Reids集群设计思路+Reids Cluster+最佳实践

1.问题背景

当业务场景存在高并发访问、海量数据、高可用性等业务需求时，单机redis已经不满足要求。

在网上一搜，你会看到琳琅满目的解决方案，有开源且成熟的redis cluster，也有大企业自研的redis集群方案，其中涉及的技术点，如主从复制、故障转移、分片算法更是让人眼花缭乱。当你想要开始针对你的业务场景设计redis缓存方案时，难免布置从何下手。

只有合适的方案才是最好的，本文旨在梳理这些技术和方案之间的选用思路，让你在面对不同的业务问题时，能自如地把握redis集群方案，按需选择！

2.从redis cluster看redis集群技术

技术的选型应该是发现某个问题，再寻求相应对策。而Redis Cluster是官方推荐的比较成熟的集群方案，其中集成了分片、主从复制、Sentinel哨兵等技术。

技术	解决的问题	RedisCluster实现方式
分片	数据量大，并发访问量大	通过哈希槽算法，将redis单节点分片成多节点，可以通过水平扩容来增加集群的存储容量；
主从复制	节点的可用性	将原来分片了的各节点作为主节点，给每个主节点配置多个从节点，保证主节点的可用性
Sentinel哨兵	基于主从复制，当主节点挂掉后，需要手动切换主从节点	额外设置一个哨兵，用于实现主从自动切换，从从节点中选举产生新的主节点（Redis-Sentinel是官方推荐的高可用（HA）解决方案，是独立运行程序，自身也可以集群）

值得注意的是高可用问题，你可能会觉得分片之后，当一个服务挂了可以快速的切换到另外一个服务，就也自动保证了高可用。

但其实Redis Cluster里保证高可用的是主从结构，如果某一master节点宕机，且他无slave的话，为了保障集群的完整性，保证所有的哈希槽都指派给了可用的master，整个集群将不可用。

当然，在这种情况下如果你还是想让集群保持可用的话，可以将 cluster-require-full-coverage 这个参数设置成no，cluster-require-full-coverage表示需要16384个slot都正常被分配的时候Redis Cluster才可以对外提供服务。

3.Redis Cluster的局限

Redis Cluster 的优点是易于使用。分片、主从复制、弹性扩容这些功能都可以做到自动化，通过简单的部署就可以获得一个大容量、高可靠、高可用的 Redis 集群。

所以，Redis Cluster 非常适合构建中小规模 Redis 集群（几个到几十个节点这样规模）。但是 Redis Cluster 不太适合构建超大规模集群，主要原因是，它采用了去中心化的设计。

Redis Cluster的去中心化是指，虽然每个节点只存储全量数据中的一部分，但其每个节点上都保存了所有槽和节点的映射关系表，客户端可以访问任意一个节点，再通过重定向命令，找到数据所在的那个节点。

但当集群增加节点、或者某个主节点宕机、新的主节点被选举出来时，都需要更新集群每一个节点上的映射关系表。

这时候就需要考虑节点之间的通讯成本了，Redis Cluster 采用了一种去中心化的 流言 (Gossip) 协议 来传播集群配置的变化。大概原理就好像一段八卦在一群吃瓜群众中传播，他是自发的无序的，一段时间后群众中的每一个人都知道这个八卦了。对比起中心节点的方案，这样部署和维护都更简单，也能避免中心节点的单点故障。但Gossip协议的缺点就是传播速度慢。并且是集群规模越大，传播得越慢，连带着数据不同步的问题会被明显放大，还有一定的不确定性，如果出现问题很难排查。

4.Redis超大规模集群最佳实践

Redis Cluster 不太适合用于大规模集群，所以很多大厂，都选择自己去搭建 Redis 集群。

集群架构	原理	案例	优缺点
基于代理	在客户端和 Redis 节点之间增加一层代理服务，作用有（1）在客户端和 Redis 节点之间转发请求和响应（2）监控集群中所有 Redis 节点状态（3）维护集群的主从信息、槽和节点的映射关系等元数据	twemproxy 、Codis	（1）性能损失：增加了一层代理转发，数据访问的链路更长（2）代理服务的单点故障问题
定制客户端	把代理服务的寻址功能前移到客户端中去，客户端在发起请求之前，先去查询元数据，就可以知道要访问的是哪个分片和哪个节点，然后直连对应的 Redis 节点访问数据	jedis	（1）架构比较复杂，客户端不能通用，需要开发定制化的 Redis 客户端；（2）元数据服务仍然是一个单点，但它的数据量和访问量不大，相对较容易实现

5.小结

• 几个到几十个节点规模的集群建议使用官方的 Redis Cluster，在节点数量不多的情况下，各方面表现都不错。
• 再大一些规模的集群，可以考虑使用twemproxy 或者 Codis 这类的基于代理的集群架构，开源且成熟，在生产环境中验证过。
• 相比于代理方案，使用定制客户端的方案性能更好，但需要定制化开发，只有规模足够大的企业才负担得起。。

6.参考

MRCODE-BOOK : 用 Redis 构建缓存集群的最佳实践有哪些？