前言
上文分析了哨兵模式的原理,他是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基本原理,还有很多细节需要深入优化。