Redis Cluster架构优化
在《全面剖析Redis Cluster原理和应用》中,我们已经详细剖析了现阶段Redis Cluster的缺点:
- 无中心化架构
- Gossip消息的开销
- 不停机升级困难
- 无法根据统计区分冷热数据
- 客户端的挑战
- Cluster协议支持
- 连接和路由表的维护开销
- MultiOp和Pipeline支持有限
- Redis实现问题
- 不能自动发现
- 不能自动Resharding
- 无监控管理UI
- 最终一致性和“脑裂”问题
- 数据迁移以Key为单位,速度较慢
- 数据迁移没有保存进度,故障时不能恢复
- Slave“冷备”,不能缓解读压力
当然之前也说过了:“这与Redis的设计初衷有关,毕竟作者都已经说了,最核心的设计目标就是性能、水平伸缩和可用性”。但综合来看,要想在生产环境中使用Redis Cluster,我们还是有一些工作要做的。本文就从宏观层面上,列举一些架构优化的参考方案。
1.P2P架构副作用
1.1 Gossip通信开销
Gossip消息的通信开销是P2P分布式系统带来的第一个副作用。有一篇关于Gossip通俗易懂的文章《Life in a Redis Cluster: Meet and Gossip with your neighbors》。Redis为集群操作的消息通信单独开辟一个TCP通道,交换二进制消息:
- PING/PONG:Cluster的心跳,每个结点每秒随机PING几个结点。结点的选择方法是:超过
cluster-node-timeout
一半的时间还未PING过或未收到PONG的结点,所以这个参数会极大影响集群内部的消息通信量。心跳包除了结点自己的数据外,还包含一些其他结点(集群规模的1/10)的数据,这也是“Gossip流言”的含义。 - MEET/PONG:只有MEET后的受信结点才能加入到上面的PING/PONG通信中。
关于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,像防洪堤坝一样将危险隔离在外。