上文分析了哨兵模式的原理，他是redis官方提供的高可用方案，弥补了集群模式下不能自动故障转移的缺陷，但是在高并发系统中，redis服务器还是会存在单机瓶颈，会给redis带来非常大的压力,redis官方提供了另外一种高可用，高性能方案cluster。redis Cluster可以提供redis数据分片和横向扩展的能力，降低单个master的压力。
想一想，如果需要做redis分片的存储，可以在哪些地方入手？
1、首先想到客户端，客户端根据操作的key进行分片计算，将请求路由到目的redis服务器
2、第2种可以是开发一个代理中间件，类似mycat，客户端连接到中间件，由中间件来完成分片和路由的逻辑。
3、还一种就是基于redis服务端进行开发，官方就是这么做的。
分片需要解决哪些问题呢？
1、需要动态选择数据源，客户端请求到底是要路由到哪台redis服务器
2、redis节点新增，删除，数据的迁移怎么处理？
常见的分片路由算法有一致性hash算法
这种算法有一个环形数据结构，将服务器节点映射到环形结构上，然后用hash算法计算服务器节点的下标，沿着顺时针方向查找第一个服务器节点，这个时候分片就选好了。这种方案的好处就是在服务器变更的情况下，数据分布比较稳定。由于服务器节点比较少，通常还会虚拟出一些节点。
在Redis Cluster中，redis既没有用hash取模，也没有用一致性hash。而是用虚拟槽实现的。创建16384个槽，每个redis节点负责一个区间段。
master根据bitmap来保存slot关系，0代表不属于本节点，1代表属于当前节点。
为什么RedisCluster会设计成16384个槽呢?
1.如果槽位为65536，`发送心跳信息的消息头达8k`，发送的心跳包过于庞大。
在消息头中，最占空间的是 myslots[CLUSTER_SLOTS/8]。 当槽位为65536时，这块的大小是: 65536÷8÷1024=8kb因为每秒钟，redis节点需要发送一定数量的ping消息作为心跳包，如果槽位为65536，这个ping消息的消息头太大了，浪费带宽。
2.redis的集群主节点数量基本不可能超过1000个。
集群节点越多，心跳包的消息体内携带的数据越多。如果节点过1000个，也会导致网络拥堵。因此redis作者，`不建议redis cluster节点数量超过1000个。那么，对于节点数在1000以内的redis cluster集群，16384个槽位够用了。没有必要拓展到65536个。
3.槽位越小，节点少的情况下，压缩率高
Redis主节点的配置信息中，它所负责的哈希槽是通过一张`bitmap`的形式来保存的，在传输过程中，会对bitmap进行压缩，但是如果bitmap的填充率slots / N很高的话(N表示节点数)，bitmap的压缩率就很低。 如果节点数很少，而哈希槽数量很多的话，bitmap的压缩率就很低。
客户端slot路由规则
1、在redission中客户端中，每次操作key都会计算slot。
if (key.hasArray()) {
end = CRC16.crc16(key.array(), key.position(), key.limit() - key.position()) % 16384;
return end;
}
//分配slot
end = CRC16.crc16(key) % 16384;2、客户端初始化和定时任务会从master拉取slot信息,并进行本地缓存。
本文内容记录redis cluster基本原理，还有很多细节需要深入优化。
