Redis在豆荚中的使用历史记录为——个实例==’多个实例，业务代码为s Harding==’单个twemproxy==’多个twemproxy=’codis，豆荚自身开发的分布式Redis服务在使用大型Redis时，我们发现Redis仅限于多个方面，包括单机器内存限制、带宽限制、单一问题、无法动态扩展以及磁盘损坏时的数据保护。
Redis通常有三种使用方法：客户端静态分片和一致性散列：代理分片，即Twemproxy； 也有官方的Redis Cluster，但至今没有新版本。 之后，pbdlr更详细地分析了为什么不用Twemproxy和Redis Cluster :
Twemproxy :最大的打击是无法顺利扩展和缩小，即使更改配置也需要重新启动服务。 其次，不能运输。 甚至没有Dashboard。
Redis Cluster (公式) :非中心化设计、程序编写困难的代码有点可怕。 clusterProcessPacket函数有426行，人脑很难处理所有的状态切换。 正式版本晚了，等了四年； 目前缺乏最佳实践，没有人会写Redis Cluster的一些注意事项； 整个系统高度耦合，很难升级。
虽然有Tair、Couchbase等多种选择，但是如果需要更复杂更好的数据结构，Redis可以说是最佳选择。 因此，在Redis的基础上，豆荚设计了Codis，使之成为开源的。
Codis
既然重新设计了，Codis首先需要满足自动扩展和缩小的需要。 其次，必须避免单点故障和单点带宽不足，构建高可用性系统。 然后，必须在传统遗留系统的基础上，轻松将数据从Twemproxy迁移到Codis，实现良好的运输和监控。 在这些基础上，Codis的设计跃然纸上：
但是，新系统的开发并不是一件容易的事情，特别是复杂的分布式系统。 据pbdlr报道，当时只有三个团队，但他们考虑了几乎可以考虑的各种细节。
尽可能划分，以简化每个模块，同时使每个组件更容易升级只负责自己的Redis，并确定是否将其作为存储引擎Proxy的状态Redis故障判断提交到外部。 分布式系统生存的判定异常复杂，提供API并向外部调用，Redis Master丢失时，Slave状态、Proxy状态、group状态、lock、action等所有事情都用于Master的图形监视另一个争议摆在眼前： ——Proxy或Smart Client:Proxy有更好的监控和控制能力，而Smart Client也很难暴露后端信息，但升级起来很麻烦。 比较各种优劣后，他们最终选择了代理。 没有独特的东西。 codis开源后，推特共享称他们也基于代理的设计。
Codis主要是codisproxy (代码代理)、CODISmanager (代码配置)、CODISredis (代码服务器)和ZooKeeper四个组件
3358 www.Sina.com/http://www.Sina.com /客户端连接的Redis代理服务本身实现Redis协议，如本机redis(twemproxy ) 一个业务可以引入多个代码代理，本身是无状态的。
codis-proxyCodis上的管理工具。 支持添加/删除Redis节点、添加/删除代理节点、启动数据迁移等操作。 Codis-config附带http服务器，启动dashboard，用户可以在浏览器中观察codis集群的运行状态。
。Codis项目维护的Redis分支添加了对slot的支持和原子数据迁移指令。
codis-config。Codis依赖ZooKeeper存储数据路由表和codis-proxy节点的元信息，codis-config启动的命令通过ZooKeeper生存的每个codis-config节点
最后，pbdlr还介绍了Codis中迁移、锁定(rwlock )等操作的实现过程和原理，以及Twemproxy向Codis迁移的详细操作。 有关Codis的详细信息，请参见Clodis开源页面GitHub
微信号opendotNET，微信号公众号名称：欢迎来到dotnet跨平台。 扫描下面的二维码，或者收集下面的二维码关注一下吧。 长按下面的二维码图片，选择识别图的二维码。