Docker部署Redis集群----第十一节（docker-redis哨兵集群总结） - 知乎

安宇雨 - 随手采集
2019-04-28 21:14:55
随手采集
0000-未整理-等待研究

本来是计划开始新篇章redis-cluster集群的，但是总觉得缺点什么，所以本篇章对前两个篇章做一个总结来引流我们接下来的集群。

哨兵节点常见的问题：

哨兵集群在发现master node挂掉后会进行故障转移，也就是启动其中一个slave node为master node。在这过程中，可能会导致数据丢失的情况。

1、异步复制导致数据丢失：

因为master->slave的复制是异步，所以可能有部分还没来得及复制到slave就宕机了，此时这些部分数据就丢失了。

2、集群脑裂导致数据丢失：

脑裂，也就是说，某个master所在机器突然脱离了正常的网络，跟其它slave机器不能连接，但是实际上master还运行着。

照成的结果：

此时哨兵可能就会认为master宕机了，然后开始选举，将其它从节点slave切换成master。这时候集群里就会有2个master，也就是所谓的脑裂。
此时虽然某个slave被切换成了master，但是可能client还没来得及切换成新的master，还继续写向旧的master的数据可能就丢失了。
因此旧master再次恢复的时候，会被作为一个slave挂到新的master上去，自己的数据会被清空，重新获取新的master复制数据。

所以对以上的解决方案：

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

要求至少有1个从节点slave和主节点master是连接状态，数据复制和同步的延迟不能超过10秒时允许写入；
如果说一旦所有的slave，数据复制和同步的延迟都超过了10秒钟，那么这个时候，master就不会再接收任何请求了。
这样我们可以减少异步复制和脑裂导致的数据丢失

这个配置的意思是：
1、异步复制导致的数据丢失：
在异步复制的过程当中，通过min-slaves-max-lag这个配置，就可以确保的说，一旦slave复制数据和ack延迟时间太长，
就认为可能master宕机后损失的数据太多了，那么就拒绝写请求，这样就可以把master宕机时由于部分数据
未同步到slave导致的数据丢失降低到可控范围内。

2、集群脑裂导致的数据丢失：
集群脑裂因为client还没来得及切换成新的master，还继续写向旧的master的数据可能就丢失了
通过min-slaves-to-write 确保必须是有多少个从节点连接，并且延迟时间小于min-slaves-max-lag
多少秒。

这个配置在第四篇章也有写到。

客户端处理方式：

对于client来讲，就需要做些处理，比如先将数据缓存到内存当中，然后过一段时间处理，或者连接失败，接收到错误切换新的master处理。

这里我们可以对第九篇章轮询代码进行修改

//逻辑处理执行
$retry=3; //重试三次
try{
    $redis=new Redis();
    $redis->connect($slave['ip'],$slave['port'],0.5);
}catch(\Exception $e){
    var_dump($e->getMessage());
    while ($e->getMessage()=='Redis server went away' && $retry-- ){
        sleep(1);
        var_dump($retry,'重新尝试连接');
    }
    //访问哨兵获取新的主节点节点
    //while ($retry-- ){
    //    var_dump($retry,'重新尝试连接');
    //}
    //$masterInfo=$redis->rawCommand('SENTINEL','get-master-addr-by-name','mymaster'); //从节点信息
}
这样做的目的能使客户端拥有更好的体验度。

redis+哨兵的主从问题：

假设我们在一台主从机器上配置了300G内存，但是业务需求是需要500G的时候，主从结构+哨兵可以实现高可用故障切换+冗余备份，但是并不能解决数据容量的问题，用哨兵redis每个实例也是全量存储，每个redis存储的内容都是完整的数据，浪费内存且有木桶效应。为了最大化利用内存，可以采用cluster群集，就是分布式存储。即每台redis存储不同的内容。

Redis 分布式方案一般有两种：

1、客户端分区方案，优点是分区逻辑可控，缺点是需要自己处理数据路由、高可用、故障转移等问题，比如在redis2.8之前通常的做法是获取某个key的hashcode，然后取余分布到不同节点，不过这种做法无法很好的支持动态伸缩性需求，一旦节点的增或者删操作，都会导致key无法在redis中命中。