Redis高可用
2021-08-23 17:52:57 0 举报AI智能生成
Redis高可用
作者其他创作
大纲/内容
Redis高可用
简述
单机的Redis是无法保证高可用的，当Redis服务器宕机后，即使在有持久化的机制下也无法保证不丢失数据
所以可以采用Redis多机和集群的方式保证Redis的高可用
主从复制
开启
Redis主持主从复制功能，可以通过执行slaveof（Redis5之后为replicaof），或在配置文件中设置slaveof（replicaof）来开启复制功能
配置
主Redis
无需特殊配置
从Redis
redis.conf
replicaof 192.168.0.110 6379
作用
读写分离
一主多从，主从同步
提升Redis性能和吞吐量
主从数据一致性问题
数据容灾
从机是主机的备份，主机宕机，从机可读不可写
默认情况下主机宕机后，从机不可为主机，可利用哨兵实现主从切换，实现高可用
原理
复制流程
保存主节点信息
当客户端向从服务器发送slaveof时，从服务器将主机IP、端口保存到redisServer的masterhost和masterport中
从服务器向发送Slaveof命令的客户端返回OK，表示复制指令已经被接收，而实际复制工作是在OK返回之后进行
建立Socket连接
slave和master建立socket连接
slave关联文件事件处理器，该处理器接收RDB文件（全量复制），接收Master传播来的写命令（增量复制）
主服务器accept从服务器的socket连接后，创建相应的客户端状态，相当于从服务器是主服务器的Client
发送ping命令
slave向master发送ping命令
1. 检测socket的读写状态
2. 检测master能否正常处理
master响应
1. 发送“pong”，说明正常
2. 返回错误，说明不正常
3. timeout，说明网络超时
权限验证
主从正常连接后，进行权限验证
主机未设置密码（requirepass=“”），从机也不用设置密码（masterauth=“”）
主机设置密码（requirepass!=""），从机需要设置密码（masterauth=xxxx），或通过auth命令向主机发送密码
发送端口信息
身份验证后，从服务器将执行命令，向主服务器发送从服务器的监听端口号
REPLCONF listening-port
同步数据
Redis2.8后分为全量同步和增量同步
命令传播
同步数据完成后，主从服务器会进入命令传播阶段，主服务器只要将自己执行的写命令发送给从服务器，而从服务器只要一直执行并接收主服务器发来的写命令
同步数据集
旧版本
Redis2.8以前，使用SYNC命令同步复制
实现
1. 同步操作
1. 通过从服务器发送SYNC命令给主服务器
2. 主服务器生成RDB文件并发送给从服务器，同时发送保存所有写命令给从服务器
3. 从服务器清空之前数据并执行解释RDB文件
4. 保持数据一致
还需要命令传播过程才能保持一致
2. 命令传播
同步操作完成后，主服务器执行写命令，该命令发送给从服务器并执行，使主从保持一致
缺陷
没有全量同步和增量同步的概念，从服务器在同步时，会清空所有数据
主从服务器断线后重新复制，主服务器会重新生成RDB文件和重新记录缓冲区的所有命令，并全量同步到从服务器上
新版本
Redis2.8以后，使用PSYNC命令替代SYNC
实现
PSYNC命令，具备完整重同步和部分重同步模式
Redis的主从同步，分为全量同步和增量同步
只有从机第一次连接上主机是全量同步
断线重连有可能触发全量同步或增量同步
Master判断runid是否一致
此外都是增量同步
全量同步
同步快照阶段
Master创建并发送快照RDB给slave，slave载入并解析快照
Master同时将此阶段产生的新的写命令存储到缓冲区
同步写缓冲阶段
Master向Slave同步存储在缓冲区的写操作命令
同步增量阶段
Master向Slave同步写操作命令
增量同步
Redis增量同步主要指Slave完成初始化后开始正常工作时，Master发生的写操作同步到Slave的过程
通常情况下，Master每执行一个写命令就会向Slave发送相同的写命令，然后Salve接收并执行
心跳检测
命令传播阶段，从服务器默认会以每秒一次的频率向主服务器发送命令
replconf ack
作用
1. 检测主从的连接状态
通过向主服务器发送INFO_Replication，可以列出从服务器列表，可以看到从机最后一次向主机发送命令距离现在的时长
Lag值应该在0~1之间跳动，超过1说明主从之间连接有故障
2. 辅助实现min-slaves
Redis可以通过配置防止主服务器在不安全的情况下执行写命令
min-slaves-to-write 3/min-replicas-to-write 3
min-slaves-max-lag 10/min-replicas-max-lag 10
以上配置表示：从服务器数量少于3，或3个从服务器延迟（lag）值都大于等于10秒时，主服务器将拒绝执行写命令
3. 检测命令丢失
如果因为网络故障，主服务器传播给从服务器的写命令在半路丢失，那么当从服务器向主服务器发送REPLCONF_ACK时，主服务器将发觉从服务器当前的偏移量少于自己的复制偏移量，然后主服务器就会根据从服务器提交的复制偏移量，在复制积压缓冲区里面找到从服务器缺少的数据，并重新发送给从服务器
哨兵模式
sentinel是Redis高可用的解决方案
由一个或多个sentinel实例组成sentinel集群可以监视一个或多个主服务器和多个从服务器
当主服务器进入下线状态时，sentinel可以将该主服务器下的某一从服务器升级为主服务器继续提供服务，从而保证Redis的高可用
部署方案
搭建配置
配置主从服务器
daemonize yes
protected-mode no
replicaof 192.168.0.120 6379
从服务器
配置哨兵集群
port 26379
哨兵实例默认端口26379
daemonize yes
sentinel monitor
master-name：自己命名的主节点名字
quorum：指定个数的sentinel认为master节点失联，则整个集群认为master节点失联
sentinel auth-pass
设置哨兵连接主从的密码，必须为主从设置一样的验证密码
sentinel down-after-milliseconds
指定毫秒后，主节点没有应答sentinel，则认为主节点下线，默认30s
sentinel parallel-syncs
指定在发生failover主备切换时最多可以有多少个slave同时对新的master进行同步
数字越小，完成failover时间越长
数字越大，意味着越多的slave因为复制而不可用
sentinel failover-timeout
故障转移的超时时间，默认3分钟
应用在
1. 同一个sentinel对同一个master两次failover之间的间隔时间
2. 当一个slave从一个错误的master同步数据开始计算，直到slave被纠正为向正确的master同步数据
3. 当要取消一个正在进行的failover所需要的时间
4. 当进行failover时，配置所有slaves指向新master所需的最大时间
然而即使超过了本参数，salves依然会被正确配置为指向master，但是就不按parallel-syncs的配置规则了
依次开启master，slave，sentinel
执行流程
启动并初始化Sentinel
Sentinel是一个特殊的Redis服务器，不会进行持久化
Sentinel实例启动后，会创建多个连向主服务器的网络连接
命令连接
用于向主服务器发送命令，并接收响应
订阅链接
用于订阅主服务器的—sentinel—:hello频道
获取主服务器信息
Sentinel默认每10s一次，向被监控的主服务器发送info命令，获取主服务器和其下属从服务器的信息
获取从服务器信息
当Sentinel发现主服务器有新的从服务器出现时，Sentinel还会向从服务器建立命令连接和订阅连接
命令连接建立后，还是默认10s一次，向从服务器发送info命令，并记录从服务器的信息
向主/从服务器发送消息（订阅方式）
默认情况下，Sentinel每2s一次，向所有被监视的主服务器和从服务器所订阅的—sentinel—:hello频道上发送消息，消息中会携带Sentinel自身的信息和主服务器的信息
接收来自主/从服务器的频道信息
当Sentinel与主/从服务器建立起订阅连接后，Sentinel会通过订阅连接，向服务器发送以下命令
subscribe -sentinel-:hello
Sentinel彼此之间只创建命令连接，而不创建订阅连接
因为Sentinel通过订阅主从服务器，可以感知到新的Sentinel加入，而一旦新Sentinel加入后，相互感知的Sentinel通过命令连接通信就可以了
检测主观下线状态
Sentinel每秒一次向所有建立了命令连接的实例发送PING命令
实例在down-after-milliseconds内返回无效回复
+PING、-LOADING、-MASTERDOWN除外
实例在down-after-milliseconds内无回复
超时
检查客观下线状态
当一个Sentinel将一个主服务器判断为主观下线后，Sentinel会向同时监控这个主服务器的所有其他Sentinel发送查询命令
SENTINEL is-master-down-by-addr
其他Sentinel回复
如果达到Sentinel配置中的quorum数量的Sentinel实例都判断主服务器为主观下线，则该主服务器被判定为客观下线（down）
选举Leader
当一个主服务器被判定为客观下线后，监视这个主服务器的所有Sentinel会通过选举算法（raft），选出一个Leader Sentinel去执行failover操作
Leader选举
Raft
Raft协议是用来解决分布式系统一致性问题的协议，它描述的节点状态有：Leader、Follower、Candidate
Term：Raft协议将时间切分为一个个Term，可以认为是一种“逻辑时间”
选举流程
Raft采用心跳机制触发Leader选举
系统启动后，所有节点初始化为Follower，term为0
节点收到RequestVote或AppendEntries，会保持自己的Follower身份
节点如果一段时间没有收到AppendEntries消息，在该节点超时时间内还没发现Leader，Follower就会转换为Candidate，自己开始竞选Leader
转化为Candidate，节点立即进行
增加自己的term
启动一个新定时器
给自己投一票
向所有其他节点发送RequestVote，并等待回复
如果在计时器超时前，节点收到多数节点的同意投票，就转换为Leader，同时向其他节点发送AppendEntries，告知自己成为Leader
每个节点在一个term内只能投一票，采取先到先得的策略，Candidate投给自己，Follower投给第一个收到的RequestVote节点
Raft协议的定时器采取随机超时时间，这是选举Leader的关键
同一个term内，先转为Candidate的节点会先发起投票，从而获得多数票
Sentinel Leader选举
1.某Sentinel认定master客观下线后，该Sentinel会先看看自己有没有投过票，如果自己已投票给其他Sentinel，在一定时间内自己就不会称为Leader
2.如果该Sentinel还没投票，那么它成为Candidate
3.Sentinel需要完成几件事情
更新故障转移状态为start
当前epoch加1，相当于进入一个新term，在Sentinel中epoch就是Raft协议中的term
向其他节点发送is-master-down-by-addr命令请求投票，命令会带上自己的epoch
给自己投一票（leader、leader_epoch）
4.当其他哨兵收到此命令时，可以同意或拒绝它成为领导者（通过判断epoch）
5.Candidate会不断统计自己的票数，直到它发现自己的选票超过半数且超过配置的quorum，则它成为Leader
6.其他Sentinel等待Leader从Slave选出Master后，检测到新的Master正常工作后，就会去掉客观下线的标识
故障转移
当选举出Leader_Sentinel后，它会对下线的主服务器执行故障转移操作
步骤
1.将失效Master的其中一个Slave升级为新Master，并让其他Salve改为复制新的Master
2.当客户端试图连接失效的Master时，集群也会向客户端返回新Master的地址，使得集群可以使用现在的Master替换失效Master
3.Master和Slave服务器切换后，Master的redis.conf、Slave的redis.conf和sentinel的redis.conf都会发生相应的改变
主服务器选择
哨兵Leader根据以下规则从从服务器中选择出新的主服务器
1. 过滤掉主观下线的节点
2. 选择slave-priority最高的节点，如有则返回，没有则继续
3. 选择出复制偏移量最大的从节点，有则返回，没有继续
复制偏移量越大说明数据复制完整性越高
4. 选择run_id最小的节点
run_id越小说明重启次数越少
集群与分区
意义
分区是将数据分布在多个Redis实例上，每个实例只包含一部分数据
性能提升
单机Redis的网络IO能力和计算资源有限，将请求分散到多台机器，充分利用多台机器的计算能力和网络带宽，有助于提高Redis总体的服务能力
存储能力的横向扩展
即使Redis的服务能力能够满足应用需求，但是随着存储数据的增加，单台机器受限于机器本身的存储容量，将数据分散到多台机器存储是的Redis服务可以横向扩展
方式
根据分区键（id）进行分区
范围分区
根据id数字的范围，每个范围分到不同的redis实例
好处
实现简单，方便迁移和扩展
缺点
热点数据分布不均，性能损失
非数字型key无法使用（uuid）（可采用雪花算法）
hash分区
利用简单hash算法即可
Redis实例 = hash(key) % N
好处
支持任何类型的key
热点分布较均匀，性能较好
缺点
迁移复杂，需要重新计算，扩展差（可利用一致性hash）
client端分区
对于一个给定的key，客户端直接选择正确的节点来进行读写，许多Redis客户端都实现了客户端分区（JedisPool），也可以自行编程实现
部署方案
客户端选择算法
普通Hash
一致性Hash
proxy端分区
在客户端和服务端引入一个代理或代理集群，客户端将命令发送到代理上，由代理根据算法，将命令路由到相应的服务器上
常见代理有Codis和TwemProxy
Codis
由豌豆荚与2014年11月开源，基于Go和C开发，是近期涌现的，国人开发的优秀开源软件之一
Codis 3.x组件
Codis Server
基于redis-3.2.8分支开发，增加了额外的数据结构，以支持Slot相关的操作以及数据迁移指令
Codis Proxy
客户端连接的Redis代理服务，实现了Redis协议
除了部分命令不支持以外，表现和原生Redis没有区别
说明
对于同一个业务集群，可以同时部署多个codis-proxy实例
不同codis-proxy之间有codis-dashboard保证状态同步
Codis Dashboard
集群管理工具，支持codis-proxy、codis-server的添加、删除，以及数据迁移操作
集群状态发生改变时，它维护集群下所有codis-proxy的状态一致性
说明
同一个业务集群来说，同一时刻codis-dashboard只能有0或1个
所有对集群的修改都必须通过codis-dashboard完成
Codis Admin
集群管理的命令行工具
可用于控制codis-porxy、codis-dashboard状态以及访问外部存储
Codis FE
集群管理界面
多个集群实例可以共享同一个前端展示页面
通过配置文件管理后端codis-dashboard列表，配置文件可自动更新
Storage
为集群状态提供外部存储
提供namespace概念，不同集群按照不同product name进行组织
目前仅提供zookeeper、Etcd、Fs三种实现，但提供了抽象的interface以供扩展
集群搭建
下载
golang
jdk
zookeeper
设置环境变量
golang
codis
编译环境
export GOPATH=/usr/codis
java
zookeeper
设置编译环境
编译Codis源码
make MALLOC=libc
配置
Codis Proxy
codis/config.ini
zk=localhost:2181
zookeeper地址
product=test
codis集群名字，也可以认为是命名空间
proxy_id=proxy_1
标记proxy的名字，多个proxy使用不同的config.ini，proxy_id不同
net_timeout=5
检测状态时间间隔
dashboard_addr=localhost:18087
dashboard服务地址，必须启动
coordinator=zookeeper
Codis Server
启动codis中的redis-3.2.8实例，利用admin/codis-server-admin.sh启动
如果配置多个需要修改config/redis.conf
Redis Sentinel
sentinel.conf
protected-mode no
daemonize yes
不需要配置监控信息
启动Admin下组件
zkServersh start
./admin/codis-dashboard-admin.sh start
./admin/codis-proxy-admin.sh start
./admin/codis-server-admin.sh start
./admin/codis-fe-admin.sh start
./bin/redis-sentinel ./config/sentinel.conf
web界面管理
localhost:9090
操作
添加组
添加主机
添加从机
自动均衡slot
Auto-Rebalance
添加哨兵
分片原理
codis将所有key默认划分为1024个槽位，首先对key进行Crc32计算hash值，再将hash值对1024取余，即得到key对应的槽位
Codis的槽位和分组映射关系保存在Codis Proxy中
实例间槽位同步
Codis_Proxy存在单点问题，需要做集群，不同proxy之间需要同步映射关系
Codis将槽位关系存储在Zk中，且提供一个Dashboard可以用来观察和修改槽位关系
槽位关系发生变化时，Codis_proxy会监听到变化并重新同步槽位关系，从而实现多个Codis_proxy间共享相同的槽位关系配置
扩容&自动均衡
通过web，添加新组、添加新主机/从机
点击 Rebalance All Slots
优点
对客户端透明，与codis交互方式和redis本身交互一样
支持在线数据迁移，迁移过程对客户端透明，有简单的管理和监控界面
支持高可用，无论是redis数据存储还是代理节点
自动进行数据的均衡分配
最大支持1024个redis实例，存储容量海量
高性能
缺点
采用自有的redis分支，不能与原版redis保持同步
如果codis的proxy只有一个，redis性能会下降20%左右
某些命令不支持
RedisCluster分区
Redis3.0后，Redis官方提供了完整的集群解决方案
采用了去中心化的方式，包括：sharding、replication、failover，称为RedisCluster
Redis5.0前采用Redis-trib进行集群的创建和管理，需要ruby支持
Redis5.0可以直接使用Redis-cli进行集群创建和管理
部署架构
去中心化
RedisCluster是由多个Redis节点组成，是一个P2P无中心节点的集群架构，依靠Gossip协议传播的集群
Gossip协议
是一个通信协议，一种传播消息的方式
基本思想
一个节点周期性（每秒）随机选择一些节点，并把信息传递给这些节点
这些收到信息的节点接下来会做同样的事请
信息会周期性的传递给N个目标节点，这个N被称为fanout（扇出）
gossip包含多种消息
meet
sender向receiver发出，请求receiver加入sender集群
ping
节点检测其他节点是否在线
pong
receiver收到meet或ping后的回复信息
在failover后，新的master也会广播pong
fail
节点A判断节点B下线后，A节点广播B的fail信息，其他收到节点会将B标记为下线
publish
节点A收到publish命令，执行该命令，并向集群广播publish命令，收到publish命令的节点都会执行相同的操作
通过gossip协议，Cluster可以提供集群间状态同步更新，选举自主failover等重要的集群功能
Slot
Redis-Cluster将所有的物理节点映射到[0-16383]个slot上，基本上采用平均分配和连续分配的方式，cluster负责维护节点和slot槽的对应关系
当需要在Redis集群中放置一个key-value时，Redis先对key使用Crc16算法得到一个结果，然后把结果对16384求余，这样每个Key都会对应一个Slot槽，Redis根据节点数量大致均等的将Slot槽映射到不同的节点
Slot槽必须在节点上连续分配，如果出现不连续的情况，则RedisCluster不能工作
优势
高性能
RedisCluster性能和单节点部署是同级别的
多主节点、负载均衡、读写分离
高可用
支持标准的主从复制配置来保障高可用和高可靠
实现了一个类似Raft的共识方式，来保障整个集群的可用性
易扩展
向集群添加新节点、或移除节点都是透明的，不需要停机
水平、垂直都非常容易扩展
数据分区、海量数据、数据存储
原生
部署RedisCluster不需要其他代理或工具，且RedisCluster和单机Redis几乎完全兼容
集群搭建
RedisCluster最少需要三台主服务器，三台从服务器
步骤
1. 安装6台Redis服务器
2. 修改配置
redis.conf
cluster-enable yes
3. 启动所有节点
4. 创建集群
cluster-replicas：集群中每台主机有几个从机
5. 连接集群
使用 -c 标识
表示以redis集群方式进行连接
6. 查看集群
集群状态
cluster info
集群节点
cluster nodes
分区
说明
不同节点分组服务于相互无交集的分片，RedisCluster不存在单独的Proxy或配置服务器，所以需要将客户端路由到目标的分片
客户端路由
RedisCluster客户端比单机Redis需要具备路由语义的识别能力，且具备一定的路由缓存能力
moved重定向
1.每个节点通过通信都会共享集群中槽和对应节点的关系
2.客户端向集群任意节点发送命令，该节点会根据Crc16规则进行hash运算和16384取余，计算自己的槽和对应节点
3.如果保存数据的槽被分配给当前节点，则去槽中执行命令，并把命令执行结果返回给客户端
4.如果保存数据的槽不再当前节点的管理范围内，则向客户端返回moved重定向异常
5.客户端接收到节点返回的结果，如果是moved异常，则从moved异常中获取目标节点的信息
6.客户端向目标节点发送命令，获取命令执行结果
ask重定向
在对集群进行扩容和缩容时，需要对槽和槽中数据进行迁移
当客户端向某个节点发送命令，节点向客户端返回moved异常，告诉客户端数据对应的槽的节点信息
如果此时正在进行集群扩容/缩容，当客户端向正确的节点发送命令时，槽和槽中数据已经被迁移到别的节点了，就会返回ask，即ask重定向
步骤
1.客户端向目标节点发送命令，目标节点中的槽已经迁移到别的节点，此时目标节点会返回ask转向给客户端
2.客户端向新的节点发送Asking命令给新的节点，然后再次向新节点发送命令
3.新节点执行命令，把命令执行结果返回给客户端
和moved区别
moved：槽已确认转移
ask：槽还在转移过程中
Smart智能客户端
JedisCluster
它是Jedis根据RedisCluster特性提供的集群智能客户端
它为每个节点创建连接池，并跟节点建立映射关系缓存
将每个节点负责的槽位一一与主节点连接池建立映射缓存
启动时，已经知道key-slot-node之间的关系，可以找到目标节点
它对目标节点发送命令，目标节点直接响应给JedisCluster
如果与目标节点连接出错，则它知道连接的节点是一个错误节点（moved异常）
它会重新初始化缓存映射关系，然后向新的目标节点发送命令
如果命令发送次数超过5次，抛出异常
Too many cluster redirection!
迁移
在RedisCluter中每个Slot对应的节点在初始化后就是确定的，某些情况下，节点和分片需要变更
新的节点作为master加入
某个节点分组需要下线
负载不均衡需要调整slot分布
此时需要进行分片的迁移，迁移的触发和过程控制由外部系统完成
节点迁移状态设置
迁移前标记源/目标节点
key迁移的原子化命令
1. 向目标节点发送状态变更命令，将目标节点对应的Slot状态置为importing
2. 向源节点发送状态变更命令，将源节点对应的Slot状态置为migrating
3. 向源节点发送migrate命令，告知其将要迁移的Slot对应的key迁移到目标节点
4. 所有key迁移完成后，cluster setslot重新设置槽位
扩容
添加节点
添加从节点
如果该节点在集群中的配置信息已经生成到cluster-config-file指定的配置文件中（默认为nodes.conf），操作会报错
解决方法是删除生成的配置文件nodes.conf，然后再执行命令
添加完主节点需要对主节点进行hash槽分配，这样该主节点才可以存储数据
步骤
1. 连接集群
2. 输入要分配的槽数量
3. 输入接收槽的节点Id
通过cluster nodes查看节点id
4. 输入源节点id
5. 输入yes开始移动槽到目标节点
缩容
命令
删除已经占有hash槽的节点会失败，需要将占用的槽分配出去
容灾（failover）
故障检测
集群中每个节点都会定期地（每秒）向集群其他节点发送PING消息
如果在一定时间内（cluster-node-timeout），A没有收到B的PONG回应，则A将B标识为pfail
A节点在后续发送ping时，会带上B节点的pfail信息，通知其他节点
如果B被标记为pfail的个数大于半数主节点，B会被标记为fail，A向整个集群广播，B已经下线
其他节点收到广播，标记B为fail
从节点选举
Raft，每个从节点，都根据自己对master复制数据的offset，来设置一个选举时间，offset越大的从节点，选举时间越靠前，优先进行选举
Slave通过向其他master发送FAILOVER_AUTH_REQUEST消息发起竞选，master收到后回复FAILOVER_AUTH_ACK消息告知是否同意
Slave发送FAILOVER_AUTH_REQUEST前会将currentEpoch自增，并将最新的Epoch带入到消息中，如果自己未投过票，则回复同意，否则回复拒绝
所有master开始slave选举投票，如果半数以上都投票给某个节点，则选举通过，该从节点可以切换成master
变更通知
当slave收到过半的master同意时，会成为新的master，此时会以最新的epoch通过PONG消息广播自己成为master，让cluster的其他节点尽快更新拓补结构（nodes.conf）
集群失效判定
集群中半数以上主节点宕机（无法投票）
宕机的主节点的从节点也宕机了（slot槽分配不连续）
主从切换
自动切换
即从节点选举
手动切换
人工故障切换是预期的操作，而非发生了真正的故障，目的是以一种安全的方式（数据无丢失）将当前master节点和其中一个slave节点（执行cluster-failover的节点）交换角色
步骤
1. 向从节点发送cluster failover命令
3.0前：slaveof no one
2. 从节点告知其主节点要手动切换
CLUSTERMSG_TYPE_MFSTART
3. 主节点会阻塞所有客户端命令的执行
10s
4. 从节点从主节点的ping包中获得主节点的复制偏移量
5. 从节点复制达到偏移量，发起选举、统计选票、赢得选举，升级为主节点，并更新配置
6. 切换完成，原主节点向所有客户端发送moved指令重定向到新主节点
主节点下线情况下，则通过以下命令进行强制切换
cluster failover force
cluster failover takeover
副本漂移
一主一从情况下，主从都宕机，则整个集群就挂了
Redis提供了一种方法叫副本漂移，既能提高集群的可靠性又不用增加太多从机
原理
MasterA宕机，则SlaveA提升为新MasterA，集群检测到新的MasterA是单点的（无从机）
集群从拥有最多从机的节点组MasterB中，选择节点名称字母顺序最小的从机SlaveB漂移到单点的主从节点组MasterA
流程
1. 将SlaveB的从机记录从MasterB中删除
2. 将SlaveB的主机改为MasterA
3. 在MasterA中添加SlaveB为从节点
4. 将SlaveB的复制源改为MasterA
5. 通过ping包将信息同步到集群所有节点
0 条评论
下一页
