架构师必备:Redis的几种集群方案

结论

有以下几种Redis集群方案,先说结论:

  • Redis cluster:应当优先考虑使用Redis cluster。
  • codis:旧项目如果仍在使用codis,可继续使用,但也推荐迁移到Redis cluster。
  • twemproxy:不建议使用,与codis同为proxy方案,但不如codis(twemproxy不能平滑地扩容)。
  • 客户端分片:应当禁止使用,因为扩容复杂,如果2个服务同时读写,其中一个修改了路由,另一个不修改会有问题。

下面重点介绍Redis cluster和codis。

Redis cluster原理

架构

架构师必备:Redis的几种集群方案_第1张图片

是官方支持的Redis集群方案:

  • 去中心化架构,不依赖外部存储,每个节点都有槽位信息、以及一部分数据,各节点之间使用gossip协议交互信息
  • 划分为16384个slot槽位,每个key按照分片规则,对key做crc16 % 16384得到slot id
  • 每个Redis节点存储了一部分槽位数据,各个Redis节点共同分担16384个slot槽位
  • 客户端需遵守Redis cluster规范读写数据,客户端连接集群时,会得到一份集群的槽位配置信息,客户端本地缓存了slot到node的映射关系,以便直接定位到对应的Redis节点

    • 用key计算出slot
    • 通过本地缓存的slot到node映射关系(某个slot范围映射到某个node),用slot得出node
    • 请求对应的node节点,如果key对应的槽位在Redis节点存储的各槽位中,则查询结果
    • 如果key对应的槽位不在Redis节点存储的各槽位中(即key所在的槽位不归该节点管理),则返回moved <节点> 提示客户端再次请求指定的节点,并更新本地映射关系
    • 如果请求的key对应槽位正在迁移,则返回ask <节点> 提示客户端再次请求指定的节点
  • 主库读写,从库用于高可用备份、一般不用来承担读请求:主从同步通过指令流、环形数组来做增量同步,通过RDB来做全量同步

优点

  • 官方支持的集群方案,能使用最新feature
  • 性能好,无多余网络开销
  • 无一致性问题,读写请求都走主节点
  • 槽位更精细,16384(2^14)相比于codis的1024

缺点

  • 如果是从旧版不支持集群的Redis升级而来,需做较大改造,把传统的Jedis client需替换成智能客户端来维护key到slot的映射关系,如lettuce
  • 官方是最小使用原则,没有易用的扩容、迁移工具,需要寻找社区提供的易用界面,或自行研发
  • 迁移过程中性能可能受影响,有3次请求:首次get得到ask返回、再次asking确认指定节点是否有槽位、最后get

codis原理

架构

架构师必备:Redis的几种集群方案_第2张图片

是Go语言编写的Redis proxy集群方案:

  • codis-proxy作为上层proxy,负责路由请求至底层的Redis分片。client与proxy交互,可以把proxy当作普通的Redis实例一样,因为codis-proxy实现了Redis协议,API保持一致。
  • Redis分片是一个codis-group,包括了多个codis-server,其中有1个主节点、n个从节点,用来作读写分离,主节点承担写请求,从节点分摊读请求。各个分片的Redis实例是独立的,互不感知。codis-server与普通Redis实例的区别是,在Redis的基础上扩展实现了slot槽的功能,用于扩容、数据迁移。
  • 分片规则:对key做crc32 % 1024
  • 强依赖zookeeper,来存储节点槽位信息。
  • codis-dashboard、codis-fe是集群运维工具。

优点

  • 客户端无需感知背后细节,使用起来跟Redis单实例无明显区别(除部分命令不支持)
  • 平滑扩容,运维操作简单,有易于使用的web界面

缺点

  • 是在Redis官方未支持集群方案之前的可选方案,目前已停止更新
  • proxy会带来额外的网络开销,请求链路多了一层
  • 读写分离可能出现不一致的问题,也需要评估请求读写比
  • 需要额外维护zookeeper

你可能感兴趣的:(缓存redis架构)