Redis 集群方案及使用场景 @刘琛林 2017.10.31

为什么集群？ 随着公司业务的发展，访问量和数据量会不断上升，而内存资源往往是有限制 的，纵向扩展不是一个好办法，我们需要横向可伸缩扩展，这需要由多台主机 协同提供服务，即分布式多个Redis实例协同运行。 其次，目前多核CPU，几十G内存的主机很普遍，对于主进程是单线程工作的 Redis，只运行一个实例就显得有些浪费。同时，管理一个巨大内存不如管理相 对较小的内存高效。 Redis集群的目标就是为了实现高可用性，避免性能瓶颈，可动态扩容，易于做 监控告警。 Redis单线程特性，多请求顺序执行，单个耗时的操作会阻塞后续的操作 单机内存有限 某些特殊业务，带宽压力较大 单点问题，缺乏高可用性 不能动态扩容

Redis集群实现方式 实现基础——分区 实现方案： 客户端分片 基于代理的分片 Twemproxy Codis 路由查询 分区是分割数据到多个Redis实例的过程，因此每个实例只保存全部key的一个子集。 通过利用多台计算机内存的和值，允许我们构造更大的数据库。 通过多核和多台计算机，允许我们扩展计算能力；通过多台计算机和网络适配器，允许我们扩展网络带宽。 实现方案： 客户端分片 基于代理的分片 Twemproxy Codis 路由查询 Redis Cluster

客户端分片 由客户端决定key写入或者读取的节点。 包括jedis在内的一些客户端，实现了客户端分片机制。 特性 优点 简单，相比于使用代理，减少了一层网络传输的消耗，效率较高。 缺点 业务逻辑与数据存储逻辑耦合 可运维性差 多业务各自使用redis，集群资源难以管理 不支持动态增删节点 Redis客户端 Redis实例 Redis实例 Redis实例

Twemproxy 特点： 支持失败的节点自动摘除（仅作为缓存时） 所有的key通过一致性哈希算法分布到集群中所有的redis实例中 代理与每个redis实例维持长连接，减少客户端和redis实例的连接数 代理是无状态的，可以任意部署多套，避免单点问题 默认启用pipeline，连接复用，提高效率，性能损失在 10% - 20% 多种hash算法：能够使用不同的分片策略和散列函数 可以设置后端实例的权重 支持状态监控 需要依赖于一些其他的程序组件。

Redis-Sentinel是Redis官方推荐的高可用性解决方案，当用Redis做Master-slave的高可用方案时，假如master宕机了，Redis没有实现自动进行主备切换，而Redis-sentinel本身也是一个独立运行的进程，它能监控多个master-slave集群，发现master宕机后能进行自动切换。

Twemproxy 不足： 虽然使用 c 开发，性能损失较小，但同样是单线程。所以基本上twemproxy的数量需要和后端redis实例一样甚至更多才能充分发挥多实例的并发能力，造成运维困难。 twemproxy更改配置文件需要重新启动，比较坑，需要修改代码使其支持动态加载。 无法动态扩容，如果需要实现这个功能，要么自己写迁移脚本，手动迁移，比较繁琐，还会影响到当前服务的正常运行。 性能低：代理层损耗 && 本身效率低下，实测大约在20% 不支持针对多个值的操作，比如取sets的子交并补等（MGET 和 DEL 除外） 不支持Redis的事务操作 失去维护 最近一次提交在一年之前。

Codis Codis 是一个分布式 Redis 解决方案, 对于上层的应用来说, 连接到 Codis Proxy 和连接原生的 Redis Server 没有显著区别 ，上层应用可以像使用单机的 Redis 一样使用, Codis 底层会处理请求的转发, 不停机的数据迁移等工作, 所有后边的一切事情, 对于前面的客户端来说是透明的, 可以简单的认为后边连接的是一个内存无限大的 Redis 服务。 Codis Twemproxy Redis Cluster resharding without restarting cluster Yes No pipeline hash tags for multi-key operations multi-key operations while resharding - No(details) Redis clients supporting Any clients Clients have to support cluster protocol

Codis模块简介 Codis Server 基于 redis-2.8.21 分支开发。增加了额外的数据结构，以支持 slot 有关的操作以及数据迁移指令。 Codis Proxy 客户端连接的 Redis 代理服务, 实现了 Redis 协议。 对于同一个业务集群而言，可以同时部署多个 codis-proxy 实例 不同 codis-proxy 之间由 codis-dashboard 保证状态同步。 Codis Dashboard 集群管理工具，支持 codis-proxy、codis-server 的添加、删除，以及据迁移等操作。 所有对集群的修改都必须通过 codis-dashboard 完成。 Codis Admin 集群管理的命令行工具。 可用于控制 codis-proxy、codis-dashboard 状态以及访问外部存储。 Codis FE 集群管理界面。 Codis HA 为集群提供高可用。 依赖 codis-dashboard 实例，自动抓取集群各个组件的状态； 会根据当前集群状态自动生成主从切换策略，并在需要时通过 codis-dashboard 完成主从切换。 Storage 为集群状态提供外部存储。 目前仅提供了 Zookeeper 和 Etcd 两种实现，但是提供了抽象的 interface 可自行扩展。

Codis Codis是一整套缓存解决方案，包含高可用、数据分片、监控、动态扩态 etc.。走的是 Apps->代理->redis cluster。 Codis引入了Group的概念，每个Group包括1个Redis Master及至少1个Redis Slave，这是和Twemproxy的区别之一。这样做的好处是，如果当前Master有问题，则运维人员可通过Dashboard“自助式”切换到Slave，而不需要小心翼翼地修改程序配置文件。 为支持数据热迁移（Auto Rebalance），出品方修改了Redis Server源码，并称之为Codis Server。 Codis采用预先分片（Pre-Sharding）机制，事先规定好了，分成1024个slots（也就是说，最多能支持后端1024个Codis Server），这些路由信息保存在ZooKeeper中。 Codis仅负责维护当前Redis Server列表，由运维人员自己去保证主从数据的一致性。 支持Pipeline 使得客户端可以发出一批请求，并一次性获得这批请求返回结果。

Redis Cluster Redis官方推出，可线性扩展到1000个节点 无中心架构 一致性哈希思想，预分片 增加slave做数据副本，同时可用于切换，使集群快速恢复。 实现故障自动切换。节点之间通过gossip协议交换状态信息；投票机制完成slave到master角色的提升。 客户端直连redis服务，免去了proxy代理的损耗 降低硬件成本和运维成本，提高系统的扩展性和可用性。

数据分布：预分片 预先分配好 16384 个slot slot 和 server 的映射关系存储每一个 server 的路由表中，每个节点中都包含集群所有的节点信息 根据 CRC16(key) mod 16384 的值，决定将一个key放到哪一个slot中 数据迁移时就是调整 slot 的分布

架构：去中心化 每个节点中不会存有有重复数据，仅仅有自己的从机帮忙冗余。 集群中的节点不会代理请求：即如果client将命令发送到错误的节点上，操作会失败，但会返回”-MOVED”或”-ASK”，供client进行永久或临时的节点切换（需要 smart-client 支持），所以client连接集群中任意一个节点都可以 节点添加，或宕机或不可达的情况下还可以正常使用

可用性：Master-Slave 每个Redis Node可以有一个或者多个Slave，当Master挂掉时，选举一个Slave形成新的Master。 Master Slave 之间异步复制（可能会丢数据）。 采用 gossip 协议探测其他节点存活状态，超过 cluster-node-timeout，标记为 PFAIL，PING中附加此数据。当 Node A发现半数以上master将失效节点标记为PFAIL，将其标记为FAIL，广播 FAIL。 各 slave 等待一个随机时间后 发起选举，向其他 master 广播，半数以上同意则赢得选举否则发起下一次选举 当 slave 成为 master，先广播，后持续PING，最终集群实例都获知此消息

动态扩容/缩容 在目标节点上声明将从源节点上迁入Slot 在源节点上声明将往目标节点迁出Slot 批量从源节点获取KEY CLUSTER SETSLOT <slot> IMPORTING <source_node_id> 在源节点上声明将往目标节点迁出Slot 批量从源节点获取KEY CLUSTER GETKEYSINSLOT <slot> <count> 将获取的Key迁移到目标节点 MIGRATE <target_ip> <target_port> <key_name> 0 <timeout> 重复步骤3，4直到所有数据迁移完毕 分别向双方节点发送 CLUSTER SETSLOT <slot> NODE <target_node_id> 该命令将会广播给集群其他节点，已经将Slot转移到目标节点。 等待集群状态变为OK CLUSTER INFO 中的 cluster_state = ok

现阶段存在的问题： Gossip协议通信开销 严重依赖于smart-client的成熟度 （PHP redis 扩展） 如果smart-client支持缓存slot路由，需要额外占用内存空间，为了效率需要建立和所有 redis server 的长连接（每一个使用该库的程序都需要建立这么多连接）。 如果不支持缓存路由信息，会先访问任意一台 redis server，之后重定向到新的节点。 需要更新当前所有的client。 官方只提供了一个ruby程序 redis-trib 完成集群的所有操作，缺乏监控管理工具，很难清楚目前集群的状态 数据迁移以Key为单位，速度较慢 某些操作不支持，MultiOp和Pipeline都被限定在命令中的所有Key必须都在同一Slot内

Redis集群方案各参数比较 Twemproxy Codis Redis Cluster 性能   Twemproxy Codis Redis Cluster 性能 1、 单点的话比起原子redis降低20%左右； 2、 增加PIPELINE管道提高性能 只要是代理的设计性能瓶颈肯定在其，因redis实在太快 1、 相当于单redis实例40%性能丢失(从最开始的版本比Twemproxy慢20%至目前比其快100%)； 2、 弥补：增加proxy数量和支持多核，比起Twemproxy还是好一点，因Twemproxy最好的情况跑满一个CPU； 3、 弥补：增加PIPELINE管道提高性能 没什么损失，追求的就 是这个 1000个节点内拥有线性的伸缩性，和操作redis实例性能差不多 分片算法 Redis一致hash，当初设计好如后续变更修改（增减节点）需要配置proxy通知新的算法，重启服务 通过presharding采用solt槽位的形式，整个集群分为1024个哈希槽，分片算法位SlotId = crc32(key) % 1024，增减节点不需要重启服务 采用solt槽位的形式，整个集群分为16384个哈希槽，分片算法位SlotId = crc16(key) % 16384，增减节点不需要重启服务 所需组件 Redis、twemproxy(nutcracker) Codis、zookeeper Redis,客户端支持 服务启动 方式 单进程 多进程

Redis集群方案各参数比较 Twemproxy Codis Redis Cluster 水平扩容 缩容（增 减节点）   Twemproxy Codis Redis Cluster 水平扩容 缩容（增 减节点） Redis存储层操作，不提供自动的解决方案，并且要自己写脚本支持数据的搬迁活动，然后更改proxy哈希算法，重启服务 Redis存储层，都是在线操作（扩容数据迁移，缩容的话先搬迁数据至别的节点，然后下线该节点） 没有代理和存储之分， 可以在线操作（扩容数 据迁移，缩容的话先搬 迁数据至别的节点，然 后下线该节点） 主从是否 必须 1、 没有数据复制不影响可 用节点代替故障节点 2、 如果没有做备份，故障节点key全部丢失 1、 故障节点如果没有备份，则 丢失掉该组的所有数据，但是不 影响其他组的运行，不会导致整 个集群坏掉 2、 如有备份节点，则把其升为主节点，集群没有影响，正常运转（需要管理员手动变更从节点为主节点，最新版本添加HA功能） 没有主从复制的节点一旦故障，将导致整个集群不可用，无法写入或者读入任何key，无法进行数据重新分片 官网建议：至少3主3从 主从特点 基于redis本身的主从方案（利用发布/订阅机制，采用广播形式）， 采用异步复制（asynchronous replication）的方案，无论是master端还是slave端都不会引起阻塞，但是肯定是存在数据丢失的情况 集群设计 1、 proxy部署高可用（多proxy结合keepalived+haporxy） 2、 redis层设计多主多从部署 1、 proxy部署（多proxy+zookeeper集群方案，并且结合keepalived+haporxy） 2、 codis-server部署多组，每组部署一主多从架构 利用redis本身部署集群：至少3主3从

Redis集群方案各参数比较 Twemproxy Codis Redis Cluster 故障监控 自带监控并告警 目前还没有提供 功能限制 1、 不支持多key操作 2、 不支持事务 3、 不支持EVAL 比较多，可以查看官方文档 1、 复杂的多KEY(set求并求交集)不能跨节点操作 2、 不支持MULTI/EXEC 提供支持 不在维护 目前活跃状态 官网主打 概括 1、 轻量级 2、 在proxy层实现一致性哈希 3、 快速的故障转移 4、 可借助sentinel实现底层HA 5、 每次变更必须重启生效 1、 基于zookeeper的proxy高可用，zookeeper会记录整个集群的生存状态，则需要维护好zookeeper 2、 优势为动态水平扩容， 平衡数据，在迁移的时候不 影响业务访问和响应时间 3、 Dashboard操作降低人失误率，图形直观查看信息 4、 强一致数据（也是设计 的重点） 1、 性能好（也是设计的原 则） 2、 无中心组织结构，有利 有弊 3、 故障转移响应时间长 4、 有写丢失，比较频繁

总结：没有最好的架构，只有最合适的架构 参考资料： http://www.jianshu.com/p/14835303b07e http://www.voidcn.com/article/p-sasaebpg-ko.html http://blog.fatedier.com/2015/09/15/redis-cluster-survey/ http://www.sohu.com/a/79200151_354963 https://www.zhihu.com/question/21419897/ http://blog.csdn.net/dc_726/article/details/48552531 http://www.jianshu.com/p/ee2aa7fe341b http://www.cnblogs.com/verrion/p/redis_structure_type_selection.html https://github.com/twitter/twemproxy/ https://github.com/CodisLabs/codis