共计 1599 个字符，预计需要花费 4 分钟才能阅读完成。
论断
有以下几种 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
正文完