本文已参与「新人创作礼」活动，一起开启掘金创作之路。

redis一致性哈希多集群客户端实现

背景

• 业务方使用单一redis集群，存在容量不够的问题，需要进行redis的扩容。
• 增加server后，需要保证相同的key落到相同的集群上。
• 业务方是多个client，需要保证集群的变更不影响不同client之间对于同一个key的一致性。
• 缩容也是同理。

方案

redis-cluster（> 3.0）

• 去中心化设计，每个master对等，感知所有slot的hash环的拓扑，节点间利用Gossip协议通信，进行选主等操作，主从进行数据同步，实现最终一致性。
• smartClient，能够进行redirect，更新hash map等。
• rebalancing，当发生增加或删除节点时，会发生rebalancing，redis-cluster利用一主多从特点，迁移slot的同时，读写分离和进行migrating，redirecting。比如：增加master节点B，需要将master节点A的slot：8迁移到B，则将A设置为IMPORTING状态，将B设置为MIGRATING状态，开始迁移slot新节点，此时，如果有query请求slot：8到A，如果key存在则直接返回，否则，redirect到B，client收到moved指令，继续请求B。当然，还有ask模式，详细参考reference中redis-cluster。

优点： 缺点：

codis，类codis，bdrp2.0

• proxy模式，client直接与proxy交互，proxy实现redis所有协议。
• slot路由信息，存放在proxy自身或者第三方组件如etcd，zk等。
• configServer，进行路由信息，和各个组件实例的配置server。
• 感知后端redis实例，一般是用sentinal进行感知，通知configServer，proxy再更新路由。
• smartClient。

优点： 缺点：

重点

• tradeoff，一致性，并发行，可靠性。
• 开发难易程度，时间精力，人力成本
• 部署难易程度，时间精力，人力成本
• 维护难易程度，时间精力，人力成本

所以当你作为架构师而不是一线工程师的角度来看问题的时候，考虑的是很多的tradeoff，包括整个团队，产品，开发，运维，安全等等因素。高度决定视野，视野决定成败。

refrence: github.com/xetorthio/j… redis.io/topics/clus… blog.csdn.net/u011535541/… brandur.org/redis-clust… www.imooc.com/article/393… yangzhe1991.org/blog/2015/0… www.cnblogs.com/me115/p/904…