与亲生的Redis Cluster，来一次亲密接触

 

笔者曾经维护过上千个redis实例，这些实例采用的简单主从结构，集群方案主要是客户端jar包。刚开始，个人并不是太喜欢redis cluster，因为它的路由实在是太死板，运维复杂。

但官方在推这个东西，注定了它的应用越来越广泛，这在平常的交流中就能够发现。虽然有这样那样的缺点，但总抵挡不了权威推动的浪潮。随着redis cluster越来越稳定，是时候和redis cluster来一次灵魂交流了。

简介

redis cluster是亲生的集群方案，目前，在高可用和稳定性方面，都有了很大的进步。据统计和观察，采用redis cluster架构的公司和社区越来越多，已经成为事实的标准。它的主要特点就是去中心化，无需proxy代理。其中一个主要设计目标就是达到线性可扩展性（linear scalability）。

仅仅靠redis cluster服务器本身，并不能完成官方承诺的功能。广义上的redis cluster应该既包含redis服务器，又包含客户端实现比如jedis等。它们是一个整体。

分布式存储无非就是处理分片和副本。 对redis cluster来说，核心概念就是槽（slot），了解了它，基本就了解了集群的管理方式。

优缺点

当了解这些特性以后，运维上其实是更简单了。我们先看下比较明显的优缺点。

优点

1、不再需要额外的Sentinel集群，为使用者提供了一致的方案，减少了学习成本。
2、去中心架构，节点对等，集群可支持上千个节点。
3、抽象出了slot概念，针对slot进行运维操作。
4、副本功能能够实现自动故障转移，大部分情况下无需人工介入。

缺点

1、客户端要缓存部分数据，实现Cluster协议，相对复杂。
2、数据是通过异步复制的，不能保证数据的强一致性。
3、资源隔离困难，经常流量不均衡，尤其是多个业务共用集群的时候。数据不知道在哪里，针对热点数据，也无法通过专项优化完成。 4、从库是完全的冷备，无法分担读操作，真是太太浪费了。需要做额外工作。 5、MultiOp和Pipeline支持有限，老代码要是进行架构升级，要小心了。 6、数据迁移是基于key而不是基于slot的，过程较慢。

基本原理

从槽到key，定位过程明显就是一个双层的路由。

key的路由

redis cluster和常用的一致性hash没什么关系，它主要采用了哈希槽的概念。当需要在其中存取一个key时，redis客户端会首先对这个key采用crc16算法算出一个值，然后对这个值进行mod操作。

crc16(key)mod 16384

 

所以，每个key都会落在其中的一个hash槽上。16384等同于2^14（16k），redis节点发送心跳包时，需要把所有的槽信息放在这个心跳包里，所以要竭尽全力的优化，感兴趣的可以看下为什么默认的槽数量是16384。

服务端简单原理

上面谈到，redis cluster共定义了16384个槽，所有的集群操作都是围绕着这个槽数据进行编码。服务端使用一个简单的数组存储这些信息。

对于判断有无的操作，使用bitmap来存储是最节省空间的。redi