首页 体育 教育 财经 社会 娱乐 军事 国内 科技 互联网 房产 国际 女人 汽车 游戏

支付宝架构到底有多牛逼!没看完我就跪了!

2020-01-17

自 2008 年双 11 以来,在每年双 11 超大规划流量的冲击上,蚂蚁金服都会不断打破现有技能的极限。

图片来自 Pexels

2010 年双 11 的付出峰值为 2 万笔/分钟,到 2017 年双 11 时这个数字变为了 25.6 万笔/秒。

2018 年双 11 的付出峰值为 48 万笔/秒,2019 年双 11 付出峰值为 54.4 万笔/秒,创下新纪录,是 2009 年第一次双 11 的 1360 倍。

在如此之大的付出 TPS 背面除了削峰等如虎添翼的运用级优化,最解渴最实质的招数当数依据分库分表的单元化了,蚂蚁技能称之为 LDC。

本文不计划谈论详细到代码级的剖析,而是测验用最简略的描绘来阐明其间最皆大欢喜的原理。

我想关怀散布式体系规划的人都曾被下面这些问题所困扰过:

假定你对这些感兴趣,无妨看一场光秃秃的论说,回绝运用不流畅难明的词汇,直面最实质的逻辑。

LDC是相关于传统的提出的,逻辑数据中心所表达的中心思想是不管物理结构怎样的散布,整个数据中心在逻辑上是协同和一起的。

这句话暗含的是强壮的体系规划,散布式体系的应战就在于全体协同作业和一起。

单元化是大型互联网体系的必定挑选趋势,举个最最浅显的比方来阐明单元化。

咱们总是说 TPS 很难提高,的确任何一家互联网公司它的买卖 TPS 顶多以十万计量,很难往上串了。

由于数据库存储层瓶颈的存在再多水平扩展的服务器都无法绕开,而从整个互联网的视角看,全国际电商的买卖 TPS 能够轻松上亿。

这个比方带给咱们一些考虑:为啥几家互联网公司的 TPS 之和能够那么大,服务的用户数规划也极为吓人,而单个互联网公司的 TPS 却很难提高?

究其实质,每家互联网公司都是一个独立的大型单元,他们各自服务自己的用户互不搅扰。

这便是单元化的根本特性,任何一家互联网公司,其想要成倍的扩展自己体系的服务才干,都必定会走向单元化之路。

它的实质是分治,咱们把广阔的用户分为若干部分,一同把体系仿制多份,每一份都独立布置,每一份体系都服务特定的一群用户。

以淘宝举例,这样之后,就会有许多个淘宝体系别离为不同的用户服务,每个淘宝体系都做到十万 TPS 的话,N 个这样的体系就能够轻松做到 N*十万的 TPS 了。

LDC 完结的要害就在于单元化体系架构规划,所以在蚂蚁内部,LDC 和单元化是不分居的,这也是许多同学比较困扰的当地,看似没啥联系,实则是单元化体系规划成果了 LDC。

小结:分库分表处理的最大痛点是数据库单点瓶颈,这个瓶颈的发作是由现代二进制数据存储体系决议的。

单元化仅仅分库分表后体系布置的一种办法,这种布置方法在灾备方面也发挥了极大的优势。

简直任何规划的互联网公司,都有自己的体系架构迭代和更新,大致的演化途径都迥然不同。

最早一般为了业务快速上线,悉数功用都会放到一个运用里,体系架构如下图所示:

这样的架构明显是有问题的,单机有着显着的单点效应,单机的容量和功用都是很约束的,而运用中小型时机带来许多的糟蹋。

跟着业务开展,这个对立逐步转变为首要对立,因而工程师们采用了以下架构:

这是整个公司第一次触碰到散布式,也便是对某个运用进行了水平扩容,它将多个微机的核算才干团结了起来,能够完胜平等价格的中小型机器。

渐渐的,咱们发现,运用服务器 CPU 都很正常了,可是仍是有许多慢恳求,究其原因,是由于单点数据库带来了功用瓶颈。

所以程序员们决议运用主从结构的数据库集群,如下图所示:

其间大部分读操作能够直接拜访从库,然后减轻主库的压力。可是这种办法仍是无法处理写瓶颈,写仍旧需求主库来处理,当业务量量级再次增高时,写现已变成刻不容缓的待处理瓶颈。

这时分,分库分表计划呈现了:

分库分表不只能够对相同的库进行拆分,还能够对相同的表进行拆分,对表进行拆分的办法叫做水平拆分。

不同功用的表放到不同的库里,一般对应的是笔直拆分,此刻一般还对应了微服务化。

这种办法做到极致根本能支撑 TPS 在万级乃至更高的拜访量了。可是跟着相同运用扩展的越多,每个数据库的链接数也巨量添加,这让数据库自身的资源成为了瓶颈。

这个问题发作的实质是全量数据无差别的同享了悉数的运用资源,比方 A 用户的恳求在负载均衡的分配下或许分配到恣意一个运用服务器上,因而悉数运用悉数都要链接 A 用户地点的分库,数据库连接数就变成笛卡尔乘积了。

在实质点说,这种方法的资源阻隔性还不行彻底。要处理这个问题,就需求把辨认用户分库的逻辑往上层移动,从数据库层移动到路由网关层。

这样一来,从运用服务器 a 进来的来自 A 客户的悉数恳求必定落库到 DB-A,因而 a 也不必链接其他的数据库实例了,这样一个单元化的雏形就诞生了。

考虑一下,运用间其实也存在交互,也就意味着,运用不需求链接其他的数据库了,可是还需求链接其他运用。

假定是常见的 RPC 结构如 Dubbo 等,运用的是 TCP/IP 协议,那么等同于把之前与数据库树立的链接,换成与其他运用之间的链接了。

为啥这样就消除瓶颈了呢?首要由于合理的规划,运用间的数据交互并不巨量,其次运用间的交互能够同享 TCP 链接,比方 A- B 之间的 Socket 链接能够被 A 中的多个线程复用。

而一般的数据库如 MySQL 则不行,所以 MySQL 才需求数据库链接池。

如上图所示,但咱们把整套体系打包为单元化时,每一类的数据从进单元开端就注定在这个单元被消化,由于这种彻底的阻隔性,整个单元能够轻松的布置到恣意机房而依然能确保逻辑上的一起。

下图为一个三地五机房的布置办法:

蚂蚁付出宝应该是国内最大的付出东西,其在双 11 等活动日当日的付出 TPS 可达几十万级,未来这个数字或许会更大,这决议了蚂蚁单元化架构从容量要求上看必定从单机房走向多机房。

另一方面,异地灾备也决议了这些 IDC 机房有必要是异地布置的。全体上付出宝也采用了三地五中心来确保体系的可用性。

跟上文中描绘的有所不同的是,付出宝将单元分红了三类:

实践状况下,GZone 异地也会布置,不过仅是用于灾备,同一时间,只需一地 GZone 进行大局服务。GZone 一般被 RZone 依靠,供给的大部分是读取服务。

CZone 是依据特定的 GZone 场景进行优化的一种单元,它把 GZone 中有些有着”写读时间差现象”的数据和服务进行了的独自布置,这样 RZone 只需求拜访本地的 CZone 即可,而不是拜访异地的 GZone。

“写读时间差现象”是蚂蚁架构师们依据实践核算总结的,他们发现大部分状况下,一个数据被写入后,都会过满意长的时间后才会被拜访。

日子中这种比方很常见,咱们办完银行卡后或许好久才会存第一笔钱;咱们创立微博账号后,或许想半响才会发微博;咱们下载创立淘宝账号后,或许得阅览好几分钟才会下单买东西。

当然了这些比方中的时间差远远超过了体系同步时间。一般来说异地的延时在 100ms 以内,所以只需满意某地 CZone 写入数据后 100ms 今后才用这个数据,这样的数据和服务就合适放到 CZone 中。

信任咱们看到这都会问:为啥分这三种单元?其实其背面对应的是不同性质的数据,而服务不过是对数据的操作集。

下面咱们来依据数据性质的不同来解说付出宝的 CRG 架构。当下简直悉数互联网公司的分库分表规矩都是依据用户 ID 来拟定的。

而环绕用户来看整个体系的数据能够分为以下两类:

用户流水型数据:典型的有用户的订单、用户发的谈论、用户的行为记载等。

这些数据都是用户行为发作的流水型数据,具有天然的用户阻隔性,比方 A 用户的 App 上肯定看不到 B 用户的订单列表。所以此类数据十分合适分库分表后独立布置服务。

用户间同享型数据:这种类型的数据又分两类。一类同享型数据是像账号、个人博客等或许会被悉数用户恳求拜访的用户数据。

比方 A 向 B 转账,A 给 B 发消息,这时分需求承认 B 账号是否存在;又比方 A 想看 B 的个人博客之类的。

别的一类是用户无关型数据,像产品、体系装备、财政核算等这些非用户纬度的数据,很难说跟详细的某一类用户挂钩,或许触及到悉数用户。

比方产品,假定按产品地点地来寄存产品数据,那么上海的用户依然需求拜访杭州的产品。

这就又构成跨地跨 Zone 拜访了,仍是达不到单元化的抱负状况,而且双维度分库分表会给整个 LDC 运维带来杂乱度提高。

注:网上和付出宝内部有别的一些分法,比方流水型和状况性,有时分还会分为三类:流水型、状况型和装备型。

个人觉得这些分法尽管测验去更高层次的笼统数据分类,但实践上鸿沟很含糊,拔苗助长。

直观的类比,咱们能够很简略的将上述两类数据对应的服务划分为 RZone 和 GZone,RZone 包含的便是分库分表后担任固定客户集体的服务,GZone 则包含了用户间同享的公共数据对应的服务。

到这儿停止,悉数都很完美,这也是干流的单元化话题了。比照付出宝的 CRG 架构,咱们一眼就发现少了 C,CZone 的确是蚂蚁在单元化实践范畴的一个立异点。

再来剖析下 GZone,GZone 之所以只能单地布置,是由于其数据要求被悉数用户同享,无法分库分表,而多地布置会带因由异地延时引起的不一起。

比方实时风控体系,假定多地布置,某个 RZone 直接读取本地的话,很简略读取到旧的风控状况,这是很风险的。

这时蚂蚁架构师们问了自己一个问题——莫非悉数数据受不了延时么?这个问题像是打开了新国际的大门,经过对 RZone 已有业务的剖析,架构师们发现 80% 乃至更高的场景下,数据更新后都不要求立马被读取到。

也便是上文提到的”写读时间差现象”,那么这就好办了,关于这类数据,咱们答应每个区域的 RZone 服务直接拜访本地,为了给这些 RZone 供给这些数据的本地拜访才干,蚂蚁架构师规划出了 CZone。

在 CZone 的场景下,写恳求一般从 GZone 写入公共数据地点库,然后同步到整个 OB 集群,然后由 CZone 供给读取服务。比方付出宝的会员服务便是如此。

即使架构师们规划了完美的 CRG,但即使在蚂蚁的实践运用中,各个体系依然存在不合理的 CRG 分类,尤其是 CG 不分的现象很常见。

单元化后,异地多活仅仅多地布置罢了。比方上海的两个单元为 ID 规模为 [00~19],[40~59] 的用户服务。

而杭州的两个单元为 ID 为 [20~39]和[60,79]的用户服务,这样上海和杭州便是异地双活的。

付出宝对单元化的根本要求是每个单元都具有服务悉数用户的才干,即——详细的那个单元服务哪些用户是能够动态装备的。所以异地双活的这些单元还充当了相互的备份。

发现作业中冷备热备现已被用的很乱了。最早冷备是指数据库在备份数据时需求封闭后进行备份,避免数据备份进程中又修正了,不需求封闭即在运转进程中进行数据备份的办法叫做热备。

也不知道从哪一天开端,冷备在主备体系里代表了这台备用机器是封闭状况的,只需主服务器挂了之后,备服务器才会被发动。

而相同的热备变成了备服务器也是发动的,仅仅没有流量罢了,一旦主服务器挂了之后,流量主动打到备服务器上。本文不计划用第二种了解,由于感觉有点野。

为了做到每个单元拜访哪些用户变成可装备,付出宝要求单元化办理体系具有流量到单元的可装备以及单元到 DB 的可装备才干。

如下图所示:

其间 Spanner 是蚂蚁依据 Nginx 自研的反向署理网关,也很好了解,有些恳求咱们期望在反向署理层就被转发至其他 IDC 的 Spanner 而无需进入后端服务,如图箭头 2 所示。

那么关于应该在本 IDC 处理的恳求,就直接映射到对应的 RZ 即可,如图箭头 1。

进入后端服务后,理论上假定恳求仅仅读取用户流水型数据,那么一般不会再进行路由了。

可是,关于有些场景来说,A 用户的一个恳求或许相关了对 B 用户数据的拜访,比方 A 转账给 B,A 扣完钱后要调用账务体系去添加 B 的余额。

这时分就触及到再次的路由,相同有两个成果:跳转到其他 IDC或是跳转到本 IDC 的其他 RZone。

RZone 到 DB 数据分区的拜访这是事前装备好的,上图中 RZ 和 DB 数据分区的联系为:

RZ0* --  a 
RZ1* --  b 
RZ2* --  c 
RZ3* --  d 

下面咱们举个比方来阐明整个流量离间的进程,假定 C 用户所属的数据分区是 c,而 C 用户在杭州拜访了 cashier.alipay.com。

①现在付出宝默许会依照地域来路由流量,详细的完结承载者是自研的 GLSB:

https://developer.alipay.com/article/1889 

它会依据恳求者的 IP,主动将 cashier.alipay.com 解析为杭州 IDC 的 IP 地址。

咱们自己搞过网站的化应该知道大部分 DNS 服务商的地址都是靠人去装备的,GLSB 归于动态装备域名的体系,网上也有比较火的相似产品,比方花生壳之类的。

②好了,到此停止,用户的恳求来到了 IDC-1 的 Spanner 集群服务器上,Spanner 从内存中读取到了路由装备,知道了这个恳求的主体用户 C 所属的 RZ3* 不再本 IDC,所以直接转到了 IDC-2 进行处理。

③进入 IDC-2 之后,依据流量配比规矩,该恳求被分配到了 RZ3B 进行处理。

④RZ3B 得到恳求后对数据分区 c 进行拜访。

⑤处理完毕后原路回来。

咱们应该发现问题地点了,假定再来一个这样的恳求,岂不是每次都要跨地域进行调用和回来体传递?

的确是存在这样的问题的,关于这种问题,付出宝架构师们决议持续把决议计划逻辑往用户终端推移。

比方,每个 IDC 机房都会有自己的域名:

那么恳求从 IDC-1 涮过一遍回来时会将前端恳求跳转到 cashieridc-2.alipay.com 去,后边悉数用户的行为都会在这个域名上发作,就避免了走一遍 IDC-1 带来的延时。

流量离间是灾备切换的根底和前提条件,发作灾祸后的通用办法便是把堕入灾祸的单元的流量从头打到正常的单元上去,这个流量切换的进程俗称切流。

付出宝 LDC 架构下的灾备有三个层次:

同机房单元间灾备:灾祸发作或许性相对最高。对 LDC 来说,最小的灾祸便是某个单元由于一些原因宕机了。

从上节里的图中能够看到每组 RZ 都有 A,B 两个单元,这便是用来做同机房灾备的,而且 AB 之间也是双活双备的。

正常状况下 AB 两个单元一同分管悉数的恳求,一旦 A 单元挂了,B 单元将主动承当 A 单元的流量比例。这个灾备计划是默许的。

同城机房间灾备:灾祸发作或许性相对更小。这种灾祸发作的原因一般是机房电线网线被挖断,或许机房保护人员操作失误导致的。

在这种状况下,就需求人工的拟定流量离间计划了。下面咱们举例阐明这个进程,如下图所示为上海的两个 IDC 机房。

整个切流装备进程分两步,首要需求将堕入灾祸的机房中 RZone 对应的数据分区的拜访权装备进行修正。

假定咱们的计划是由 IDC-2 机房的 RZ2 和 RZ3 别离接收 IDC-1 中的 RZ0 和 RZ1。

那么首要要做的是把数据分区 a,b 对应的拜访权从 RZ0 和 RZ1 回收,分配给 RZ2 和 RZ3。

行将:

RZ0* --  a 
RZ1* --  b 
RZ2* --  c 
RZ3* --  d 

变为:

RZ0* --  / 
RZ1* --  / 
RZ2* --  a 
RZ2* --  c 
RZ3* --  b 
RZ3* --  d 

然后再修正用户 ID 和 RZ 之间的映射装备。假定之前为:

[00-24] --  RZ0A,RZOB 
[25-49] --  RZ1A,RZ1B 
[50-74] --  RZ2A,RZ2B 
[75-99] --  RZ3A,RZ3B 

那么依照灾备计划的要求,这个映射装备将变为:

[00-24] --  RZ2A,RZ2B 
[25-49] --  RZ3A,RZ3B 
[50-74] --  RZ2A,RZ2B 
[75-99] --  RZ3A,RZ3B 

这样之后,悉数流量将会被打到 IDC-2 中,期间部分现已向 IDC-1 主张恳求的用户会收到失利并重试的提示。

实践状况中,整个进程并不是灾祸发作后再去做的,整个切换的流程会以预案装备的方法事前准备好,推送给每个流量离间客户端。

这儿能够考虑下,为何先切数据库映射,再切流量呢?这是由于假定先切流量,意味着许多注定失利的恳求会被打到新的正常单元上去,然后影响体系的稳定性。

异地机房间灾备:这个根本上跟同城机房间灾备一起,不再赘述。

CAP 原则是指恣意一个散布式体系,一同最多只能满意其间的两项,而无法一同满意三项。

所谓的散布式体系,说白了便是一件事一个人做的,现在分给好几个人一同干。

咱们先简略回忆下 CAP 各个维度的意义:

Consistency,这个了解起来很简略,便是每时每刻每个节点上的同一份数据都是一起的。

这就要求任何更新都是原子的,即要么悉数成功,要么悉数失利。幻想一下运用散布式业务来确保悉数体系的原子性是多么低效的一个操作。

Availability,这个可用性看起来很简略了解,但真实说清楚的不多。我更乐意把可用性解说为:恣意时间体系都能够供给读写服务。

举个比方,当咱们用业务将悉数节点锁住来进行某种写操作时,假定某个节点发作不行用的状况,会让整个体系不行用。

关于分片式的 NoSQL 中间件集群来说,一旦一个分片歇菜了,整个体系的数据也就不完整了,读取宕机分片的数据就会没呼应,也便是不行用了。

需求阐明一点,哪些挑选 CP 的散布式体系,并不是代表可用性就彻底没有了,仅仅可用性没有确保了。

为了添加可用性确保,这类中间件往往都供给了”分片集群+仿制集”的计划。

Partition tolerance,这个或许也是许多文章都没说清楚的。P 并不是像 CA 相同是一个独立的性质,它依托于 CA 来进行谈论。

参考文献中的解说:”除非整个网络瘫痪,不然任何时间体系都能正常作业”,言下之意是小规模的网络瘫痪,节点宕机,都不会影响整个体系的 CA。

我感觉这个解说听着仍是有点懵逼,所以个人更乐意解说为当节点之间网络不通时,可用性和一起性依然能得到确保。

从个人视点了解,分区忍受性又分为“可用性分区忍受性”和“一起性分区忍受性”。

呈现分区时会不会影响可用性的要害在于需不需求悉数节点相互交流协作来完结一次业务,不需求的话是铁定不影响可用性的。

幸亏的是应该不太会有散布式体系会被规划成完结一次业务需求悉数节点联动,必定要举个比方的话,全同步仿制技能下的 MySQL 是一个典型事例。

呈现分区时会不会影响一起性的要害则在于呈现脑裂时有没有确保一起性的计划,这对主从同步型数据库是丧命的。

一旦网络呈现分区,发作脑裂,体系会呈现一份数据两个值的状况,谁都不觉得自己是错的。

需求阐明的是,正常来说同一局域网内,网络分区的概率十分低,这也是为啥咱们最了解的数据库也是不考虑 P 的原因。

下图为 CAP 之间的经典联系图:

还有个需求阐明的当地,其实散布式体系很难满意 CAP 的前提条件是这个体系必定是有读有写的,假定只考虑读,那么 CAP 很简略都满意。

比方一个核算器服务,承受表达式恳求,回来核算成果,搞成水平扩展的散布式,明显这样的体系没有一起性问题,网络分区也不怕,可用性也是很稳的,所以能够满意 CAP。

先说下 CA 和 P 的联系,假定不考虑 P 的话,体系是能够轻松完结 CA 的。

而 P 并不是一个独自的性质,它代表的是方针散布式体系有没有对网络分区的状况做容错处理。

假定做了处理,就必定是带有 P 的,接下来再考虑分区状况下究竟挑选了 A 仍是 C。所以剖析 CAP,主张先确认有没有对分区状况做容错处理。

以下是个人总结的剖析一个散布式体系 CAP 满意状况的一般办法:

if{ 
 if) 
 return  AP  
 else if。

水平扩展运用+单数据库实例的 CAP 剖析

让咱们再来回忆下散布式运用体系的因由,早年每个运用都是单体的,跑在一个服务器上,服务器一挂,服务就不行用了。

别的一方面,单体运用由于业务功用杂乱,对机器的要求也逐步变高,一般的微机无法满意这种功用和容量的要求。

所以要拆!还在 IBM 大卖小型商用机的时代,阿里巴巴就提出要以散布式微机代替小型机。

所以咱们发现,散布式体系处理的最大的痛点,便是单体单机体系的可用性问题。

要想高可用,有必要散布式。一家互联网公司的开展之路上,第一次与散布式相遇应该都是在单体运用的水平扩展上。

也便是同一个运用发动了多个实例,连接着相同的数据库,如下图所示:

这样的体系天然具有的便是 AP:

一方面处理了单点导致的低可用性问题。 另一方面不管这些水平扩展的机器间网络是否呈现分区,这些服务器都能够各自供给服务,由于他们之间不需求进行交流。

可是,这样的体系是没有一起性可言的,幻想一下每个实例都能够往数据库 insert 和 update,那还不乱了套。

所以咱们转向了让 DB 去做这个事,这时分”数据库业务”就被用上了。用大部分公司会挑选的 MySQL 来举例,用了业务之后会发现数据库又变成了单点和瓶颈。

单点就像单机相同,理论上就不叫散布式了,假定必定要剖析其 CAP 的话,依据上面的进程剖析进程应该是这样的:

分区忍受性:先看有没有考虑分区忍受性,或许分区后是否会有影响。单台 MySQL 无法构成分区,要么整个体系挂了,要么就活着。 可用性分区忍受性:分区状况下,假定恰好是该节点挂了,体系也就不行用了,所以可用性分区忍受性不满意。 一起性分区忍受性:分区状况下,只需可用,单点单机的最大优点便是一起功用够得到确保。

因而这样的一个体系,个人认为仅仅满意了 CP。A 有但不超卓,从这点能够看出,CAP 并不对错黑即白的。

包含常说的 BASE 计划,其实仅仅 C 不超卓,但终究也是到达一起性的,BASE 在一起性上挑选了让步。

关于散布式运用+单点数据库的方法是不是纯粹的散布式体系,这个或许每个人观点有点差异,上述仅仅我个人的一种了解,是不是散布式体系不重要,重要的是剖析进程。

其实咱们谈论散布式,便是期望体系的可用性是多个体系多活的,一个挂了别的的也能顶上,明显单机单点的体系不具有这样的高可用特性。

所以在我看来,广义的说 CAP 也适用于单点单机体系,单机体系是 CP 的。

提到这儿,咱们好像也发现了,水平扩展的服务运用+数据库这样的体系的 CAP 魔咒首要发作在数据库层。

由于大部分这样的服务运用都仅仅承当了核算的使命,自身不需求相互协作,悉数写恳求带来的数据的一起性问题下沉到了数据库层去处理。

幻想一下,假定没有数据库层,而是运用自己来确保数据一起性,那么这样的运用之间就触及到状况的同步和交互了,ZooKeeper 便是这么一个典型的比方。

水平扩展运用+主从数据库集群的CAP剖析

上一节咱们谈论了多运用实例+单数据库实例的方法,这种方法是散布式体系也好,不是散布式体系也罢,全体是偏 CP 的。

实践中,技能人员们也会很快发现这种架构的不合理性——可用性太低了。

所以如下图所示的方法成为了当下大部分中小公司所运用的架构:

从上图我能够看到三个数据库实例中只需一个是主库,其他是从库。

必定程度上,这种架构极大的缓解了”读可用性”问题,而这样的架构一般会做读写别离来到达更高的”读可用性”,走运的是大部分互联网场景中读都占了 80% 以上,所以这样的架构能得到较长时间的广泛运用。

写可用功用够经过 Keepalived 这种 HA结构来确保主库是活着的,但细心一想就能够了解,这种办法并没有带来功用上的可用性提高。还好,至少体系不会由于某个实例挂了就都不行用了。

可用性牵强合格了,这时分的 CAP 剖析如下:

分区忍受性:仍旧先看分区忍受性,主从结构的数据库存在节点之间的通讯,他们之间需求经过心跳来确保只需一个 Master。

可是一旦发作分区,每个分区会自己选取一个新的 Master,这样就呈现了脑裂,常见的主从数据库并没有自带处理脑裂的计划。所以分区忍受性是没考虑的。

一起性:不考虑分区,由于恣意时间只需一个主库,所以一起性是满意的。 可用性:不考虑分区,HA 机制的存在能够确保可用性,所以可用性明显也是满意的。

所以这样的一个体系,咱们认为它是 AC 的。咱们再深入研究下,假定发作脑裂发作数据不一起后有一种办法能够裁定一起性问题,是不是就能够满意 P 了呢。

还真有测验经过预先设置规矩来处理这种多主库带来的一起性问题的体系,比方 CouchDB,它经过版别办理来支撑多库写入,在其裁定阶段会经过 DBA 装备的裁定规矩进行主动裁定,然后确保终究一起性,主动规矩无法兼并的状况则只能依靠人工决议计划了。

蚂蚁单元化 LDC 架构 CAP 剖析

①打败分区忍受性

在谈论蚂蚁 LDC 架构的 CAP 之前,咱们再来想想分区忍受性有啥值得一提的,为啥许多大名鼎鼎的 BASE体系体系都挑选丢失实时一起性,而不是丢掉分区忍受性呢?

分区的发作一般有两种状况:

某台机器宕机了,过一瞬间又重启了,看起来就像失联了一段时间,像是网络不行达相同。

异地布置状况下,异地多活意味着每一地都或许会发作数据写入,而异地之间偶然的网络延时尖刺、网络故障都会导致小规模的网络分区发作。

前文也提到过,假定一个散布式体系是布置在一个局域网内的,那么个人认为分区的概率极低,即使有杂乱的拓扑,也很少会有在同一个机房里呈现网络分区的状况。

而异地这个概率会大大增高,所以蚂蚁的三地五中心有必要需求考虑这样的问题,分区忍受不能丢!

相同的状况还会发作在不同 ISP 的机房之间。

为了应对某一时间某个机房突发的网络延时尖刺活着间歇性失联,一个好的散布式体系必定能处理好这种状况下的一起性问题。

那么蚂蚁是怎样处理这个问题的呢?咱们在上文谈论过,其实 LDC 机房的各个单元都由两部分组成:担任业务逻辑核算的运用服务器和担任数据耐久化的数据库。

大部分运用服务器就像一个个核算器,自身是不对写一起性担任的,这个使命被下沉到了数据库。所以蚂蚁处理散布式一起性问题的要害就在于数据库!

想必蚂蚁的读者大约猜到下面的谈论重点了——OceanBase,我国第一款自主研制的散布式数据库,一时间也的确取得了许多光环。

在谈论 OB 前,咱们先来想想 Why not MySQL?

首要,就像 CAP 三角图中指出的,MySQL 是一款满意 AC 但不满意 P 的散布式体系。

试想一下,一个 MySQL 主从结构的数据库集群,当呈现分区时,问题分区内的 Slave 会认为主现已挂了,所以自己成为本分区的 Master。

等分区问题康复后,会发作 2 个主库的数据,而无法确认谁是正确的,也便是分区导致了一起性被损坏。这样的成果是严峻的,这也是蚂蚁甘愿自研 OceanBase 的原动力之一。

那么怎样才干让散布式体系具有分区忍受性呢?依照老常规,咱们从”可用性分区忍受”和”一起性分区忍受”两个方面来谈论:

可用性分区忍受性确保机制:可用性分区忍受的要害在于别让一个业务一来悉数节点来完结,这个很简略,别要求悉数节点一同一同参加某个业务即可。

一起性分区忍受性确保机制:老实说,都发作分区了,哪还或许取得实时一起性。

但要确保终究一起性也不简略,一旦发作分区,怎样确保同一时间只会发作一份提议呢?

换句话说,怎样确保依然只需一个脑呢?下面咱们来看下 PAXOS 算法是怎样处理脑裂问题的。

这儿能够发散下,所谓的“脑”其实便是具有写才干的体系,“非脑”便是只具有读才干的体系,对应了 MySQL 集群中的从库。

下面是一段摘自维基百科的 PAXOS 界说:

Paxos is a family of protocols for solving consensus in a network of unreliable processors .

大致意思便是说,PAXOS 是在一群不是特别牢靠的节点组成的集群中的一种一起机制。

Paxos 要求任何一个提议,至少有 +1 的体系节点认可,才被认为是可信的,这背面的一个根底理论是少数服从大都。

幻想一下,假定大都节点认可后,整个体系宕机了,重启后,依然能够经过一次投票知道哪个值是合法的。

这样的设定也奇妙的处理了分区状况下的一起问题,由于一旦发作分区,必然最多只需一个分区内的节点数量会大于等于 +1。

经过这样的规划就能够奇妙的避开脑裂,当然 MySQL 集群的脑裂问题也是能够经过其他办法来处理的,比方一同 Ping 一个公共的 IP,成功者持续为脑,明显这就又制作了别的一个单点。

假定你了解过比特币或许区块链,你就知道区块链的根底理论也是 PAXOS。区块链凭借 PAXOS 对终究一起性的奉献来抵挡歹意篡改。

而本文触及的散布式运用体系则是经过 PAXOS 来处理分区忍受性。再说实质一点,一个是抵挡部分节点变坏,一个是防备部分节点失联。

咱们必定听说过这样的描绘:PAXOS 是仅有能处理散布式一起性问题的解法。

这句话越是了解越发觉得怪异,这会让人认为 PAXOS 逃离于 CAP 约束了,所以个人更乐意了解为:PAXOS 是仅有一种确保散布式体系终究一起性的一起算法。

PAXOS 并没有逃离 CAP 魔咒,究竟到达一起是 +1 的节点之间的事,剩余的 -1 的节点上的数据仍是旧的,这时分依然是不一起的。

所以 PAXOS 对一起性的奉献在于经过一次业务后,这个集群里现已有部分节点保有了本次业务正确的成果,这个成果随后会被异步的同步到其他节点上,然后确保终究一起性。

以下摘自维基百科:

Paxos is a family of protocols for solving consensus in a network of unreliable processors .Quorums express the safety properties of Paxos by ensuring at least some surviving processor retains knowledge of the results.

别的 PAXOS 不要求对悉数节点做实时同步,实质上是考虑到了分区状况下的可用性,经过削减完结一次业务需求的参加者个数,来确保体系的可用性。

②OceanBase 的 CAP 剖析

上文提到过,单元化架构中的成千山万的运用就像是核算器,自身无 CAP 约束,其 CAP 约束下沉到了其数据库层,也便是蚂蚁自研的散布式数据库 OceanBase。

在 OB 体系中,每个数据库实例都具有读写才干,详细是读是写能够动态装备。

实践状况下大部分时分,关于某一类数据恣意时间只需一个单元会担任写入某个节点,其他节点要么是实时库间同步,要么是异步数据同步。

OB 也采用了 PAXOS 一起协议。实时库间同步的节点个数至少需求 +1 个,这样就能够处理分区忍受性问题。

下面咱们举个马教师改英文名的比方来阐明 OB 规划的精妙之处:

假定数据库依照用户 ID 分库分表,马教师的用户 ID 对应的数据段在 [0-9],开端由单元 A 担任数据写入。

假定马教师正在用付出宝 App 修正自己的英文名,马教师一开端打错了,打成了 Jason Ma,A 单元收到了这个恳求。

这时分发作了分区,咱们将单元 A 对数据段 [0,9] 的写入权限转交给单元 B,马教师这次写对了,为 Jack Ma。

而在网络断开前恳求现已进入了 A,写权限转交给单元 B 收效后,A 和 B 一同对 [0,9] 数据段进行写入马教师的英文名。

假定这时分都答应写入的话就会呈现不一起,A 单元说我看到马教师设置了 Jason Ma,B 单元说我看到马教师设置了 Jack Ma。

可是这种状况不会发作的,A 提议说我主张把马教师的英文名设置为 Jason Ma 时,发现没人回应它。

由于呈现了分区,其他节点对它来说都是不行达的,所以这个提议被主动丢掉,A 心里也了解是自己分区了,会有主分区替自己完结写入使命的。

相同的,B 提出了将马教师的英文名改成 Jack Ma 后,大部分节点都呼应了,所以 B 成功将 Jack Ma 写入了马教师的账号记载。

假定在写权限转交给单元 B 后 A 忽然康复了,也没联系,两笔写恳求一同要求取得 +1 个节点的业务锁,经过 no-wait 规划,在 B 取得了锁之后,其他争抢该锁的业务都会由于失利而回滚。

下面咱们剖析下 OB 的 CAP:

分区忍受性:OB 节点之间是有相互通讯的,所以存在分区问题,OB 经过仅同步到部分节点来确保可用性。这一点就阐明 OB 做了分区容错。 可用性分区忍受性:OB 业务只需求同步到 +1 个节点,答应其他的一小半节点分区,只需 +1 个节点活着便是可用的。 极点状况下,比方 5 个节点分红 3 份,那就的确不行用了,仅仅这种状况概率比较低。 一起性分区忍受性:分区状况下意味着部分节点失联了,一起性明显是不满意的。但经过一起算法能够确保当下只需一个值是合法的,而且终究会经过节点间的同步到达终究一起性。

所以 OB 依然没有逃脱 CAP 魔咒,发作分区的时分它变成 AP+终究一起性。全体来说,它是 AP 的,即高可用和分区忍受。

个人感觉本文触及到的知识面的确不少,每个点独自打开都能够谈论半响。回到咱们紧扣的宗旨来看,双十一海量付出背面技能上皆大欢喜的规划究竟是啥?

我想无非是以下几点:

依据用户分库分表的 RZone 规划。每个用户群独占一个单元给整个体系的容量带来了爆发式添加。 RZone 在网络分区或灾备切换时 OB 的防脑裂规划。咱们知道 RZone 是单脑的,而网络分区或许灾备时热切换进程中或许会发作多个脑,OB 处理了脑裂状况下的一起问题。 依据 CZone 的本地读规划。这一点确保了很大一部分有着“写读时间差”现象的公共数据能被高速本地拜访。 剩余的那一丢丢不能本地拜访只能实时拜访 GZone 的公共装备数据,也兴不起什么风,作不了什么浪。

比方用户创立这种 TPS,不会高到哪里去。再比方关于实时库存数据,能够经过“页面展现查询走运用层缓存”+“实践下单时再校验”的办法削减其 GZone 调用量。

而这便是蚂蚁 LDC 的 CRG 架构,信任 54.4 万笔/秒还远没到 LDC 的上限,这个数字能够做到更高。

当然双 11 海量付出的成功不单单是这么一套规划所决议的,还有预热削峰等运营+技能的手法,以及成百上千的兄弟姐妹一同奋战,特此在这向各位双 11 留守同学问候。

感谢咱们的阅览,文中或许存在缺乏或遗失之处,欢迎批评指正。

参考文献:

Practice of Cloud System Administration, The: DevOps and SRE Practices for Web Services, Volume 2. Thomas A. Limoncelli, Strata R. Chalup, Christina J. Hogan. MySQL 5.7 半同步仿制技能

https://www.cnblogs.com/zero-gg/p/9057092.html

BASE 理论剖析

https://www.jianshu.com/p/f6157118e54b

Keepalived

https://baike.baidu.com/item/Keepalived/10346758?fr=aladdin

PAXOS

https://en.wikipedia.org/wiki/Paxos_

OceanBase 支撑 2135 亿成交额背面的技能原理

https://www.cnblogs.com/antfin/articles/10299396.html

Backup

https://en.wikipedia.org/wiki/Backup

作者:汤波

简介:阿里巴巴架构师,酷爱技能,坚信技能让国际更夸姣。对前沿技能一向坚持饥饿感,热衷于立异和改造,让体系体系更为高效和人性化,也深知一个人强走的快,一个集体强才干走的远。在技能团队建造、技能栈办理和项目研制办理方面有着较为丰厚的实践经验。重视范畴:SaaS,PaaS,Serverless,Service mesh,新零售,区块链,人工智能,互联网全栈,散布式企业级开发,网络运用/协议开发,核算机算法运用。

让咱们再来回忆下散布式运用体系的因由,早年每个运用都是单体的,跑在一个服务器上,服务器一挂,服务就不行用了。

别的一方面,单体运用由于业务功用杂乱,对机器的要求也逐步变高,一般的微机无法满意这种功用和容量的要求。

所以要拆!还在 IBM 大卖小型商用机的时代,阿里巴巴就提出要以散布式微机代替小型机。

所以咱们发现,散布式体系处理的最大的痛点,便是单体单机体系的可用性问题。

要想高可用,有必要散布式。一家互联网公司的开展之路上,第一次与散布式相遇应该都是在单体运用的水平扩展上。

也便是同一个运用发动了多个实例,连接着相同的数据库,如下图所示:

这样的体系天然具有的便是 AP:

可是,这样的体系是没有一起性可言的,幻想一下每个实例都能够往数据库 insert 和 update,那还不乱了套。

所以咱们转向了让 DB 去做这个事,这时分”数据库业务”就被用上了。用大部分公司会挑选的 MySQL 来举例,用了业务之后会发现数据库又变成了单点和瓶颈。

单点就像单机相同,理论上就不叫散布式了,假定必定要剖析其 CAP 的话,依据上面的进程剖析进程应该是这样的:

因而这样的一个体系,个人认为仅仅满意了 CP。A 有但不超卓,从这点能够看出,CAP 并不对错黑即白的。

包含常说的 BASE 计划,其实仅仅 C 不超卓,但终究也是到达一起性的,BASE 在一起性上挑选了让步。

关于散布式运用+单点数据库的方法是不是纯粹的散布式体系,这个或许每个人观点有点差异,上述仅仅我个人的一种了解,是不是散布式体系不重要,重要的是剖析进程。

其实咱们谈论散布式,便是期望体系的可用性是多个体系多活的,一个挂了别的的也能顶上,明显单机单点的体系不具有这样的高可用特性。

所以在我看来,广义的说 CAP 也适用于单点单机体系,单机体系是 CP 的。

提到这儿,咱们好像也发现了,水平扩展的服务运用+数据库这样的体系的 CAP 魔咒首要发作在数据库层。

由于大部分这样的服务运用都仅仅承当了核算的使命,自身不需求相互协作,悉数写恳求带来的数据的一起性问题下沉到了数据库层去处理。

幻想一下,假定没有数据库层,而是运用自己来确保数据一起性,那么这样的运用之间就触及到状况的同步和交互了,ZooKeeper 便是这么一个典型的比方。

上一节咱们谈论了多运用实例+单数据库实例的方法,这种方法是散布式体系也好,不是散布式体系也罢,全体是偏 CP 的。

实践中,技能人员们也会很快发现这种架构的不合理性——可用性太低了。

所以如下图所示的方法成为了当下大部分中小公司所运用的架构:

从上图我能够看到三个数据库实例中只需一个是主库,其他是从库。

必定程度上,这种架构极大的缓解了”读可用性”问题,而这样的架构一般会做读写别离来到达更高的”读可用性”,走运的是大部分互联网场景中读都占了 80% 以上,所以这样的架构能得到较长时间的广泛运用。

写可用功用够经过 Keepalived 这种 HA结构来确保主库是活着的,但细心一想就能够了解,这种办法并没有带来功用上的可用性提高。还好,至少体系不会由于某个实例挂了就都不行用了。

可用性牵强合格了,这时分的 CAP 剖析如下:

可是一旦发作分区,每个分区会自己选取一个新的 Master,这样就呈现了脑裂,常见的主从数据库并没有自带处理脑裂的计划。所以分区忍受性是没考虑的。

所以这样的一个体系,咱们认为它是 AC 的。咱们再深入研究下,假定发作脑裂发作数据不一起后有一种办法能够裁定一起性问题,是不是就能够满意 P 了呢。

还真有测验经过预先设置规矩来处理这种多主库带来的一起性问题的体系,比方 CouchDB,它经过版别办理来支撑多库写入,在其裁定阶段会经过 DBA 装备的裁定规矩进行主动裁定,然后确保终究一起性,主动规矩无法兼并的状况则只能依靠人工决议计划了。

蚂蚁单元化 LDC 架构 CAP 剖析

在谈论蚂蚁 LDC 架构的 CAP 之前,咱们再来想想分区忍受性有啥值得一提的,为啥许多大名鼎鼎的 BASE体系体系都挑选丢失实时一起性,而不是丢掉分区忍受性呢?

分区的发作一般有两种状况:

某台机器宕机了,过一瞬间又重启了,看起来就像失联了一段时间,像是网络不行达相同。

异地布置状况下,异地多活意味着每一地都或许会发作数据写入,而异地之间偶然的网络延时尖刺、网络故障都会导致小规模的网络分区发作。

前文也提到过,假定一个散布式体系是布置在一个局域网内的,那么个人认为分区的概率极低,即使有杂乱的拓扑,也很少会有在同一个机房里呈现网络分区的状况。

而异地这个概率会大大增高,所以蚂蚁的三地五中心有必要需求考虑这样的问题,分区忍受不能丢!

相同的状况还会发作在不同 ISP 的机房之间。

为了应对某一时间某个机房突发的网络延时尖刺活着间歇性失联,一个好的散布式体系必定能处理好这种状况下的一起性问题。

那么蚂蚁是怎样处理这个问题的呢?咱们在上文谈论过,其实 LDC 机房的各个单元都由两部分组成:担任业务逻辑核算的运用服务器和担任数据耐久化的数据库。

大部分运用服务器就像一个个核算器,自身是不对写一起性担任的,这个使命被下沉到了数据库。所以蚂蚁处理散布式一起性问题的要害就在于数据库!

想必蚂蚁的读者大约猜到下面的谈论重点了——OceanBase,我国第一款自主研制的散布式数据库,一时间也的确取得了许多光环。

在谈论 OB 前,咱们先来想想 Why not MySQL?

首要,就像 CAP 三角图中指出的,MySQL 是一款满意 AC 但不满意 P 的散布式体系。

试想一下,一个 MySQL 主从结构的数据库集群,当呈现分区时,问题分区内的 Slave 会认为主现已挂了,所以自己成为本分区的 Master。

等分区问题康复后,会发作 2 个主库的数据,而无法确认谁是正确的,也便是分区导致了一起性被损坏。这样的成果是严峻的,这也是蚂蚁甘愿自研 OceanBase 的原动力之一。

那么怎样才干让散布式体系具有分区忍受性呢?依照老常规,咱们从”可用性分区忍受”和”一起性分区忍受”两个方面来谈论:

可用性分区忍受性确保机制:可用性分区忍受的要害在于别让一个业务一来悉数节点来完结,这个很简略,别要求悉数节点一同一同参加某个业务即可。

一起性分区忍受性确保机制:老实说,都发作分区了,哪还或许取得实时一起性。

但要确保终究一起性也不简略,一旦发作分区,怎样确保同一时间只会发作一份提议呢?

换句话说,怎样确保依然只需一个脑呢?下面咱们来看下 PAXOS 算法是怎样处理脑裂问题的。

这儿能够发散下,所谓的“脑”其实便是具有写才干的体系,“非脑”便是只具有读才干的体系,对应了 MySQL 集群中的从库。

下面是一段摘自维基百科的 PAXOS 界说:

Paxos is a family of protocols for solving consensus in a network of unreliable processors .

大致意思便是说,PAXOS 是在一群不是特别牢靠的节点组成的集群中的一种一起机制。

Paxos 要求任何一个提议,至少有 +1 的体系节点认可,才被认为是可信的,这背面的一个根底理论是少数服从大都。

幻想一下,假定大都节点认可后,整个体系宕机了,重启后,依然能够经过一次投票知道哪个值是合法的。

这样的设定也奇妙的处理了分区状况下的一起问题,由于一旦发作分区,必然最多只需一个分区内的节点数量会大于等于 +1。

经过这样的规划就能够奇妙的避开脑裂,当然 MySQL 集群的脑裂问题也是能够经过其他办法来处理的,比方一同 Ping 一个公共的 IP,成功者持续为脑,明显这就又制作了别的一个单点。

假定你了解过比特币或许区块链,你就知道区块链的根底理论也是 PAXOS。区块链凭借 PAXOS 对终究一起性的奉献来抵挡歹意篡改。

而本文触及的散布式运用体系则是经过 PAXOS 来处理分区忍受性。再说实质一点,一个是抵挡部分节点变坏,一个是防备部分节点失联。

咱们必定听说过这样的描绘:PAXOS 是仅有能处理散布式一起性问题的解法。

这句话越是了解越发觉得怪异,这会让人认为 PAXOS 逃离于 CAP 约束了,所以个人更乐意了解为:PAXOS 是仅有一种确保散布式体系终究一起性的一起算法。

PAXOS 并没有逃离 CAP 魔咒,究竟到达一起是 +1 的节点之间的事,剩余的 -1 的节点上的数据仍是旧的,这时分依然是不一起的。

所以 PAXOS 对一起性的奉献在于经过一次业务后,这个集群里现已有部分节点保有了本次业务正确的成果,这个成果随后会被异步的同步到其他节点上,然后确保终究一起性。

以下摘自维基百科:

Paxos is a family of protocols for solving consensus in a network of unreliable processors .Quorums express the safety properties of Paxos by ensuring at least some surviving processor retains knowledge of the results.

别的 PAXOS 不要求对悉数节点做实时同步,实质上是考虑到了分区状况下的可用性,经过削减完结一次业务需求的参加者个数,来确保体系的可用性。

上文提到过,单元化架构中的成千山万的运用就像是核算器,自身无 CAP 约束,其 CAP 约束下沉到了其数据库层,也便是蚂蚁自研的散布式数据库 OceanBase。

在 OB 体系中,每个数据库实例都具有读写才干,详细是读是写能够动态装备。

实践状况下大部分时分,关于某一类数据恣意时间只需一个单元会担任写入某个节点,其他节点要么是实时库间同步,要么是异步数据同步。

OB 也采用了 PAXOS 一起协议。实时库间同步的节点个数至少需求 +1 个,这样就能够处理分区忍受性问题。

下面咱们举个马教师改英文名的比方来阐明 OB 规划的精妙之处:

假定数据库依照用户 ID 分库分表,马教师的用户 ID 对应的数据段在 [0-9],开端由单元 A 担任数据写入。

假定马教师正在用付出宝 App 修正自己的英文名,马教师一开端打错了,打成了 Jason Ma,A 单元收到了这个恳求。

这时分发作了分区,咱们将单元 A 对数据段 [0,9] 的写入权限转交给单元 B,马教师这次写对了,为 Jack Ma。

而在网络断开前恳求现已进入了 A,写权限转交给单元 B 收效后,A 和 B 一同对 [0,9] 数据段进行写入马教师的英文名。

假定这时分都答应写入的话就会呈现不一起,A 单元说我看到马教师设置了 Jason Ma,B 单元说我看到马教师设置了 Jack Ma。

可是这种状况不会发作的,A 提议说我主张把马教师的英文名设置为 Jason Ma 时,发现没人回应它。

由于呈现了分区,其他节点对它来说都是不行达的,所以这个提议被主动丢掉,A 心里也了解是自己分区了,会有主分区替自己完结写入使命的。

相同的,B 提出了将马教师的英文名改成 Jack Ma 后,大部分节点都呼应了,所以 B 成功将 Jack Ma 写入了马教师的账号记载。

假定在写权限转交给单元 B 后 A 忽然康复了,也没联系,两笔写恳求一同要求取得 +1 个节点的业务锁,经过 no-wait 规划,在 B 取得了锁之后,其他争抢该锁的业务都会由于失利而回滚。

下面咱们剖析下 OB 的 CAP:

所以 OB 依然没有逃脱 CAP 魔咒,发作分区的时分它变成 AP+终究一起性。全体来说,它是 AP 的,即高可用和分区忍受。

个人感觉本文触及到的知识面的确不少,每个点独自打开都能够谈论半响。回到咱们紧扣的宗旨来看,双十一海量付出背面技能上皆大欢喜的规划究竟是啥?

我想无非是以下几点:

比方用户创立这种 TPS,不会高到哪里去。再比方关于实时库存数据,能够经过“页面展现查询走运用层缓存”+“实践下单时再校验”的办法削减其 GZone 调用量。

而这便是蚂蚁 LDC 的 CRG 架构,信任 54.4 万笔/秒还远没到 LDC 的上限,这个数字能够做到更高。

当然双 11 海量付出的成功不单单是这么一套规划所决议的,还有预热削峰等运营+技能的手法,以及成百上千的兄弟姐妹一同奋战,特此在这向各位双 11 留守同学问候。

感谢咱们的阅览,文中或许存在缺乏或遗失之处,欢迎批评指正。

参考文献:

https://www.cnblogs.com/zero-gg/p/9057092.html

https://www.jianshu.com/p/f6157118e54b

https://baike.baidu.com/item/Keepalived/10346758?fr=aladdin

https://en.wikipedia.org/wiki/Paxos_

https://www.cnblogs.com/antfin/articles/10299396.html

https://en.wikipedia.org/wiki/Backup

作者:汤波

简介:阿里巴巴架构师,酷爱技能,坚信技能让国际更夸姣。对前沿技能一向坚持饥饿感,热衷于立异和改造,让体系体系更为高效和人性化,也深知一个人强走的快,一个集体强才干走的远。在技能团队建造、技能栈办理和项目研制办理方面有着较为丰厚的实践经验。重视范畴:SaaS,PaaS,Serverless,Service mesh,新零售,区块链,人工智能,互联网全栈,散布式企业级开发,网络运用/协议开发,核算机算法运用。

热门文章

随机推荐

推荐文章