Redis- redis4.0、codis、阿里云redis 3种redis集群对比分析

 

本文对redis4.0版本的cluster，codis，以及阿里云redis 3种集群进行了对比分析。

1、架构对比

1.1、redis 4.0 cluster

redis 4.0版本的集群是去中心化的结构，集群元数据信息分布在每个节点上，主备切换依赖于多个节点协商选主。 redis 提供了redis-trib 工具做部署集群及运维等操作。 客户端访问散列的db节点需依赖smart client，也就是客户端需要对redis返回的节点信息做判断选择路由等操作。例如客户端请求一个节点，如果所请求的key不在该节点上，客户端需要判断返回的move或ask等指令，重定向请求到对应的节点。

1.2、codis

codis由3大组件构成：

  • codis-server : 修改过源码的redis, 支持slot，扩容迁移等
  • codis-proxy : 支持多线程，go语言实现的内核
  • codis Dashboard : 集群管理工具

提供web图形界面管理集群。 集群元数据存在在zookeeper或etcd。 提供独立的组件codis-ha负责redis节点主备切换。 基于proxy的codis，客户端对路由表变化无感知。客户端需要从codis dashhoard调用list proxy命令获取所有proxy列表，并根据自身的轮询策略决定访问哪个proxy节点以实现负载均衡。

1.3、阿里云redis

阿里云的redis集群版由3大组件构成：

  • redis-config : 集群管理工具
  • redis-server : 优化过源码的redis，支持slot, 扩容迁移等
  • redis-proxy : 单线程，c++14语言实现的内核

redis-proxy 无状态，一个集群根据集群规格可挂多个proxy节点。 redis-config 双节点，支持容灾。 集群元数据存储在rds db上。 提供独立的组件HA负责集群的主备切换等。 阿里云的redis集群同样基于proxy，用户对路由信息无感知，同时提供vip给客户端访问，客户端只需一个连接地址即可，无须关心proxy访问的负载均衡等。

2、性能对比

2.1、压测环境

在3台物理机上分别搭建了以上3种redis集群。每台物理机千兆网卡，24核cpu，内存189G。3台物理机分别跑压测工具memtier_benchmark、codis proxy/阿里云proxy、redis server。redis server使用各种集群配套的redis内核。 固定key size 32个字节，set/get 操作比例为1:10。每个线程16个客户端。连续压测5分钟，分8个， 16个， 32个， 48个， 64个线程压测。 因为redis4.0集群需要额外的客户端选择节点，而memtier_benchmark不支持，所以使用了hashtag 来压测redis4.0。 每个集群有8个master db， 8个slave db， aof打开。aof rewrite的最小buffer为64MB。 压测的对象分别为单个redis 4.0 节点， 单个阿里云redis-proxy， 单核的codis-proxy， 8核的codis-proxy。 codis 使用的go版本为1.7.4。

压测结果图如下： 可看出，单核的codis-proxy性能最弱。8核的codis-proxy压测没有对key使用hashtag，如此相当于将请求分散到后端8个db节点上， 也可以说相当于8个阿里云的redis-proxy。自然性能数据就比较高了。 单核的阿里云redis-proxy在压力够大的情况下性能逼近原生的redis db节点。 在实际生产环境中，使用原生的redis cluster，客户端需要实现cluster protocol， 解析move, ask等指令并重定向节点，随意访问key可能需要两次访问操作才能完成，性能上并不能完全如单节点一样。

3、支持特性对比

3.1、主要不同协议的支持对比

redis 4.0阿里云rediscodis事务支持相同slot支持相同的slot不支持sub/pub支持相同slot支持不支持flushall支持支持不支持select不支持不支持不支持mset/mget支持相同slot支持支持

更多命令请参考各自的集群版本说明。

3.2、水平扩展对比

redis4.0 cluster，codis，阿里云redis 分布式集群均实现了面对slot的管理，扩展的最小单元是slot。 分布式集群中水平扩展的本质是对集群节点的路由信息管理以及数据的迁移。这3种集群迁移数据的最小单位均是key。

3.2.1 redis cluster 水平扩展原理

redis4.0 cluster支持指定slot在节点中移动，也支持加入空节点后根据集群节点中已存在的slot分布自动进行再分布。以redis-trib的move_slot为例解析slot移动的过程：

  • 步骤1): 调用setslot命令修改源、目标节点slot的状态
  • 步骤2): 获取源节点上slot的key列表
  • 步骤3): 调migrate命令迁移key，迁移过程中redis属于阻塞状态，只有目标节点restore成功后才返回
  • 步骤4): 调用setslot命令修改源、目标节点slot的状态

在迁移过程中，如何保证数据的一致性呢？ redis cluster提供迁移状态中的重定向机制，向客户端返回ASK，客户端收到后需先发送asking指令到目标节点上，然后再发请求到目标节点上才可以访问。当访问的key满足以下全部条件时会出现重定向返回：

  • key所属slot在该节点上，如不在，返回的是MOVE
  • slot处于迁移状态中
  • key不存在

如上所述，migrate 是一个同步阻塞型的操作，如果key并不为空，即使slot处于迁移状态，key依然能被读写，以此保证数据的一致性。

3.2.2 codis 水平扩展原理

codis对slot的再分布策略与redis cluster相同。codis-server内核并没有存储slot的信息，也不解析key所在的slot，只有在dbadd等操作时将对应的key记录到以slot为key的dict中，如果key带有tag，则将tag做crc32运算后将key插入到以crc32值为key的skiplist中。 codis Dashboard 后台起迁移状态机程序，先确保通知到所有proxy开始迁移，即prepare阶段，如有一台以上proxy失败，则迁移任务失败。迁移步骤与redis cluster类似，不同点是：

  • slot状态信息存储在zookeeper/etcd
  • 发送slotsmgrttagslot而非migrate指令，slotsmgrttagslot执行时会随机获取一个key迁移，如key带有tag，则从上文中的skiplist获取所有key批量迁移

codis同样也是同步阻塞型的迁移操作。 在保持数据一致性方面，因为codis-server内核不维护slot的状态，所以一致性的保证落在了proxy组件上。codis-proxy在处理请求时，先判断key所在slot的状态，如slot处于迁移中，则向codis-server发起指定key迁移的命令，等key迁移完成后，codis-proxy转向目标的codis-server请求。做法简单，对redis内核修改较少，但同时也导致迁移慢，客户端卡住的时间较久。

3.2.3 阿里云redis 水平扩展原理

阿里云redis除了提供指定源、节点、slot外，还提供按节点的容量、slot的大小等考量参数动态分配slot，以最小粒度影响集群可用性作为分配原则。迁移大体步骤如下：

  • 步骤1): 由redis-config计算源、目标节点、slot
  • 步骤2): redis-config向redis-server发送迁移slot指令
  • 步骤3): redis-server启动状态机，分批量迁移key
  • 步骤4): redis-config定时检查redis-server并更新slot状态

与codis不同，阿里云redis在内核上同样维护了slot的信息，并且抛弃了codis迁移整个slot和redis cluster迁移单个key的做法，从内核上支持批量迁移，加快迁移速度。 阿里云redis迁移数据是异步的流程，不等待目标节点是否restore成功，由目标节点通知和源节点定时检查来验证是否成功。以此缩小同步阻塞对其他slot访问的影响。 同时也是因为迁移异步化，所以在保证数据一致性时，判断请求如果是写请求并且key存在且不在迁移的key列表中，走正常的写请求流程。其他数据一致性保证与redis4.0 cluster相同。 阿里云redis-server优化了迁移大key的流程，详情可见

3.3、其他

redis 4.0阿里云rediscodis内核热升级不支持支持不支持proxy热升级无proxy支持不支持slots槽数16384163841024密码不支持，需改redis-trib脚本支持支持，所有组件密码必须一致

阿里云的redis内核和proxy的热升级过程中均不断连接，对客户端无影响。

4、结束语

云数据库Redis版（ApsaraDB for Redis）是一种稳定可靠、性能卓越、可弹性伸缩的数据库服务。基于飞天分布式系统和全SSD盘高性能存储，支持主备版和集群版两套高可用架构。提供了全套的容灾切换、故障迁移、在线扩容、性能优化的数据库解决方案。欢迎各位购买使用:云数据库 Redis 版

支持 Partition 的 Redis 集群方案大致有几类：

1，客户端实现分片


分区的逻辑在客户端实现，由客户端自己选择请求到哪个节点。方案可参考一致性哈希，基于 Memcached 的 cache 集群一般是这么做，而这种方案通常适用于用户对客户端的行为有完全控制能力的场景。

2，中间件实现分片


有名的例子是 Twitter 的 Twemproxy，Redis 作者对其评价较高。一篇较旧的博客如下：Twemproxy, a Redis proxy from Twitter
另一个知名度较高的实现是 Codis，由豌豆荚的团队开发，作者

刘老师已经在前面的答案中推荐过了。

3，客户端服务端协作


官方的 Redis Cluster 实现就是采用这种方式，在这种方案下，客户端请求到达错误节点后不会被错误节点代理执行，而是被错误节点重定向至正确的节点。

那么，上面几种方案如何选择？

显然在客户端做分片是自定义能力最高的，优势在于，在不需要客户端服务端协作，以及没有中间层的条件下，每个请求的 roundtrip 时间是相对更小的，搭配良好的客户端分片策略，可以让整个集群获得很好的扩展性。当然劣势也很明显，用户需要自己对付 Redis 节点宕机的情况，需要采用更复杂的策略来做 replica，以及需要保证每个客户端看到的集群“视图”是一致的。

中间件的方案对客户端实现的要求是最低的，客户端只要支持基本的 Redis 通信协议即可，至于扩容、多副本、主从切换等机制客户端都不必操心，因此这种方案也很适合用来做“缓存服务”。

官方推出的协作方案也完整地支持了分片和多副本，相对于各种 proxy，这种方案假设了客户端实现是可以与服务端“协作”的，事实上主流语言的 SDK 都已经支持了。

所以，对于大部分使用场景来说，官方方案和代理方案都够用了，其实没必要太纠结谁更胜一筹，每种方案都有很多靠谱的公司在用。而官方方案具备详细的文档和Q&A，作者本人也在博客中写了很多设计思路，再加上比较成熟的实践经验，我想从这些方面考虑，无论是站在运维还是学习的角度，都是值得选择的。

twemproxy代理方案；

  • 大概概念是，它类似于一个代理方式，使用方法和普通redis无任何区别，设置好它下属的多个redis实例后，使用时在本需要连接redis的地方改为连接twemproxy，它会以一个代理的身份接收请求 并使用一致性hash算法，将请求转接到具体redis，将结果再返回twemproxy。
    使用方式简便(相对redis只需修改连接端口)，对旧项目扩展的首选，
    问题：twemproxy自身单端口实例的压力，
    使用一致性hash后，对redis节点数量改变时候的 计算值的改变，数据无法自动移动到新的节点。
  • 哨兵

4.在业务代码层实现 ， 起几个毫无关联的redis实例，在代码层，对key 进行hash计算，然后去对应的redis实例操作数据。 这种方式对hash层代码要求比较高，考虑部分包括，节点失效后的替代算法方案，数据震荡后的自动脚本恢复，实例的监控，等等。

posted @ 2018-01-11 08:00  活的潇洒80  阅读(706)  评论(0)  编辑  收藏  举报