腾讯云服务器配置redis 腾讯云服务器配置环境

windows2008服务器中毒登录不进去

pyright © 1999-2020, CSDN.NET, All Rights Reserved

创新互联公司专注于镇康网站建设服务及定制，我们拥有丰富的企业做网站经验。 热诚为您提供镇康营销型网站建设，镇康网站制作、镇康网页设计、镇康网站官网定制、小程序设计服务，打造镇康网络公司原创品牌,更为您提供镇康网站排名全网营销落地服务。

运维

打开App

登录

const_qiu

关注

服务器中毒了，无法登陆，开启拷贝恢复之路 原创

2021-03-25 11:57:09

const_qiu

码龄8年

关注

服务器中毒了，无法登陆，开启拷贝恢复之路

如果不太想看那么多废话，可以直接跳第10点看解决方案

首先，不得不说，这是一个悲伤的故事。客户几年前的一个项目，开发都找不到人了，这几天突然反馈小程序打不开，后台系统也打不开。然后找到我，开始排查。

使用的是腾讯云服务器，登录控制台后，检查了一下cpu和内存状态，发现近期几乎都是99+%，怀疑是被李坦攻击了

系统是centos7.2，尝试通过ssh 22端口远程访问服务器，哪启桐一直提示超时

检查安全组，发现端口全部处于开放状态，这~简直就是裸奔呀

先简单配置了下安全组，仅开放80 443，22端口限制ip。再次尝试，还是超时登录不上

感觉要重启，先用客户给的网站地址尝试打开，显示的是nginx默认页，看来是用了nginx代理，后台服务说是旁者java，我自己是java开发，所以如果能重启成功，重新启服务应该还是行得通的

开始重启， 然后等待了大概5-10分钟才重启完成，腾讯云是不是太垃圾了，还是说因为被攻击原因。

再次尝试远程登录，然而现实是残酷的，依旧是提示超时，检查安全组配置也是没有问题，期间还尝试了重置密码，也依然不行，心态崩了。找腾讯云售后技术~~

提交工单，害怕数据丢失，云盘备份了个快照，其实应该第一步就备份块快照的，不过都一样，备份还是需要的，虽然没用到。

工单反馈还是挺快的，不过排查了一中午，技术跟我说：你的系统我们尝试修复，但是发现原因是被抓住系统漏洞，然后被攻击中毒了。然后他网上也查了资料，跟我这现象一样，网上有解决方案，问我要不要按这个方案执行，如果成功，那就可以，如果失败，那可能要考虑做下一步处理(备份、重装啥的)。听完，心态又炸了，原来腾讯云技术也要网上查资料的呀，然后感觉后果似乎比较严重。但是只能答应说先按网上方案实施

果然意料之中，修复失败。然后他推荐了最后一个 方案：

腾讯云工程师2021-03-23 15:27:24

您好：

与您电话沟通，这边为您同步下问题的处理进展。

【问题描述】

linux服务器登录不上

【处理进展】

1、您授权后这边使用VNC登录后如下报错：

![报错图片地址]()

2、您云服务器存在安全威胁

![威胁列表图片地址]()

3、这边进入救援后，chroot时候如下报错

ERROR: ld.so: object '/usr/local/lib/libs.so' from /etc/ld.so.preload cannot be preloaded: ignored

![网上查询报错解决方案]()

尝试为您修复，并没有修复成功。

【处理建议】

您表示系统盘有重要数据需要拷贝，如下操作。

1.先将云服务器制作成自定义镜像，然后再购买一块云硬盘（此云硬盘必须大于系统盘的容量，自定义镜像是为了预防万一）

制作镜像：

2.将有问题的云服务器进行关机（在关机的状态下才能拷贝数据）

3.在CVM控制台使用【拷贝系统盘数据】功能将系统盘的数据拷贝到云硬盘（拷贝时间比较长，请耐心等待）

大图

4.当数据拷贝完成后，先购买一台按量计费的云服务器

5.把云硬盘挂载至新购买的按量计费云服务器，检查里面的数据是否完整（这步一定要做，核实数据是否存在）

6.当核实数据没有问题后，将云硬盘从按量计费云服务器卸载下来，并销毁按量计费云服务器

7.然后将有问题的云服务器进行重装系统

8.重装系统完成后挂载云硬盘即可读取里面的数据

温馨提示：重装系统后，服务器系统盘内的所有数据将被清除，恢复到初始状态；服务器数据盘的数据不会丢失，但需要手动挂载才能使用。

详细操作指引如下：

感谢您对腾讯云的支持，祝您生活愉快。

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

拿到方案，我问技术能不能我给他权限，让他帮忙操作下，我是真的没经验，我只是个小菜开发，不过他说不能这样，没办法，只能自己上了。

解决过程

1.先将云服务器制作成自定义镜像，然后再购买一块云硬盘

镜像我觉得可以不用，除非你想保留现场，但是这系统都已经被攻击了，没必要。可以直接购买一块云硬盘，就是在控制台-云硬盘，点击下新增，选择跟你现有云盘配置一样的就行，然后选择按量计费，费用其实就是几分钱一个小时，用完销毁就行

购买数据盘

2.将有问题的云服务器进行关机（在关机的状态下才能拷贝数据）.

这就不解释了直接关机

3.在CVM控制台使用【拷贝系统盘数据】功能将系统盘的数据拷贝到云硬盘（拷贝时间比较长，请耐心等待）

这一步按下面操作完成后就可以把中毒的服务器云盘数据拷贝到我们新买的云盘上，然后按后面的操作挂载到服务器后就可以读取到我们的数据，然后拷贝了

拷贝系统盘数据

4.当数据拷贝完成后，先购买一台按量计费的云服务器

这一步跟买云盘一样，就是新买一台临时服务器，配置最低的就行，因为就是为了挂载云盘拷贝数据用的。选择和原服务器和云盘同一个地区的，然后带宽调到最高，这样下载数据会很快，选择按量收费，按量是按流量收费，所以带宽高点不用担心费用太高，反而下载速度会更快

5.把云硬盘挂载至新购买的按量计费云服务器，检查里面的数据是否完整（这步一定要做，核实数据是否存在）

这里首先也是简单配置下安全组吧，可以临时开放22端口保证可以远程访问

挂载就在云盘列表，有个更多按钮，然后点击一下挂载，挂载到我们新购的临时服务器

挂载成功后，其实你会发现服务器还是没有数据的，因为还得登录远程窗口手动配置下才能成功

两个命令：

fdisk -l

mount /dev/vdb1 /mnt/

框住的

6. 当核实数据没有问题后，将云硬盘从按量计费云服务器卸载下来，并销毁按量计费云服务器

这一步我觉得腾讯云说的太简单了，其实这一步才是关键，当我们完成上面的挂载后，就能在/mnt目录看到我们原来服务器云盘的数据了，这里我大概列一下我拷贝的文件和目录

nginx 配置，通过nginx配置可以看到我们的项目域名、项目关联文件目录、一些证书文件

项目源文件，由于之前项目源码我这边没有，所有直接把这个文件拷出来，然后解压缩还能看到数据库相关配置

项目图片目录，通过nginx.conf看到项目的图片啥文件竟然也存在服务器，所以还得拷贝这个目录文件

redis 配置，通过项目源文件看到还有redis配置，而且是无密码登录，所以等会重装后还得安装配置redis无密码登录。本来想设置个密码的，然后发现源码还想不支持读密码，所以放弃了。只是关闭了外网访问

项目源文件是jar包，所以java环境就正常搭建就好

数据库文件

*这是重中之中了，通过源文件发现数据库用的也是本地mysql数据库，而且还是mysql5.5。说实话这一步我有点不知道怎么恢复数据，但是这一步没完成，上面的没有任何意义。

我的想法是，我物理文件肯定是有，那通过物理文件还是有办法恢复的，所以先把数据库的目录我整个压缩拷贝了一份，接着就开始百度，但是觉得答非所闻，没办法了，只能求助之前一个dba同事。

同事真的很热心，这里感谢一下我的这位dba（清华）同事，跟他大概说了下情况，然后mysql版本和数据库目录文件发给他，很快他“轻轻松松”就恢复了，专业的果然就不一样。这个过程我这里就不详细描述了，后面打算再写个文章复盘一下，大致过程就是，拷贝data目录，然后找台正常的服务器，修改一下data映射配置，修改下目录权限，然后启动mysql拉一下数据，然后导出来就可以。

7. 然后将有问题的云服务器进行重装系统

到这里基本拷贝工作都完成了，然后就是重装系统，重新按上面的项目配置要求重新搭建启动一下服务就行

8. 重装系统完成后挂载云硬盘即可读取里面的数据

至此，我就成功完成了服务恢复，最后还是很感谢过程提供服务和技术支持的所有人。

阿里云腾讯云服务器官方性能及实际体验对比

阿里云腾讯云服务器性能对比

阿里云我自己的服务器，2核8G的，1个物理CPU.1个物庆猜运理核心，两线程

4核=核8g,1个物理CPU  2个物理核心，4线程

腾讯云sa24核8g    一个物理CPU，4个物理核心，,4线程

实际体验：腾讯云的redis会掉，阿里云的没有遇到过，扔开性能指数，还是阿里云的稳定些

腾讯云的不稳定点，性价比腾讯云还是可以吧，sa2做活动服务商那边拿真便宜！！

腾讯官方活动链接

阿里官方活动链接

以下是腾讯官网的一些数据

腾讯云标准型 S5

2.5GHz Intel® Xeon® Cascade Lake 处理器，2.5GHz,睿频3.1GHz，搭配最新一代六通道 DDR4，内存计算性能稳定

规格vCPU内存（GB）网络收发包（pps）队列数内网带宽能力（Gbps）主频备注

S5.SMALL11125万11.52.5GHz-

S5.SMALL21225万11.52.5GHz-

S5.SMALL41425万11.52.5GHz-

S5.MEDIUM42430万21.52.5GHz-

S5.MEDIUM82830万21.52.5GHz-

S5.LARGE84850万21.52.5GHz-

S5.LARGE1641650万21.52.5GHz-

S5.2XLARGE1681680万23.02.5GHz-

S5.2XLARGE3283280万23.02.5GHz-

S5.4XLARGE321632150万46.02.5GHz-

S5.4XLARGE641664150万46.02.5GHz-

S5.6XLARGE482448200万69.02.5GHz-

S5.6XLARGE962496200万69.02.5GHz-

S5.8XLARGE643264250万8122.5GHz-

S5.8XLARGE12832128250万8122.5GHz-

S5.12XLARGE964896400万1217.02.5GHz-

S5.12XLARGE19248192400万1217.02.5GHz-

S5.16XLARGE25664256500万1623.02.5GHz-

腾讯云s4

标准型 S4 实例采用至强®处理器 Skylake 全新处理器，内存采用最新最新兆咐一代六通道 DDR4 内存，，默认网络优化，内存带宽达2666MT/s最高内网收誉梁发能力达600万pps，最高内网带宽可支持25Gbps。

服务器    2.4GHz Intel® Xeon® Skylake 6148 最新一代六通道 DDR4 内存

规格vCPU内存（GB）网络收发包（pps）队列数内网带宽能力（Gbps）主频备注

S4.SMALL11125万11.52.4GHz-

S4.SMALL21225万11.52.4GHz-

S4.SMALL41425万11.52.4GHz-

S4.MEDIUM42430万21.52.4GHz-

S4.MEDIUM82830万21.52.4GHz-

S4.LARGE84850万21.52.4GHz-

S4.LARGE1641650万21.52.4GHz-

S4.2XLARGE1681680万23.02.4GHz-

S4.2XLARGE3283280万23.02.4GHz-

S4.4XLARGE321632150万46.02.4GHz-

S4.4XLARGE641664150万46.02.4GHz-

S4.6XLARGE482448200万68.02.4GHz-

S4.6XLARGE962496200万68.02.4GHz-

S4.8XLARGE643264250万811.02.4GHz-

S4.8XLARGE12832128250万811.02.4GHz-

S4.12XLARGE964896400万1216.02.4GHz-

S4.12XLARGE19248192400万1216.02.4GHz-

S4.16XLARGE12864128500万1622.02.4GHz-

S4.16XLARGE25664256500万1622.02.4GHz-

S4.18XLARGE28872288600万1624.02.4GHz-

腾讯云标准型SA2配置参数

CPU处理器：AMD EPYC ROME新一代处理器，主频2.6GHz，睿频3.3GHz。

内存：最新一代八通道 DDR4，内存计算性能稳定。

网络：超高网络收发包能力达750万pps，最大网络带宽25Gbps。

规格vCPU内存（GB）网络收发包（pps）队列数内网带宽能力（Gbps）主频备注

SA2.SMALL11125万11.52.6GHz-

SA2.SMALL21225万11.52.6GHz-

SA2.SMALL41425万11.52.6GHz-

SA2.MEDIUM42430万21.52.6GHz-

SA2.MEDIUM82830万21.52.6GHz-

SA2.LARGE84850万21.52.6GHz-

SA2.LARGE1641650万21.52.6GHz-

SA2.2XLARGE1681670万21.52.6GHz-

SA2.2XLARGE3283270万21.52.6GHz-

SA2.4XLARGE321632100万43.02.6GHz-

SA2.4XLARGE641664100万43.02.6GHz-

SA2.8XLARGE643264140万85.02.6GHz-

SA2.12XLARGE964896210万127.02.6GHz-

SA2.16XLARGE12864128280万169.02.6GHz-

SA2.20XLARGE16080160350万1612.02.6GHz-

SA2.22XLARGE22490224375万1613.02.6GHz-

SA2.24XLARGE19296192420万1614.02.6GHz-

SA2.32XLARGE256128256560万3218.02.6GHz-

SA2.40XLARGE320160320710万3223.02.6GHz-

SA2.45XLARGE464180464750万3225.02.6GHz-

Redis简单集群

1开放云服务器web控制台对应的端口和对应防火墙端口

22台阿里云服务器（公网IP：120.25.172.196，120.78.177.101）

一台腾讯云服务器（公网IP：111.231.106.5）

其中（120.25.172.196作为主，其他两台作为从）

主要修改3个配置如下：

bind 0.0.0.0 (原本是127.0.0.1，bind不是绑定意思而是允许哪个IP访问这个跑起来redis,0.0.0.0代表任意IP)

requirepass xu123456 (设置密码，客户端需要用，在小黑窗打命令如下redis-cli -a xu123456)

masterauth xu123456 (设置从节点追随主节点密码，设成和上面一样)

》》》带配置启动Redis服务：redis-server ~/redisfile/redis.conf

在120.78.177.101 进入redis-cli 客户端态稿搏小黑窗后，执行replicaof 120.25.172.196 6379 追随帆祥master

在111.231.106.5 进入redis-cli 客户端小黑窗后，执行replicaof 120.25.172.196 6379 追随master

1，redis-server 26379.conf --sentinel

其中26379.conf 只有两行：

port 26379

sentinel monitor mymaster 120.25.172.196 6379 2

sentinel auth-pass mymaster xu123456

sentinel announce-ip "120.25.172.196" #这个是公布Redis 对外用这个公网IP

具体解释：mymaster任意给的名字，127.0.0.1 6379 代表监控的服务，2代表选举势力

假如集群中有5个sentinel，票数被设置为2，敬余当2个sentinel认为一个master已经不可用了以后，将会触发failover，但是，进行failover的那个sentinel必须先获得至少3个sentinel的授权才可以实行failover。

如果票数被设置为5，要达到ODOWN状态，必须所有5个sentinel都主观认为master为不可用，要进行failover，那么得获得所有5个sentinel的授权。

Redis分布式缓存搭建

花了两天时间整理了之前记录的Redis单体与哨兵模式的搭建与使用，又补齐了集群模式的使用和搭建经验，并对集群的一些个原理做了理解。

笔者安装中遇到的一些问题：

如果make报错，可能是没装gcc或者gcc++编辑器，安装之 yum -y install gcc gcc-c++ kernel-devel ，有可能还是提示一些个c文件编译不过，gcc -v查看下版本，如果不到5.3那么升级一下gcc：

在 /etc/profile 追加一行 source /opt/rh/devtoolset-9/enable

scl enable devtoolset-9 bash

重新make clean, make

这回编译通态纳哪过了，提示让你最好make test一下/

执行make test ，如果提示 You need tcl 8.5 or newer in order to run the Redis test

那就升级tcl， yum install tcl

重新make test，如果还有error就删了目录，重新tar包解压重新make , make test

\o/ All tests passed without errors! ，表示编译成功。

然后make install即可。

直接运行命令： ./redis-server /usr/redis-6.0.3/redis.conf

redis.conf 配置文件里帆码 bind 0.0.0.0 设置外部访问， requirepass xxxx 设置密码。

redis高可用方案有两种：

常用搭建方案为1主1从或1主2从+3哨兵监控主节点， 以及3主3从6节点集群。

（1）sentinel哨兵

/usr/redis-6.0.3/src/redis-sentinel /usr/redis-6.0.3/sentinel2.conf

sentinel2.conf配置：

坑1：master节点也会在故障转移后成为从节点，也需要配置masterauth

当kill master进程之后，经过sentinel选举，slave成为了新的master，再次启动原master，提示如下错误：

原因是此时的master再次启动已经是slave了，需要向现在的新master输入密码，所以需要在master.conf

中配置：

坑2：哨兵配置文件要暴露客户端可以访问到的master地址

在 sentinel.conf 配置文件的 sentinel monitor mymaster 122.xx.xxx.xxx 6379 2 中，配置该哨兵对应的master名字、master地址和端口，以及达到多少个哨兵选举通过认为master挂掉。其中master地址要站在redis访问者（也就是客户端）的角度、配置茄稿访问者能访问的地址，例如sentinel与master在一台服务器（122.xx.xxx.xxx）上，那么相对sentinel其master在本机也就是127.0.0.1上，这样 sentinel monitor mymaster 127.0.0.1 6379 2 逻辑上没有问题，但是如果另外服务器上的springboot通过lettuce访问这个redis哨兵，则得到的master地址为127.0.0.1，也就是springboot所在服务器本机，这显然就有问题了。

附springboot2.1 redis哨兵配置：

坑3：要注意配置文件.conf会被哨兵修改

redis-cli -h localhost -p 26379 ，可以登到sentinel上用info命令查看一下哨兵的信息。

曾经遇到过这样一个问题，大致的信息如下

slaves莫名其妙多了一个，master的地址也明明改了真实对外的地址，这里又变成127.0.0.1 !

最后，把5个redis进程都停掉，逐个检查配置文件，发现redis的配置文件在主从哨兵模式会被修改，master的配置文件最后边莫名其妙多了一行replicaof 127.0.0.1 7001， 怀疑应该是之前配置错误的时候（见坑2）被哨兵动态加上去的！ 总之，实践中一定要多注意配置文件的变化。

（2）集群

当数据量大到一定程度，比如几十上百G，哨兵模式不够用了需要做水平拆分，早些年是使用codis，twemproxy这些第三方中间件来做分片的，即 客户端 - 中间件 - Redis server 这样的模式，中间件使用一致性Hash算法来确定key在哪个分片上。后来Redis官方提供了方案，大家就都采用官方的Redis Cluster方案了。

Redis Cluster从逻辑上分16384个hash slot，分片算法是 CRC16(key) mod 16384 得到key应该对应哪个slot，据此判断这个slot属于哪个节点。

每个节点可以设置1或多个从节点，常用的是3主节点3从节点的方案。

reshard，重新分片，可以指定从哪几个节点移动一些hash槽到另一个节点去。重新分片的过程对客户端透明，不影响线上业务。

搭建Redis cluster

redis.conf文件关键的几个配置：

启动6个集群节点

[root@VM_0_11_centos redis-6.0.3]# ps -ef|grep redis

root 5508 1 0 21:25 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7001 [cluster]

root 6903 1 0 21:32 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7002 [cluster]

root 6939 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7003 [cluster]

root 6966 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7004 [cluster]

root 6993 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7005 [cluster]

root 7015 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7006 [cluster]

这时候这6个节点还是独立的，要把他们配置成集群：

说明： -a xxxx 是因为笔者在redis.conf中配置了requirepass xxxx密码，然后 --cluster-replicas 1 中的1表示每个master节点有1个从节点。

上述命令执行完以后会有一个询问： Can I set the above configuration? yes同意自动做好的分片即可。

最后 All 16384 slots covered. 表示集群中16384个slot中的每一个都有至少有1个master节点在处理，集群启动成功。

查看集群状态：

坑1：暴露给客户端的节点地址不对

使用lettuce连接发现连不上，查看日志 Connection refused: no further information: /127.0.0.1:7002 ，跟之前哨兵配置文件sentinel.conf里边配置master地址犯的错误一样，集群启动的时候带的地址应该是提供给客户端访问的地址。

我们要重建集群：先把6个redis进程停掉，然后删除 nodes-7001.conf 这些节点配置文件，删除持久化文件 dump.rdb 、 appendonly.aof ，重新启动6个进程，在重新建立集群：

然后，还是连不上，这次报错 connection timed out: /172.xx.0.xx:7004 ，发现连到企鹅云服务器的内网地址上了！

解决办法，修改每个节点的redis.conf配置文件，找到如下说明：

所以增加配置：

然后再重新构建集群，停进程、改配置、删除节点文件和持久化文件、启动进程、配置集群。。。再来一套（累死了）

重新使用Lettuce测试，这次终于连上了！

坑2：Lettuce客户端在master节点故障时没有自动切换到从节点

name这个key在7002上，kill这个进程模拟master下线，然后Lettuce一直重连。我们期望的是应该能自动切换到其slave 7006上去，如下图：

重新启动7002进程，

7006已成为新master，7002成为它的slave，然后Lettuce也能连接上了。

解决办法，修改Lettuce的配置：

笔者用的是springboot 2.1 spring-boot-starter-data-redis 默认的Lettuce客户端，当使用Redis cluster集群模式时，需要配置一下 RedisConnectionFactory 开启自适应刷新来做故障转移时的自动切换从节点进行连接。

重新测试：停掉master 7006，这次Lettuce可以正常切换连到7002slave上去了。（仍然会不断的在日志里报连接错误，因为需要一直尝试重连7006，但因为有7002从节点顶上了、所以应用是可以正常使用的）

Redis不保证数据的强一致性

Redis并不保证数据的强一致性，也就是取CAP定理中的AP

关于一致性Hash算法，可以参考 一致性Hash算法 - (jianshu点抗 )

Redis cluster使用的是hash slot算法，跟一致性Hash算法不太一样，固定16384个hash槽，然后计算key落在哪个slot里边（计算key的CRC16值再对16384取模），key找的是slot而不是节点，而slot与节点的对应关系可以通过reshard改变并通过gossip协议扩散到集群中的每一个节点、进而可以为客户端获知，这样key的节点寻址就跟具体的节点个数没关系了。也同样解决了普通hash取模算法当节点个数发生变化时，大量key对应的寻址都发生改动导致缓存失效的问题。

比如集群增加了1个节点，这时候如果不做任何操作，那么新增加的这个节点上是没有slot的，所有slot都在原来的节点上且对应关系不变、所以没有因为节点个数变动而缓存失效，当reshard一部分slot到新节点后，客户端获取到新迁移的这部分slot与新节点的对应关系、寻址到新节点，而没迁移的slot仍然寻址到原来的节点。

关于热迁移，猜想，内部应该是先做复制迁移，等迁移完了，再切换slot与节点的对应关系，复制没有完成之前仍按照原来的slot与节点对应关系去原节点访问。复制结束之后，再删除原节点上已经迁移的slot所对应的key。

与哨兵模式比较类似，当1个节点发现某个master节点故障了、会对这个故障节点进行pfail主观宕机，然后会通过gossip协议通知到集群中的其他节点、其他节点也执行判断pfail并gossip扩散广播这一过程，当超过半数节点pfail时那么故障节点就是fail客观宕机。接下来所有的master节点会在故障节点的从节点中选出一个新的主节点，此时所有的master节点中超过半数的都投票选举了故障节点的某个从节点，那么这个从节点当选新的master节点。

所有节点都持有元数据，节点之间通过gossip这种二进制协议进行通信、发送自己的元数据信息给其他节点、故障检测、集群配置更新、故障转移授权等等。

这种去中心化的分布式节点之间内部协调，包括故障识别、故障转移、选主等等，核心在于gossip扩散协议，能够支撑这样的广播协议在于所有的节点都持有一份完整的集群元数据，即所有的节点都知悉当前集群全局的情况。

Redis高可用方案 - (jianshu点抗 )

面试题:Redis 集群模式的工作原理能说一下么 - 云+社区 - 腾讯云 (tencent点抗 )

深度图解Redis Cluster原理 - detectiveHLH - 博客园 (cnblogs点抗 )

Redis学习笔记之集群重启和遇到的坑-阿里云开发者社区 (aliyun点抗 )

云服务器Redis集群部署及客户端通过公网IP连接问题