redis集群模式

redis集群模式主要分为服务端集群和客户端分片及代理分片几种

客户端分片

这实际上是一种静态分片技术。Redis实例的增减,都得手工调整分片程序。基于此分片机制的开源产品,现在仍不多见。这种方式下,可运维性较差。出现故障,定位和解决都得研发和运维配合着解决,故障时间变长。

目前有的实现是Jedis的Redis Sharding,参考:https://blog.csdn.net/java20150326/article/details/70945732

优缺点

  • 客户端sharding技术其优势在于服务端的Redis实例彼此独立,相互无关联,每个Redis实例像单服务器一样运行,非常容易线性扩展,系统的灵活性很强。
  • 其不足之处在于由于sharding处理放到客户端,规模进步扩大时给运维带来挑战。服务端Redis实例群拓扑结构有变化时,每个客户端都需要更新调整。连接不能共享,当应用规模增大时,资源浪费制约优化。

基于服务端sharding

官方新推出的Redis Cluster。服务端sharding的Redis Cluster其优势在于服务端Redis集群拓扑结构变化时,客户端不需要感知,客户端像使用单Redis服务器一样使用Redis集群,运维管理也比较方便。正式版推出时间不长,系统稳定性、性能等都需要时间检验,尤其在大规模使用场合。

代理分片

twemproxy就是这样一种利用中间件做sharding的技术。twemproxy后端不仅支持redis,同时也支持memcached,这是twitter系统具体环境造成的。

优缺点:

  • 由于使用了中间件,twemproxy可以通过共享与后端系统的连接,降低客户端直接连接后端服务器的连接数量。同时,它也提供sharding功能,支持后端服务器集群水平扩展。统一运维管理也带来了方便。
  • twitter 在2015年就不再贡献Twemproxy代码,它最大的缺点是一个静态的Sharding 策略,随着业务的增长也几乎没有办法进行动态的扩缩容。Twemproxy更加像服务器端静态sharding。有时为了规避业务量突增导致的扩容需求,甚至被迫新开一个基于Twemproxy的Redis集群。
  • 业务量突增,需增加Redis服务器;业务量萎缩,需要减少Redis服务器。但对Twemproxy而言,基本上都很难操作。
  • Twemproxy另一个痛点是,运维不友好,甚至没有控制面板。

codis

Codis 是一个分布式 Redis 解决方案, 对于上层的应用来说, 连接到 Codis Proxy 和连接原生的 Redis Server 没有显著区别 (不支持的命令列表), 上层应用可以像使用单机的 Redis 一样使用, Codis 底层会处理请求的转发, 不停机的数据迁移等工作, 所有后边的一切事情, 对于前面的客户端来说是透明的, 可以简单的认为后边连接的是一个内存无限大的 Redis 服务。

codis官方地址:https://github.com/wandoulabs/codis

架构:

特点:

  1. Codis引入了Group的概念,每个Group包括1个Redis Master及至少1个Redis Slave,这是和Twemproxy的区别之一。这样做的好处是,如果当前Master有问题,则运维人员可通过Dashboard“自助式”切换到Slave,而不需要小心翼翼地修改程序配置文件。
  2. 为支持数据热迁移(Auto Rebalance),出品方修改了Redis Server源码,并称之为Codis Server。
  3. Codis采用预先分片(Pre-Sharding)机制,事先规定好了,分成1024个slots(也就是说,最多能支持后端1024个Codis Server),这些路由信息保存在ZooKeeper中。
  4. Codis仅负责维护当前Redis Server列表,由运维人员自己去保证主从数据的一致性。
  5. 无缝迁移Twemproxy。
  6. 兼容所有语言的客户端,支持Java程序的HA即Jodis。
  7. 支持Pipeline。
  8. 能支持GB到TB级别的水平扩展能力。
  9. 也能提供Redis同样的高吞吐和低延迟的优势。
  10. 更多数据结构的支持。

与Redis Cluster的比较

与Redis Cluster和Twemproxy的比较

原文发布于微信公众号 - 开发架构二三事(gh_d6f166e26398)

原文发表时间:2019-09-06

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券