一致性哈希算法232取_redis一致性哈希算法_一致性哈希算法(2)

Redis的数据复制是异步的，无论在Master端还是Slave端都不会阻塞。redis一致性哈希算法

Slave会周期性确认收到的备份数据

Twemproxy引入主备复制后的架构更新为：

开启主备复制后的Redis Cluster的架构更新为下图，Client可以向任意节点发起请求，无论是Master节点还是Slave节点。

4.故障检测与转移

4.1 Twemproxy

4.1.1 故障检测

Twemproxy本身通过三个配置项实现：

auto_eject_hosts: true
timeout: 400
server_failure_limit: 3

如果Server Pool开启了auto_eject_hosts，则当连续server_failure_limit次访问某Server，都超时timeout无响应，则标记该节点为故障。

4.1.2 故障转移

故障节点将从Hash环上直接取下，之前保存在该Server上的Key将丢失。

4.1.3 故障转移耗时评估

假设配置：timeout=400ms, server_failure_limit=2， 则故障转移需要耗时800ms。

4.2 Twemproxy借助其他工具

使用Twemproxy时可以引入Redis Sentinel来进行故障检测。引入Redis Sentinel后Twemproxy的架构更新为：

每个Sentinel节点可以监控一个或多个Master节点，及其所有Slave节点

4.2.1 启动Redis Sentinel

redis-sentinel /path/to/sentinel.conf，其中的配置文件是必须的，配置文件将会被用来存储运行时状态信息。在配置文件中只需要指明要监视的Master节点列表。

无须为运行的每个 Sentinel 分别设同一Master的其他 Sentinel 的地址， 因为 Sentinel 可以通过发布与订阅功能来自动发现正在监视相同主服务器的其他 Sentinel

不必手动列出主服务器属下的所有从服务器， 因为 Sentinel 可以通过询问主服务器来获得所有从服务器的信息。

4.2.2 故障检测

每个 Sentinel 以每秒钟一次的频率向它所知的主服务器、从服务器以及其他 Sentinel 实例发送一个 PING 命令。

如果一个Master被标记为主观下线， 那么正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认主服务器的确进入了主观下线状态。

如果一个主服务器被标记为主观下线， 并且有足够数量的 Sentinel （至少要达到配置文件指定的数量）在指定的时间范围内同意这一判断， 那么这个主服务器被标记为客观下线。

4.2.3 故障转移

Redis Sentinel进行故障转移的过程：

某Sentinel节点发现主服务器已经进入客观下线状态。

该Sentinel发起选举，试图当选故障转移主持节点

如果当选失败， 那么在设定的故障迁移超时时间的两倍之后， 重新尝试当选。 如果当选成功， 那么执行以下步骤。

选出一个Slave节点，并将它升级为Master节点

向被选中的从服务器发送 SLEOF NO ONE 命令，让它转变为Master节点

通过发布与订阅功能， 将更新后的配置传播给所有其他 Sentinel ， 其他 Sentinel 对它们自己的配置进行更新。

向已下线主服务器的Slave节点发送 SLEOF 命令， 让它们去复制新的Master节点

Redis Sentinel选择新的Master节点进行故障转移之后，Twemproxy无法找到新的Master节点，此时需要引入第四方工具redis-twemproxy-agent（node.js），更新Twemproxy配置，并重启。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-30886-2.html