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

Posted anyRTC

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了实时消息RTM| 多活架构中的数据一致性问题相关的知识,希望对你有一定的参考价值。

一,容灾方案

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

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

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

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

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

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

二,一致性算法

一致性就是数据保持一致,在分布式系统中,可以理解为多个节点中数据的值是一致的。

1,为什么需要一致性
a)数据不能存在单个节点(主机)上,否则可能出现单点故障。

b)多个节点(主机)需要保证具有相同的数据。

c)一致性算法就是为了解决上面两个问题。


2,一致性的分类
a)强一致性
说明:保证系统改变提交以后立即改变集群的状态。
模型:
Paxos
Raft(muti-paxos)
ZAB(muti-paxos)

b)弱一致性
说明:也叫最终一致性,系统不保证改变提交以后立即改变集群的状态,但是随着 时间的推移最终状态是一致的。
模型:
DNS系统
Gossip协议
具体的一致性算法的介绍大家可以自行搜索,其中的一些思想非常值得去深究,都是大牛们智慧的结晶。

RTM系统中有个非常经典的场景,一个群组里面有N个人分布在不同的区域,这时候有些人同时对群组的某一个相同属性进行修改;属性的修改需要通知群里的所有人,这个时候如果没有数据一致性的保证,有极大的可能会导致群里的N个人中一部分人收到的数据去其他人收不到的不一样,如果是这样对于业务来说是致命的。

多个人在不同地点同时对属性A进行修改,由于网络的波动延时,导致Client-D、E、F收到的顺序完全不同;最终呈现的属性值也不同。因此我们参考了Paxos算法的一些思想:

P1: 一个Acceptor必须接受它收到的第一个议案。

P2: 如果一个值为v的议案被选定了,那么被选定的更大编号的议案,它的值必须也是v。

P2a: 如果一个值为v的议案被选定了,那么Acceptor接受的更大编号的议案,它的值必须也是v。

P2b: 如果一个值为v的议案被选定了,那么Proposer提出的更大编号的议案,它的值必须也是v。

P2c: 在所有Acceptor中,任意选取半数以上的Acceptor集合,我们称这个集合为S。Proposal新提出的议案(简称Pnew)必须符合下面两个条件之一:

1)如果S中所有Acceptor都没有接受过议案的话,那么Pnew的编号保证唯一性和递增即可,Pnew的值可以是任意值。

2)如果S中有一个或多个Acceptor曾经接受过议案的话,要先找出其中编号最大的那个议案,假设它的编号为N,值为V。那么Pnew的编号必须大于N,Pnew的值必须等于V。

算法的推导过程理解起来还是比较困难,我们大致总结了其核心点:一致性算法不是算法保证数据一致,他保证的是你数据写入顺序的一致。如果数据写入顺序一致,最终的结果肯定是一样的。

比如上面我们提到的经典场景,我们只要保证所有客户端收到的属性的顺序是一致的,不论属性是213,还是312,只要大家都是这个顺序,那么最终每个客户端上的最终属性值肯定是一样的。

三,总结

任何架构和算法最终都是服务于实际的业务,并不是一种架构胜任所有,应当从多角度、多维度找到适合的方案才是最优解。

以上是关于实时消息RTM| 多活架构中的数据一致性问题的主要内容,如果未能解决你的问题,请参考以下文章

全球异地多活架构设计: 数据层的支持

安卓中的 Agora RTM(实时消息传递)

微服务架构之最终一致性设计概述

不理解Zookeeper一致性原理,谈何异地多活改造

本地读写的多活数据存储架构设计要义

全球异地多活架构设计: Why and How