redis集群高可用相关问题总结

1、通信方式

redis cluster节点间采取gossip协议进行通信。

跟集中式不同，不是将集群元数据（节点信息，故障，等等）集中存储在某个节点上，而是互相之间不断通信，保持整个集群所有节点的数据是完整的。

维护集群的元数据用得，一种是集中式，一种叫做gossip。

集中式：好处在于，元数据的更新和读取，时效性非常好，一旦元数据出现了变更，立即就更新到集中式的存储中，其他节点读取的时候立即就可以感知到;不好在于，所有的元数据的跟新压力全部集中在一个地方，可能会导致元数据的存储有压力。

gossip：好处在于，元数据的更新比较分散，不是集中在一个地方，更新请求会陆陆续续，打到所有节点上去更新，有一定的延时，降低了压力;

缺点，元数据更新有延时，可能导致集群的一些操作会有一些滞后。

2、gossip协议

gossip协议包含多种消息，包括ping，pong，meet，fail，等等。

meet: 某个节点发送meet给新加入的节点，让新节点加入集群中，然后新节点就会开始与其他节点进行通信。

redis-trib.rb add-node其实内部就是发送了一个gossip meet消息，给新加入的节点，通知那个节点去加入我们的集群。

ping: 每个节点都会频繁给其他节点发送ping，其中包含自己的状态还有自己维护的集群元数据，互相通过ping交换元数据，每个节点每秒都会频繁发送ping给其他的集群，ping，频繁的互相之间交换数据，互相进行元数据的更新。

pong: 返回ping和meet，包含自己的状态和其他信息，也可以用于信息广播和更新。

fail: 某个节点判断另一个节点fail之后，就发送fail给其他节点，通知其他节点，指定的节点宕机了。

3、ping消息深入

ping很频繁，而且要携带一些元数据，所以可能会加重网络负担。

每个节点每秒会执行10次ping，每次会选择5个最久没有通信的其他节点。当然如果发现某个节点通信延时达到了cluster_node_timeout / 2，那么立即发送ping，避免数据交换延时过长，落后的时间太长了。比如说，两个节点之间都10分钟没有交换数据了，那么整个集群处于严重的元数据不一致的情况，就会有问题。

所以cluster_node_timeout可以调节，如果调节比较大，那么会降低发送的频率。

每次ping，一个是带上自己节点的信息，还有就是带上1/10其他节点的信息，发送出去，进行数据交换。至少包含3个其他节点的信息，最多包含总节点-2个其他节点的信息。

4、计算hash slot和hash slot查找

计算hash slot的算法，就是根据key计算CRC16值，然后对16384取模，拿到对应的hash slot，

用hash tag可以手动指定key对应的slot，同一个hash tag下的key，都会在一个hash slot中，比如set mykey1:{100}和set mykey2:{100}

节点间通过gossip协议进行数据交换，就知道每个hash slot在哪个节点上。

5、edisCluster的工作原理

本地维护一份hashslot -> node的映射表，缓存，同时为每个节点创建一个JedisPool连接池。大部分情况下，直接走本地缓存就可以找到hashslot -> node，不需要通过节点进行moved重定向。

hashslot迁移和ask重定向：

如果hash slot正在迁移，那么会返回ask重定向给jedis。

jedis接收到ask重定向之后，会重新定位到目标节点去执行，但是因为ask发生在hash slot迁移过程中，所以JedisCluster API收到ask是不会更新hashslot本地缓存。已经可以确定说，hashslot已经迁移完了，moved是会更新本地hashslot->node映射表缓存的

6、判断节点宕机

如果一个节点认为另外一个节点宕机，那么就是pfail，主观宕机。如果多个节点都认为另外一个节点宕机了，那么就是fail，客观宕机，跟哨兵的原理几乎一样，sdown，odown在cluster-node-timeout内，某个节点一直没有返回pong，那么就被认为pfail。

如果一个节点认为某个节点pfail了，那么会在gossip ping消息中，ping给其他节点，如果超过半数的节点都认为pfail了，那么就会变成fail

7、从节点过滤

对宕机的master node，从其所有的slave node中，选择一个切换成master node。

检查每个slave node与master node断开连接的时间，如果超过了cluster-node-timeout * cluster-slave-validity-factor，那么就没有资格切换成master。这个也是跟哨兵是一样的，从节点超时过滤的步骤。

8、从节点选举

哨兵：对所有从节点进行排序，slave priority，offset，run id。

每个从节点，都根据自己对master复制数据的offset，来设置一个选举时间，offset越大（复制数据越多）的从节点，选举时间越靠前，优先进行选举。所有的master node开始slave选举投票，给要进行选举的slave进行投票，如果大部分master node（N/2 + 1）都投票给了某个从节点，那么选举通过，那个从节点可以切换成master。从节点执行主备切换，从节点切换为主节点。

9、cluster模式与哨兵模式比较

整个流程跟哨兵相比，非常类似，所以说，redis cluster功能强大，直接集成了replication和sentinal的功能。

10、fork耗时导致高并发请求延时

RDB和AOF的时候，其实会有生成RDB快照，AOF rewrite，耗费磁盘IO的过程，主进程fork子进程。

fork的时候，子进程是需要拷贝父进程的空间内存页表的，也是会耗费一定的时间的。

一般来说，如果父进程内存有1个G的数据，那么fork可能会耗费在20ms左右，如果是10G~30G，那么就会耗费20 * 10，甚至20 * 30，也就是几百毫秒的时间。info stats中的latest_fork_usec，可以看到最近一次form的时长。redis单机QPS一般在几万，fork可能一下子就会拖慢几万条操作的请求时长，从几毫秒变成1秒。

优化思路

fork耗时跟redis主进程的内存有关系，一般控制redis的内存在10GB以内，slave -> master，全量复制

11、AOF的阻塞问题

redis将数据写入AOF缓冲区，单独开一个线程做fsync操作，每秒一次。但是redis主线程会检查两次fsync的时间，如果距离上次fsync时间超过了2秒，那么写请求就会阻塞。everysec，最多丢失2秒的数据，一旦fsync超过2秒的延时，整个redis就被拖慢。

优化思路

优化硬盘写入速度，建议采用SSD，不要用普通的机械硬盘，SSD，大幅度提升磁盘读写的速度。

12、主从复制延迟问题

主从复制可能会超时严重，这个时候需要良好的监控和报警机制。在info replication中，可以看到master和slave复制的offset，做一个差值就可以看到对应的延迟量。如果延迟过多，那么就进行报警。

13、主从复制风暴问题

如果一下子让多个slave从master去执行全量复制，一份大的rdb同时发送到多个slave，会导致网络带宽被严重占用。

如果一个master真的要挂载多个slave，那尽量用树状结构，不要用星型结构。

14、redis启动警告vm.overcommit_memory问题

0: 检查有没有足够内存，没有的话申请内存失败

1: 允许使用内存直到用完为止

2: 内存地址空间不能超过swap + 50%

如果是0的话，可能导致类似fork等操作执行失败，申请不到足够的内存空间

cat /proc/sys/vm/overcommit_memory

echo "vm.overcommit_memory=1" >> /etc/sysctl.conf

sysctl vm.overcommit_memory=1

15、redis优化之swap分区：swapiness

cat /proc/version，查看linux内核版本

如果linux内核版本<3.5，那么swapiness设置为0，这样系统宁愿swap也不会oom killer（杀掉进程）

如果linux内核版本>=3.5，那么swapiness设置为1，这样系统宁愿swap也不会oom killer

保证redis不会被杀掉

echo 0 > /proc/sys/vm/swappiness

echo vm.swapiness=0 >> /etc/sysctl.conf

16、最大打开文件句柄

ulimit -n 10032 10032

不同的操作系统，版本，设置的方式都不太一样

17、Redis 优化之 tcp backlog

cat /proc/sys/net/core/somaxconn

echo 511 > /proc/sys/net/core/somaxconn

此参数确定了TCP连接中已完成队列(完成三次握手之后)的长度， 当然此值必须不大于Linux系统定义的/proc/sys/net/core/somaxconn值，默认是511，而Linux的默认参数值是128。当系统并发量大并且客户端速度缓慢的时候，可以将这二个参数一起参考设定。

建议修改为 2048

18、主从切换数据丢失问题

    Redis Cluster 不保证强一致性，在一些特殊场景，客户端即使收到了写入确认，还是可能丢数据的。

    1、异步复制丢失

    对于Redis主节点与从节点之间的数据复制，是异步复制的，当客户端发送写请求给master节点的时候，客户端会返回OK，然后同步到各个slave节点中。

    如果此时master还没来得及同步给slave节点时发生宕机，那么master内存中的数据会丢失；

要是master中开启持久化设置数据可不可以保证不丢失呢？答案是否定的。在master 发生宕机后，sentinel集群检测到master发生故障，重新选举新的master，如果旧的master在故障恢复后重启，那么此时它需要同步新master的数据，此时新的master的数据是空的（假设这段时间中没有数据写入）。那么旧master中的数据就会被刷新掉，此时数据还是会丢失。

    wait 命令可以给为同步复制，但也无法完全保证数据不丢，而且影响性能。即使使用了同步复制方式，也存在特殊情况：一个没有完成同步的 slave 被选举为了 master。

    2、集群产生脑裂

    假设我们有一个redis集群，正常情况下client会向master发送请求，然后同步到salve，sentinel集群监控着集群，在集群发生故障时进行自动故障转移。此时，由于某种原因，比如网络原因，集群出现了分区，master与slave节点之间断开了联系，sentinel监控到一段时间没有联系认为master故障，然后重新选举，将slave切换为新的master。但是master可能并没有发生故障，只是网络产生分区，此时client任然在旧的master上写数据，而新的master中没有数据，如果不及时发现问题进行处理可能旧的master中堆积大量数据。在发现问题之后，旧的master降为slave同步新的master数据，那么之前的数据被刷新掉，大量数据丢失。

    脑裂网络分区

    分区后一个 master 继续接收写请求，分区恢复后这个 master 可能会变为 slave，那么之前写入的数据就丢了。

可以设置节点过期时间(maximum window（最大时间窗口） 可以减少数据损失)，减少 master 在分区期间接收的写入数量，降低数据丢失的损失。

对于redis集群，我们不可能保证数据完全不丢失，只能做到使得尽量少的数据丢失。

redis的配置文件中有两个参数我们可以设置：

min-slaves-to-write 1
min-slaves-max-lag 10

min-slaves-to-write默认情况下是0，min-slaves-max-lag默认情况下是10。

以上面配置为例，这两个参数表示至少有1个salve的与master的同步复制延迟不能超过10s，一旦所有的slave复制和同步的延迟达到了10s，那么此时master就不会接受任何请求。可以减小min-slaves-max-lag参数的值，这样就可以避免在发生故障时大量的数据丢失，一旦发现延迟超过了该值就不会往master中写入数据。（异常后可临时写入消息队列之类的方式进行重试）

19、频繁的全量复制

增大复制缓冲区repl-backlog-size

20、频繁的网络中断

repl-timeout

repl-ping-slave-period

21、多个slave获取不同步，数据不一致

slave-server-state-data  yes|no (延迟过大，暂时屏蔽对slave的访问)（慎用）

待补充....