38 | 通信开销：限制Redis Cluster规模的关键因素

看到 Gossip 协议，第一时间想到了《人类简史》中说的：八卦是人类进步的动力，但是集群超过一定规模时，八卦的作用就十分有限了。

可以划分管理面和数据面，集群通信走单独的网络

如果采用类似 Codis 保存 Slot 信息的方法，把集群实例状态信息和 Slot 分配信息保存在第三方的存储系统上（例如Zookeeper），这种方法会对集群规模产生什么影响？ 由于 Redis Cluster 每个实例需要保存集群完整的路由信息，所以每增加一个实例，都需要多一次与其他实例的通信开销，如果有 N 个实例，集群就要存储 N 份完整的路由信息。而如果像 Codis 那样，把 Slot 信息存储在第三方存储上，那么无论集群实例有多少，这些信息在第三方存储上只会存储一份，也就是说，集群内的通信开销，不会随着实例的增加而增长。当集群需要用到这些信息时，直接从第三方存储上获取即可。 Redis Cluster 把所有功能都集成在了 Redis 实例上，包括路由表的交换、实例健康检查、故障自动切换等等，这么做的好处是，部署和使用非常简单，只需要部署实例，然后让多个实例组成切片集群即可提供服务。但缺点也很明显，每个实例负责的工作比较重，如果看源码实现，也不太容易理解，而且如果其中一个功能出现 bug，只能升级整个 Redis Server 来解决。 而 Codis 把这些功能拆分成多个组件，每个组件负责的工作都非常纯粹，codis-proxy 负责转发请求，codis-dashboard 负责路由表的分发、数据迁移控制，codis-server 负责数据存储和数据迁移，哨兵负责故障自动切换，codis-fe 负责提供友好的运维界面，每个组件都可以单独升级，这些组件相互配合，完成整个集群的对外服务。但其缺点是组件比较多，部署和维护比较复杂。 在实际的业务场景下，我觉得应该尽量避免非常大的分片集群，太大的分片集群一方面存在通信开销大的问题，另一方面也会导致集群变得越来越难以维护。而且当集群出问题时，对业务的影响也比较集中。建议针对不同的业务线、业务模块，单独部署不同的分片集群，这样方便运维和管理的同时，出现问题也只会影响某一个业务模块。

集群的规模应该是可以进一步扩大的。因为集群的信息保存在了第三方存储系统上，意味着redis cluster内部不用再沟通了，这将节省下大量的集群内部的沟通成本。当然就整个集群而言部署、维护也会更加复杂，毕竟引入了一个第三方组件来管理集群。

约到后面，评论的人越少，看来坚持到最后的人不多啊~~

其实集群不要大，大了通讯是个问题同样后期维护也是个很大的麻烦；不同业务的redis集群区分开来，这样每个集群不至于太大，也不至于一个集群出问题影响到别的业务；

Gossip 协议还有很多有意思的东西，可以参照这篇： 病毒传播：全靠 Gossip 协议： http://www.passjava.cn/#/92.%E5%88%86%E5%B8%83%E5%BC%8F/08.Gossip%E5%8D%8F%E8%AE%AE

用Gossip协议管理配置和Zookeeper统一存储配置信息各有利弊。 Gossip协议在节点间传递配置让系统简单，而且发生网络故障时自行恢复能力更强一些，但通讯效率随着网络节点的增加而降低； Zookeeper统一管理配置，通讯效率无论节点多少都比较高，但让系统架构更复杂故障点增多，对抗网络故障时自行恢复能力差一些。 但其实无论哪种方式，节点太多了都会更加难以管理维护，出现问题影响面也更难以控制，不推荐。 但其实另一个极端，就是单个实例性能特别高，存储特别多数据也不推荐，同样也是更容易出问题，出现问题影响面太大，不推荐。

今天这个话题应该有点类似屠龙之技，菜鸟如我，什么时候才能有机会运维 100 个以上实例的 Redis Cluster。 Gossip 协议还挺有意思，名字也比较形象。如果翻译成中文，是叫“八卦协议”么？好像容易引起误解。“流言蜚语协议”、“风闻协议”？ 一个 ping 消息大概是 104 字节，1000 个实例的 Redis 集群一个 Gossip 消息大概是 12KB，ping-pong 往返，24KB。再加上实例间的通信，那么集群中用于服务正常请求的带宽就会被占用。在这种情况下，是不是采用类似于 Codis 的集中式管理更合适？ 将 cluster-node-timeout 从 15 秒调整到 20 或 25 秒，大概能减少 1/3 到 2/3 的实例间通信流量（不知道这个计算是否正确） PING 消息发送数量 = 1 + 10 * 实例数（最近一次接收 PONG 消息的时间超出 cluster-node-timeout/2） 估计最后还是要靠 tcpdump 来分析实例间的网络带宽变化情况，然后再找出合适的 cluster-node-timeout。但是业务流量经常会有变化，增加了调优的难度。 对于课后题，如果是 Codis 模式，将集群实例状态信息和 Slot 分配信息保存在 Zookeeper 上，那么实例太多之后，查询分配信息的时间也会比较长，另外实时保存实例状态信息也比较难。

这种方法会将所有实例之间的两两通信，转换成实例和第三方服务器之间的单一通信，能大幅减少通信次数，从而减少集群运行所占用的网络带宽，实现更大规模的集群。