Redis Sentinel集群部署

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模式来保护系统的可用性.

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

（编辑：东莞站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!