Codis——分布式Redis服务的解决方案

 Codis——分布式Redis服务的解决方案

 

以前介绍过的 Twemproxy 是一种Redis代理，但它不支持集群的动态伸缩，而codis则支持动态的增减Redis节点；另外，官方的redis 3.0开始支持cluster。

  

codis和twemproxy最大的区别有两个：

• codis支持动态水平扩展，对client彻底透明不影响服务的状况下能够完成增减redis实例的操做；
• codis是用go语言写的并支持多线程，twemproxy用C并只用单线程。 后者又意味着：codis在多核机器上的性能会好于twemproxy；codis的最坏响应时间可能会由于GC的STW而变大，不过go1.5发布后会显著下降STW的时间；若是只用一个CPU的话go语言的性能不如C，所以在一些短链接而非长链接的场景中，整个系统的瓶颈可能变成accept新tcp链接的速度，这时codis的性能可能会差于twemproxy。

 

codis和redis cluster的区别：

redis cluster基于smart client和无中心的设计，client必须按key的哈希将请求直接发送到对应的节点。这意味着：使用官方cluster必需要等对应语言的redis driver对cluster支持的开发和不断成熟；client不能直接像单机同样使用pipeline来提升效率，想同时执行多个请求来提速必须在client端自行实现异步逻辑。 而codis因其有中心节点、基于proxy的设计，对client来讲能够像对单机redis同样去操做proxy（除了一些命令不支持），还能够继续使用pipeline而且若是后台redis有多个的话速度会显著快于单redis的pipeline。同时codis使用zookeeper来做为辅助，这意味着单纯对于redis集群来讲须要额外的机器搭zk，不过对于不少已经在其余服务上用了zk的公司来讲这不是问题：）

 

 

---

 

 

Codis 是豌豆荚公司开发的一个分布式 Redis 解决方案，用Go语言开发的。对于上层的应用来讲，链接到 Codis Proxy 和链接原生的 Redis Server 没有明显的区别 （不支持的命令列表），Codis 底层会处理请求的转发，不停机的数据迁移等工做。全部后边的一切事情，对于前面的客户端来讲是透明的，能够简单的认为后边链接的是一个内存无限大的 Redis 服务。

Codis 由四部分组成:

• Codis Proxy (codis-proxy)，处理客户端请求，支持Redis协议，所以客户端访问Codis Proxy跟访问原生Redis没有什么区别；
• Codis Dashboard (codis-config)，Codis 的管理工具，支持添加/删除 Redis 节点、添加/删除 Proxy 节点，发起数据迁移等操做。codis-config 自己还自带了一个 http server，会启动一个 dashboard，用户能够直接在浏览器上观察 Codis 集群的运行状态；
• Codis Redis (codis-server)，Codis 项目维护的一个 Redis 分支，基于 2.8.21 开发，加入了 slot 的支持和原子的数据迁移指令；
• ZooKeeper/Etcd，Codis 依赖 ZooKeeper 来存放数据路由表和 codis-proxy 节点的元信息，codis-config 发起的命令都会经过 ZooKeeper 同步到各个存活的 codis-proxy；

 

Codis 支持按照 Namespace 区分不一样的产品，拥有不一样的 product name 的产品，各项配置都不会冲突。

 

Codis 采用 Pre-sharding 的技术来实现数据的分片，默认分红 1024 个 slots (0-1023)，对于每一个key来讲，经过如下公式肯定所属的 Slot Id：

SlotId = crc32(key) % 1024

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

 

 

 

---

 

安装与部署

1. 安装go；
2. 安装codis

   go get -u -d github.com/CodisLabs/codis
   cd $GOPATH/src/github.com/CodisLabs/codis
   make

    

3. 安装zookeeper；
4. 启动dashboard

   bin/codis-config dashboard

    

5. 初始化slots，在zk上建立slot相关信息

   bin/codis-config slot init

    

6. 启动codis-redis，跟官方redis server方法同样；
7. 添加redis server group，每一个 Group 做为一个 Redis 服务器组存在，只容许有一个 master, 能够有多个 slave，group id 仅支持大于等于1的整数。如: 添加两个 server group, 每一个 group 有两个 redis 实例，group的id分别为1和2， redis实例为一主一从。

8. bin/codis-config server add 1 localhost:6379 master
   bin/codis-config server add 1 localhost:6380 slave
   bin/codis-config server add 2 localhost:6479 master
   bin/codis-config server add 2 localhost:6480 slave

    

9. 设置server group 服务的 slot 范围，如设置编号为[0, 511]的 slot 由 server group 1 提供服务, 编号 [512, 1023] 的 slot 由 server group 2 提供服务

   bin/codis-config slot range-set 0 511 1 online
   bin/codis-config slot range-set 512 1023 2 online

    

10. 启动codis-proxy，

    bin/codis-proxy -c config.ini -L ./log/proxy.log  --cpu=8 --addr=0.0.0.0:19000 --http-addr=0.0.0.0:11000

    刚启动的 codis-proxy 默认是处于 offline状态的, 而后设置 proxy 为 online 状态, 只有处于 online 状态的 proxy 才会对外提供服务

    bin/codis-config -c config.ini proxy online <proxy_name>  <---- proxy的id, 如 proxy_1

     

 

 

 

 

 

---

 

数据迁移（migrate）

安全和透明的数据迁移是 Codis 提供的一个重要的功能，也是 Codis 区别于 Twemproxy 等静态的分布式 Redis 解决方案的地方。

数据迁移的最小单位是 key，咱们在 codis redis 中添加了一些指令，实现基于key的迁移，如 SLOTSMGRT等 (命令列表)，每次会将特定 slot 一个随机的 key 发送给另一个 codis redis 实例，这个命令会确认对方已经接收，同时删除本地的这个 k-v 键值，返回这个 slot 的剩余 key 的数量，整个操做是原子的。

在 codis-config 管理工具中，每次迁移任务的最小单位是 slot。如: 将slot id 为 [0-511] 的slot的数据，迁移到 server group 2上，--delay 参数表示每迁移一个 key 后 sleep 的毫秒数，默认是 0，用于限速。

bin/codis-config slot migrate 0 511 2 --delay=10

迁移的过程对于上层业务来讲是安全且透明的，数据不会丢失，上层不会停止服务。

注意，迁移的过程当中打断是能够的，可是若是中断了一个正在迁移某个slot的任务，下次须要先迁移掉正处于迁移状态的 slot，不然没法继续 (即迁移程序会检查同一时刻只能有一个 slot 处于迁移状态)。

 

 

自动再平衡（auto rebalance）

Codis 支持动态的根据实例内存，自动对slot进行迁移，以均衡数据分布

bin/codis-config slot rebalance

要求:

• 全部的codis-server都必须设置了maxmemory参数；
• 全部的 slots 都应该处于 online 状态, 即没有迁移任务正在执行；
• 全部 server group 都必须有 Master；

 

 

高可用（HA）

由于codis的proxy是无状态的，能够比较容易的搭多个proxy来实现高可用性并横向扩容。

对Java用户来讲，可使用通过咱们修改过的Jedis，Jodis ，来实现proxy层的HA。它会经过监控zk上的注册信息来实时得到当前可用的proxy列表，既能够保证高可用性，也能够经过轮流请求全部的proxy实现负载均衡。若是须要异步请求，可使用咱们基于Netty开发的Nedis。

对下层的redis实例来讲，当一个group的master挂掉的时候，应该让管理员清楚，并手动的操做，由于这涉及到了数据一致性等问题（redis的主从同步是最终一致性的）。所以codis不会自动的将某个slave升级成master。 不过咱们也提供一种解决方案：codis-ha。这是一个经过codis开放的api实现自动切换主从的工具。该工具会在检测到master挂掉的时候将其下线并选择其中一个slave提高为master继续提供服务。

须要注意，codis将其中一个slave升级为master时，该组内其余slave实例是不会自动改变状态的，这些slave仍将试图从旧的master上同步数据，于是会致使组内新的master和其余slave之间的数据不一致。由于redis的slave of命令切换master时会丢弃slave上的所有数据，重新master完整同步，会消耗master资源。所以建议在知情的状况下手动操做。使用 codis-config server add <group_id> <redis_addr> slave 命令刷新这些节点的状态便可。codis-ha不会自动刷新其余slave的状态。