实时消息RTM| 多活架构中的数据一致性问题

一，容灾方案

之前介绍过RTM的系统架构设计，其中有说到我们的容灾设计的是双活和多活。有很多小伙伴问到为什么不采用主从架构设计，以及多活容灾怎么做到数据一致性等问题。这里我们针对容灾和多活设计进行详细介绍。

容灾的方案有很多，最常见的就是主备容灾，最初版本我们也采用了主机+冷备机容灾模式：Client正常与Master连接进行通信，正常情况下只有主机提供服务；在主机出故障时，仲裁服务切换主备，原来的主机下线变成备机，原备机变成主机后为Client提供服务。

一主机一备机的模型设计简单，并且具有不错的可用性——毕竟主备两台机器同时不可用的概率极低，相信很多后台系统也采用了类似的容灾策略。

主备容灾存在一些明显的缺陷，比如备机闲置导致有一半的空闲机器；比如主备切换的时候，备机在瞬间要接受主机所有的请求，容易导致备机过载。既然一主一备容灾存在这样的问题，为什么还有大量的公司采用这种容灾模型？事实上，架构的选择往往跟项目背景有关，大多数情况项目需要的机器数少，机器冗余不是主要问题；其次主备架构简单稳定，可以快速开发，快速上线。

由于RTM系统对并发的要求非常高，同时由于项目对设备的使用率要求较高，所以我们采用了多活架构。

多活架构中每台机器都能为客户端提供服务，如果其中一台宕机或发生故障，Client只需要连接相同区域内其他的服务即可。多活架构可是使得机器的利用率最大化，降低服务运营的成本，同时对于运维来说也相对简单，当发生流量峰值时只需要平行增加机器即可，当流量较低时，可以减少机器；动态增加或减少机器对于成本的控制非常有效。多活架构看似非常美好，对于技术人员来说使