3.0的集群支持
来看看 Redis3.0 推出的 cluster 做了什么。cluster 版本的 Redis 在启动集群服务时,节点之间互相之间会建立连接,这个节点互相发现也是通过配置文件来实现的,运行期间集群会自动将不可用 master 节点切换为它的一个 slave,保持了很好的高可用性。这个基本上是第一个问题的内置解决方案。但是对于第二个问题看上去似乎没什么革新的地方。按照官网介绍,Redis Cluster 的数据分布并没有使用一致性哈希,它引入了一个 hash slot 的概念,总共有16384(固定的)个 slots。所有 master Redis 实例将会分摊这些 slots。对 key 做 CRC16 映射到整数,然后对 16384 取模,定位到对应的 Redis 实例上。当加入节点时你还是需要手动将一部分老 Redis 的 hash slot 重新分配到新的上,所以本质上和我们采用的方法没有任何差别。尽管由于节点相互之间存在连接,slot 重新分配后数据访问和存储可以自动重定向,但是 key 的自动迁移会阻塞两个节点,对于 key 非常多的应用场景,仍然显得有些力不从心。而且 slot 得重新分配该使用什么策略能保证 key 得分配均匀呢?和我们的处理方式一样均分么?
在客户端方面,新的 Jedis(Java 实现的 Redis Client)已经不再需要我们自己做一致性哈希,并且节点实例的缓存都已经控制好。
总的来说,这次 Redis Cluster 通过节点互联支持了内部的数据访问的重定向,内部的数据迁移,也做到了在节点 fail 时的主从自动切换,相比自己处理集群来说方便了许多。