Codis相比Redis Cluster的架构选择：无状态Proxy+可插拔存储

Redis Cluster和Codis几乎同期发布正式版，但架构思路截然不同，代表了分布式Redis方案的两条路线。Redis Cluster把数据存储模块和分布式逻辑模块耦合在一起——好处是部署异常简单，all-in-the-box、不需要额外的概念、组件和依赖；但坏处是很难对业务做无痛升级：如果分布式逻辑本身出现严重Bug，除了滚动重启整个集群外没有别的好办法，这对运维很不友好；同时它对协议做了较大修改，对已经大规模落地的现有Redis客户端不友好，让业务方全部换客户端也不现实。Codis选择了不同的路线：用一层无状态的Proxy承载分布式逻辑，底层存储引擎依然是Redis本身（基于Redis 2.8.13打了一些小patch），数据的分布状态存储在ZooKeeper（或etcd）里，让底层数据存储变成一个可插拔的部件——这套架构的好处是各个部件都能动态水平扩展，尤其Proxy是无状态的，坏处是请求经过Proxy多了一次网络交互、看上去性能会下降一些。但这个”性能下降”不该被孤立地看待：因为Proxy本身可以动态水平扩展，整个服务的QPS并不由单个Proxy的性能决定，生产环境里配合LVS/HA Proxy或Jodis做负载均衡，每个Proxy都是等价的、可以随时加减。这个对比揭示了一条通用的架构取舍：Redis Cluster用”少一层网络跳转”换来了更高的单次请求性能，但代价是分布式逻辑和存储引擎强耦合、难以独立升级；Codis用”多一层Proxy”换来了存储引擎和分布式逻辑的解耦、双方都可以独立水平扩展，代价是多了一跳网络开销——选哪条路线本质上是在”极致的单次请求性能”和”运维灵活性/独立扩展能力”之间做取舍，而不存在绝对更优的一方。