论断

有以下几种Redis集群计划，先说论断：

  • Redis cluster：该当优先思考应用Redis cluster。
  • codis：旧我的项目如果仍在应用codis，可持续应用，但也举荐迁徙到Redis cluster。
  • twemproxy：不倡议应用，与codis同为proxy计划，但不如codis（twemproxy不能平滑地扩容）。
  • 客户端分片：该当禁止应用，因为扩容简单，如果2个服务同时读写，其中一个批改了路由，另一个不批改会有问题。

上面重点介绍Redis cluster和codis。

Redis cluster原理

架构

是官网反对的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原理

架构

是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