一站式分布式缓存解决方案codisX

1 研究背景

分布式缓存是各大公司业务系统必不可少的组件，目前市面上开源的分布式缓存解决方案主要有redis cluster和codis，在进行了一系列调研之后，redis cluster现阶段的模块耦合使得我最后放弃了这一方案，转向了codis。在使用过程中，发现了一些codis的不足之处。因此笔者在官方codis的基础上（基于最新版本3.2.2），修改了源码，做出了codisX。

先说一下官方版本的codis解决的痛点，官方github地址 https://github.com/CodisLabs/codis

1. 真正的弹性伸缩，扩容时只需要在fe中添加server并且自动resharding，无需任何组件重启
2. fe中可以实时监控各个server的运行状态，也可以更改master和slave的角色
3. 兼容原生的redis操作，业务开发人员无需学习成本
4. 业务开发人员不需要考虑分片问题，就像使用单机一样使用codis
5. 不同的业务系统可以通过同一套zk的不同路径去区分（担心zk性能问题就多余了，codis正常运行的过程中，无论是proxy连接池还是dashboard都根本不会走zk的）

---

2 codisX的设计思路

codis的官方作者一开始是想要实现一个KV数据库，也就是强调数据一致性，是CP的系统，在一组server（包括master和slave）都宕机的情况下，服务是不可用的。但是很多场景缓存只是用来加速的，也就是说，对于缓存的需求应该是AP的，无需高度的一致性，而是需要满足高的可用性。在这种情况下，一组server是不需要slave的（我这么说不是说有slave不行，而是slave的存在没什么必要，有那个机器还不如去充当另一个group的master）。当一台server宕机又恢复之后数据取不到也无所谓。

基于以上思考，就要动手修改codis源码了。借鉴了cassandra的设计模式，在slot级别实现了一致性哈希，一个group的server宕机之后，请求会根据哈希环打到下一个节点上，根据墨菲定律，最坏的情况是下一个节点的server也挂了，因此在proxy的配置文件中，提供了最大重试次数的选项，如果超过了这个阈值还是失败，就向业务系统返回异常，由业务系统自行处理。至于你的系统对缓存的需求是CP还是AP的，只需要在dashboard的配置文件中修改一下配置，指定working mode就可以了。

# Set work mode for codis cluster (only accept 'CP' & 'AP',default is 'CP').
working_mode = "AP"

注意，在AP模式下，如下图所示配置各个group的权重，点击confirm，会按照一致性哈希自动分配

另外，codis的主从读写分离规则中，replica group是包含master的。对于redis这种本身就是最终一致性的工具，本来如果你考虑实现读写分离的时候，就表明你认为减轻master的压力比追求数据的强一致性要重要，因此在请求随机路由的情况下，如果还是可能打到master是不必要的，这一点在codisX中做了改进。

kubernetes应该是现在比较理想的容器管理解决方案了，在官方实现的kubernetes scale方案中，server的伸缩方案还是基于CP的考虑的，前面我们已经说过了，在AP的模式下，scale过程中，group中要一个slave属于浪费机器的举动。当然土豪请自动忽略这句话。因此修改了codis基于k8s的scale方案，在集群指定AP的工作模式下，扩容的时候，ReplicaController只会在新的group中放置一台server。当然这一切对于用户来说都是透明的，用户无需关心这一点，而是通过脚本自动识别的。

---

3 总结一下

codisX实现的新功能：

1. 可以提供CP和AP两种分布式缓存服务模式，无论你的业务系统对于把缓存当作数据库使用还是单纯为了加速访问，都可以满足你的需求
2. 修改了读写分离逻辑
3. 修改了基于kubernetes的scale方式，自动根据工作模式去修改扩容的方式，这一切对于运维人员或者用户来说是完全透明的
4. 其它一些小的修改

目前codisX运行在我们公司的推送和网关日志统计平台，每天日志量过亿，表现还是可以的。

github地址
https://github.com/AntonyWujiang/codisX

欢迎各位高手试用和理性吐槽，如果有问题的话，可以找我反馈，我也会进行一些日常的维护

说明
如有转载，请注明出处
https://blog.csdn.net/antony9118/article/details/80077163