我们都知道 Redis 是单机单进程的, 在之前的测试中, 我们也知道 Redis 的单机性能是有限的, 并且高性能的机器其实非常昂贵. 一个好汉三个帮, 分布式系统正是利用了多台普通计算器从而被大量互联网公司所使用, 今天我们来聊一聊 Redis 集群的一种解决方案 --Codis.
Codis,GitHub 上面近万 star, 是一款由中国人开源的 Redis 集群解决方案, 由前豌豆夹团队提供. Codis, 它是一款 Redis 的 Proxy, 主要负责把 Redis 的请求分发到不同的 Redis 实例当中.
我们从一次 get 请求来解释一下, Codis 是如何工作的. 因为 Codis 代理了 Redis 服务, 所以我们发起请求的时候, 并不是请求到 Redis-server 所在的机器上, 而是到 Codis 机器上, Codis 机器再根据一定的路由规则进行分发, 最终请求到 Redis-Server 的机器上, 也就是说, 如果我们使用一个 mget 请求, 可能会到多台机器上.
很显然, 这样子 Codis 也会存在单点问题, 好在 Codis 是一个无状态的服务, 所以我们可以同时部署多个 Codis 实例.
Codis 是如何把对应的 key 分配到不同机器的呢? 奥秘就在于 Codis 的 Slot,Codis 切分出 1024(可配置) 个 Slot, 每个 Slot 会绑定不同的 Redis 实例, 这里为什么要切分到 1024 个呢? 这是一个不错的思考题? 可以从扩容缩容方向进行考虑.
那么不同的 Codis 实力是如何同步 Slot 的数据呢? Codis 的方法非常简单粗暴, 那便是使用 ZooKeeper.ZooKeeper 不是发现服务么? 怎么还能用来存储数据? ZooKeeper 其实为每个目录提供了 1M 的存储空间, 通过 Quorum 的 2pc 机制来做数据一致性. 所以, ZooKeeper 可以偷偷用来做数据小, 吞吐不是那么大的数据存储.
Codis 提供一个 Dashboard 给用户编辑 Slot 的情况, 当用户编辑的时候, 会由 Zookeeper 分发给所有的 Codis 实例. 优点
Codis 非常的简单, 无论是理解上, 问题排查上还是部署上, 都非常的简单. 他把一些分布式一致性的东西交给了另外的开源方案 Zookeeper 去解决, 自身非常轻量级.
缺点
由于 Codis 的数据是落在多台机器上的, 所以, Redis 的事务功能就不能使用了, 对于批量查询接口, Codis 需要到多台机器上去获取结果, 这就不能保证数据的一致性. 会存在这样的情况, 使用 Codis 同时获取 key1 与 key2, 同时 Update 两者的值, 可能获取到的 Value1 是新版本, 而 Value2 为旧版本.
Codis 会对 Slot 进行数据迁移, 如果 key-value 的数据太小太大的话, 就会影响迁移的效率, 所以 Codis 官方推荐 Codis 的 key-value 大小不要超过 1M.
由于 Codis 不是 Redis 的官方项目, 所以每当 Redis 发布新版本的时候, Codis 都会瑟瑟发抖, 随着 Redis 退出自己的亲儿子 Redis-Cluster,Codis 的竞争力都在减弱.
今天我们对 GitHub 上面 10kstar 的 Codis 就介绍到这里, 如果你有兴趣, 欢迎关注我, 我们后面再继续分析, 谈一谈 Codis 中是如何做数据迁移的.
来源: http://news.51cto.com/art/201906/598037.htm