Redis Sentinel集群部署(5)

移除一个Sentinel实例会相对麻烦一些,因为Sentinel不会忘记已经感知到的Sentinel实例,所以最好按照下列步骤来处理：

• 停止将要移除的sentinel进程.
• 给其余的sentinel进程发送SENTINEL RESET *命令来重置状态,忘记将要移除的sentinel,每个进程之间间隔30秒.
• 确保所有sentinel对于当前存货的sentinel数量达成一致,可以通过SENTINEL MASTER <mastername>命令来观察,或者查看配置文件.

生产环境推荐

对于一个最小集群,Redis应该是一个Master带上两个Slave,并且开启下列选项：

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

这样能保证写入Master的同时至少写入一个Slave,如果出现网络分区阻隔并发生failover的时候,可以保证写入的数据最终一致而不是丢失,写入老的Master会直接失败.

Slave可以适当设置优先级,除了0之外(0表示永远不提升为Master),越小的优先级,越有可能被提示为Master.如果Slave分布在多个机房,可以考虑将和Master同一个机房的Slave的优先级设置的更低以提升他被选为新的Master的可能性.

考虑到可用性和选举的需要,Sentinel进程至少为3个,推荐为5个.如果有网络分区,应当适当分布(比如2个在A机房,2个在B机房,一个在C机房)等.

客户端实现

客户端从过去直接连接Redis,变成：

• 先连接一个Sentinel实例
• 使用 SENTINEL get-master-addr-by-name master-name 获取Redis地址信息.
• 连接返回的Redis地址信息,通过ROLE命令查询是否是Master.如果是,连接进入正常的服务环节.否则应该断开重新查询.
• (可选)客户端可以通过SENTINEL sentinels <master-name>来更新自己的Sentinel实例列表.

当Sentinel发起failover后,切换了新的Master,Sentinel会发送 CLIENT KILL TYPE normal命令给客户端,客户端需要主动断开对老的Master的链接,然后重新查询新的Master地址,再重复走上面的流程.这样的方式仍然相对不够实时,可以通过Sentinel提供的Pub/Sub来更快地监听到failover事件,加快重连.

如果需要实现读写分离,读走Slave,那可以走SENTINEL slaves <master name> 来查询Slave列表并连接.

其他

由于Redis是异步复制,所以Sentinel其实无法达到强一致性,它承诺的是最终一致性：最后一次failover的Redis Master赢者通吃,其他Slave的数据将被丢弃,重新从新的Master复制数据.此外还有前面提到的分区带来的一致性问题.

其次,Sentinel的选举算法依赖时间,因此要确保所有机器的时间同步,如果发现时间不一致,Sentinel实现了一个TITL模式来保护系统的可用性.

文章来自微信公众号：运维之美

（编辑：ASP站长网）