codis

功能

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

最新 release 版本为 codis-3.2，codis-server 基于 redis-3.2.8

我们可以看到codis的proxy和group是多对多的关系，另外一个group就是一个backend。在某一个backend挂掉以后，不会自动将这个backend的slot的key的请求发给其他backend，这一点很危险，对于那些group只有一个master没有slave和sentinel的。当一个group下线以后需要手动迁移group的数据然后再rebalance。

codis-proxy的转发信息由codis dashboard控制
Codis Admin：集群管理的命令行工具。一般都直接在codis dashboard上操作
codis-dashboard提供管理和查询的http api，codis fe才是web ui

slot&zk

Codis 采用 Pre-sharding 的技术来实现数据的分片, 默认分成 1024 个 slots (0-1023), 对于每个key来说, 通过以下公式确定所属的 Slot Id : SlotId = crc32(key) % 1024。

每一个 slot 都会有一个且必须有一个特定的 server group id 来表示这个 slot 的数据由哪个 server group 来提供。数据的迁移也是以slot为单位的。

codis-dashboard是把slot的信息写到zk上面，由proxy自己去监听，这样每个proxy的数据都是最终一致的了

另外proxy也都会在zk注册，便于客户端选取proxy发送请求

proxy & group 的HA

因为 codis-proxy 是无状态的，可以比较容易的搭多个实例，达到高可用性和横向扩展。

对 Java 用户来说，可以使用基于 Jedis 的实现 Jodis ，来实现 proxy 层的 HA：

它会通过监控 zookeeper 上的注册信息来实时获得当前可用的 proxy 列表，既可以保证高可用性；
也可以通过轮流请求所有的proxy实现负载均衡。
如果需要异步请求，可以使用我们基于Netty开发的 Nedis。

对下层的 redis 实例来说，当一个 group 的 master 挂掉的时候，应该让管理员清楚，并手动的操作，因为这涉及到了数据一致性等问题（redis的主从同步是最终一致性的）。因此 codis 不会自动的将某个 slave 升级成 master。关于外部 codis-ha 工具（具体可以参考之前的章节），这是一个通过 codis-dashboard 开放的 RESTful API 实现自动切换主从的工具。该工具会在检测到 master 挂掉的时候主动应用主从切换策略，提升单个 slave 成为新的 master。

需要注意，codis 将其中一个 slave 升级为 master 时，该组内其他 slave 实例是不会自动改变状态的，这些 slave 仍将试图从旧的 master 上同步数据，因而会导致组内新的 master 和其他 slave 之间的数据不一致。因此当出现主从切换时，需要管理员手动创建新的 sync action 来完成新 master 与 slave 之间的数据同步（codis-ha 不提供自动操作的工具，因为这样太不安全了）。

redis sentinel

• 通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。

• 当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。
  多个sentinel之间会进行通信，只有多数的sentinel都认为这个master下线的时候才会统一切换某一个slave至master状态

codis-proxy监听sentinel实现转发到正确的master