Redis集群最佳实践

存储系统通用解决方案

数据量大查询慢：历史数据归档/分库分表  =》 分片

并发高扛不住：读写分离  =》 增加实例数

主实例宕机：增加主从节点，主节点宕机时候从节点顶上 =》主从复制（数据一致性问题）

 

Redis Cluster如何应对数据量大、高并发和高可用问题？

 

一、分片

槽（Slot）：每个集群16*1024=16384个Slot，槽是Redis分片的基本单位，每个槽存放部分Key

哈希Key：HASH_SLOT = CRC16(key) mod 16384  

槽如何存放Redis节点：利用查表法

    客户端连接任意节点访问集群数据，访问Key, 通过HASH_SLOT公式计算具体的槽位，再通过查表法，查找到槽与节点的真实映射关系，再重定向到正确节点上

 

二、水平扩容

利用水平扩容增加集群存储容量，集群新增节点，从集群老节点搬运部分槽到新节点，也可以手动指定具体的槽到新节点 =》利用官方的 redis-trib.rb脚本自动重新分配槽，自动迁移

 

三、高可用&高并发

 

高可用：增加主从节点，做主从复制；

Redis Cluster支持每个分片增加1个或多个从节点，从节点连接主节点后，向主节点发送SYNC命令 ,请求一次全量复制；全量复制完后，进入同步阶段，主节点把刚刚复制期间收到的全部命令以及后续收到命令，持续转发给从节点；  =》状态机技术（快照+日志）

高并发：主从节点读取，大部分读写都是主节点负责，从节点只是预备作用

 

四、Redis Cluster不适合超大规模集群的原因

Redis Cluster优点：易使用，分片、主从复制、弹性扩容功能自动化，简单部署并可达到大容量、高可靠、高可用的Redis集群，对应用来说，完全透明，适合构建中小规模Redis集群（几10个规模Redis集群）

不适合超大规模集群原因：去中心化设计，Redis每个节点保存所有槽和节点映射关系

问题：这个映射关系是如何更新的？集群中加入新节点或某个节点宕机，新节点被选举出来，都需要更新集群每个节点映射关系

实现：采用流言(Gossip）协议 https://en.wikipedia.org/wiki/Gossip_protocol   八卦传播协议，优点：避免中心节点故障，缺点：传输速度慢，集群规模越大，传播协议越慢；集群规模太大，数据不同步问题明显放大，存在一定不确定性，问题难排查

 

方案一：代理模式 

 

 

优点： 代理实现路由转发，检测集群Redis节点状态（出现问题及时切换），维护集群元数据

缺点：增加一层代理转发，数据链路更长，带来一定性能损失；代理服务同样需要集群支持

 业界方案：twemproxy （https://github.com/twitter/twemproxy ）和codis （https://github.com/CodisLabs/codis）

 

方案二：客户端寻址 （推荐）

 

 实现原理：客户端维护元数据，某个分片主节点宕机，新节点选举出来，更新元数据信息

 问题：元数据服务依旧是单点，可以使用Zookeeper、etcd或MySQL解决 

 优点： 性能、弹性、高可用几方面表现都非常好

  缺点：整个架构比较复杂，客户端不能通用；需要定制Redis客户端