reids集群方案设计思路 + 最佳实践
- 1.问题背景
- 2.从redis cluster看redis集群技术
- Cluster的局限
- 超大规模集群最佳实践
- 5.小结
- 6.参考
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才可以对外提供服务。
Cluster的局限
Redis Cluster 的优点是易于使用。分片、主从复制、弹性扩容这些功能都可以做到自动化，通过简单的部署就可以获得一个大容量、高可靠、高可用的 Redis 集群。
所以，Redis Cluster 非常适合构建中小规模 Redis 集群（几个到几十个节点这样规模）。但是 Redis Cluster 不太适合构建超大规模集群，主要原因是，它采用了去中心化的设计。
Redis Cluster的去中心化是指，虽然每个节点只存储全量数据中的一部分，但其每个节点上都保存了所有槽和节点的映射关系表，客户端可以访问任意一个节点，再通过重定向命令，找到数据所在的那个节点。
但当集群增加节点、或者某个主节点宕机、新的主节点被选举出来时，都需要更新集群每一个节点上的映射关系表。
这时候就需要考虑节点之间的通讯成本了，Redis Cluster 采用了一种去中心化的 流言 (Gossip) 协议 来传播集群配置的变化。大概原理就好像一段八卦在一群吃瓜群众中传播，他是自发的无序的，一段时间后群众中的每一个人都知道这个八卦了。对比起中心节点的方案，这样部署和维护都更简单，也能避免中心节点的单点故障。但Gossip协议的缺点就是传播速度慢。并且是集群规模越大，传播得越慢，连带着数据不同步的问题会被明显放大，还有一定的不确定性，如果出现问题很难排查。
超大规模集群最佳实践
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 构建缓存集群的最佳实践有哪些？