Codis 的设计与实现 Part 2

多 Proxy 架构

在 Codis 的设计中, Proxy 被设计成无状态的,客户端连接任何一个 Proxy 都是一样的。而且每个 Proxy 启动的时候,会在 Zookeeper 上注册一个临时节点, 所以客户端甚至可以根据这个特性实现 HA (其实我在豌豆荚内部就写了一个基于 Jedis 的 Codis HA RoundRobinPool)

当然,这个设计带来的好处是,请求可以被负载均衡,而且在整个系统中不会出现单点。 但是,问题来了,由于 Codis 是动态扩缩容的功能的, 当 Codis 在进行数据迁移的过程中,如何保证任意一个 Proxy 都不会读到老的或者错误的数据?

解释这个问题之前,我想先介绍一下 Codis 的数据存储方式和关于数据迁移的一些前置知识:

  • 数据被根据key,分布在 1024 个 slot 中, slot 是一个虚拟的概念,数据存储在实际的多个 codis-server (codis 修改版的 redis-server) 中,每个 codis-server 负责一部分key-value数据, 哈希算法是 crc32(key) % 1024
  • 数据迁移是由 codis-config 发起的,在 codis-config 看来,数据迁移的最小单位是 slot
  • 对于 codis-server 来说,没有任何分布式逻辑在其中, 只是实现了几个关于数据传输的指令: slotsmgrtone, slotsmgrt…. 其主要的作用是:随机选取特定 slot 中的一个 key-value pair, 传输给另外一个 codis-server, 传输成功后,把本地的这个 key-value pair 删除, 注意, 这个整个操作是原子的。

所以,这就决定了 Codis 并不太适合 key 少,但是 value 特别大的应用, 而且你的 key 越少, value 越大,最后就会退化成单个 redis 的模型 (性能还不如 raw redis),所以 Codis 更适合海量 Key, value比较小 (<= 1 MB) 的应用。

为什么 codis-server 的数据迁移是一个个key的,而不是类似很多其他分布式系统,采用 replication 的方式? 我认为,对于 redis 这种系统来说,实现 replication 不太经济, 首先,你需要 rdb dump 吧? 在 redis 里面所有的操作严格来说都是串行的(单线程模型决定),所以dump数据是需要 fork 一个新进程的, 否则如果直接 SAVE 会阻塞唯一的主线程,同时还得考虑dump过程和传输过程中产生的新数据的同步的问题, 实现起来比较复杂。所以我们每次只原子的迁走一个 key,不会把主线程 block 住, redis 操作的是内存,批量的一次性写入和分多次set几乎没有区别(对于单机而言), 而且这个模型还避免了迁移过程中的数据更新同步的问题,因为由于迁移一个 key 的操作是原子的, 对于这个 redis-server 来说, 在完成这次迁移指令之前,是不会响应其他请求的。 所以保证了数据的安全。

一次典型的迁移流程:

  1. codis-config 发起迁移指令如 pre_migrate slot_1 to group 2

  2. codis-config 等待所有的 proxy 回复收到迁移指令, 如果某台 proxy 没有响应, 则标记其下线 (由于proxy启动时会在zk上注册一个临时节点, 如果这个proxy挂了, 正常来说, 这个临时节点也会删除, 在codis-config发现无响应后, codis-config会等待30s, 等待其下线, 如果还没下线或者仍然没有响应, 则codis-config 将不会释放锁, 通知管理员出问题了) 相当于一个2阶段提交

  3. codis-config 标记slot_1的状态为 migrate, 服务该slot的server group改为group2, 同时codis-config向group1的redis机器不断发送 SLOTSMGRT 命令, target参数是group2的机器, 直到group1中没有剩余的属于slot_1的key

  4. 迁移过程中, 如果客户端请求 slot_1 的 key 数据, proxy 会将请求转发到group2上, proxy会先在group1上强行执行一次 MIGRATE key 将这个键值提前迁移过来. 然后再到group2上正常读取

  5. 迁移完成, 标记slot_1状态为online

关键点:

  1. 所有的操作命令,都通过 Zookeeper 中转,所有的路由表,都放置在 ZooKeeper 中,确保任意一个 proxy 的视图都是一样的。

  2. codis-config 在实际修改slot状态之前,会确保所有的 proxy 收到这个迁移请求。

  3. 在客户端读取正在迁移的slot内的数据之前, 会强制在源redis是执行一下迁移这个key的操作。

这两点保证了,proxy 在读取数据的时候,总是能在迁移的目标机上命中这个 key。

这就是 Codis 如何进行安全的数据迁移的过程。

转载:http://0xffff.me/blog/2014/11/11/codis-de-she-ji-yu-shi-xian-part-2/

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值