本文共 1707 字，大约阅读时间需要 5 分钟。
| 在《全面剖析Redis Cluster原理和应用》中，我们已经详细剖析了现阶段Redis Cluster的缺点：
当然之前也说过了：“这与Redis的设计初衷有关，毕竟作者都已经说了，最核心的设计目标就是性能、水平伸缩和可用性”。但综合来看，要想在生产环境中使用Redis Cluster，我们还是有一些工作要做的。本文就从宏观层面上，列举一些架构优化的参考方案。 1.P2P架构副作用1.1 Gossip通信开销 Gossip消息的通信开销是P2P分布式系统带来的第一个副作用。有一篇关于Gossip通俗易懂的文章《Life in a Redis Cluster: Meet and Gossip with your neighbors》。Redis为集群操作的消息通信单独开辟一个TCP通道，交换二进制消息：
关于Gossip的问题不可避免，我们只能通过参数调整和优化，在通信效率和开销之间找到一个平衡点。因为笔者还未搭建过大规模的Redis Cluster集群，关于集群的性能和参数调优还不能给出建议，留到积累足够经验再做整理吧。 1.2 不停机升级困难以Nginx为例，修改配置甚至升级版本都不需要停机，Master会逐一启动新的Worker实例去替代旧的Worker。对于单机版的Redis，我们也可以用类似的方式实现的。但目前不知道Redis Cluster或者其他P2P分布式系统像Cassandra，是否有比较好的方案。 1.3 冷热数据无法区分由于集群内结点都是对等的，所以像数据热度这种整体的统计数据就无处存放。当内存有限时，要想实现层次化存储，将冷数据Swap到慢存储如磁盘上时，就变得有些棘手了！ 解决方法就是计算机界号称万能的“增加中间层”方法。增加一层Proxy，负责做数据统计、Swap甚至L1缓存。关于冷热数据的统计和处理，请参考《微博CacheService架构浅析》 2.客户端的挑战 Redis Cluster的引入会给客户端带来一些挑战。要么“勇敢面对”，通过引入最新的支持Cluster协议的Jedis客户端，再加以改造来应对这些挑战。要么增加Proxy，像防洪堤坝一样将危险隔离在外。 2.1 Cluster协议开发对于Java，最主流的Jedis客户端已经早早开始支持Cluster协议了，但仔细看了一下，貌似处理集群中结点Failover时有些问题。Slave替换上来了，Jedis的确可以根据”MOVED”消息更新Slot与结点的对应关系，但是：
不知道这算不算Jedis由来已久的问题了。因为之前Jedis就是只支持要么用分片连接池，要么用Sentinel连接池，没有两者的结合！还好有热心的程序员“出手相助”，详见《Jedis分片Sentinel连接池实验》。上面两个问题对应的源码看得不是很细，突然想到的这两个问题，要是说的不对还请指正！ |
转载地址：http://guiea.baihongyu.com/