业务多活架构和分布式CAP实战.docx

? ? ? ? ? ? ? ? 业务多活架构和分布式CAP实战 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  自2008 年双11 以来，在每年双 11 超大规模流量的冲击上，蚂蚁金服都会不断突破现有技术的极限。2010 年双 11 的支付峰值为 2 万笔/分钟，到 2017 年双 11 时这个数字变为了 25.6 万笔/秒。 2018 年双 11 的支付峰值为 48?万笔/秒，2019 年双 11 支付峰值为 54.4 万笔/秒，创下新纪录，是 2009 年第一次双 11 的 1360?倍。 在如此之大的支付 TPS 背后除了削峰等锦上添花的应用级优化，最解渴最实质的招数当数基于分库分表的单元化了，蚂蚁技术称之为 LDC（逻辑数据中心）。 本文不打算讨论具体到代码级的分析，而是尝试用最简单的描述来说明其中最大快人心的原理。 我想关心分布式系统设计的人都曾被下面这些问题所困扰过： 支付宝海量支付背后最解渴的设计是啥？换句话说，实现支付宝高 TPS 的最关键的设计是啥？ LDC 是啥？LDC 怎么实现异地多活和异地灾备的？ CAP 魔咒到底是啥？P 到底怎么理解？ 什么是脑裂？跟 CAP 又是啥关系？ 什么是 PAXOS，它解决了啥问题？ PAXOS 和 CAP 啥关系？PAXOS 可以逃脱 CAP 魔咒么？ Oceanbase 能逃脱 CAP 魔咒么？ 如果你对这些感兴趣，不妨看一场赤裸裸的论述，拒绝使用晦涩难懂的词汇，直面最本质的逻辑。 LDC 和单元化 LDC（logic data center）是相对于传统的（Internet Data Center-IDC）提出的，逻辑数据中心所表达的中心思想是无论物理结构如何的分布，整个数据中心在逻辑上是协同和统一的。 这句话暗含的是强大的体系设计，分布式系统的挑战就在于整体协同工作（可用性，分区容忍性）和统一（一致性）。 单元化是大型互联网系统的必然选择趋势，举个最最通俗的例子来说明单元化。 我们总是说 TPS 很难提升，确实任何一家互联网公司（比如淘宝、携程、新浪）它的交易 TPS 顶多以十万计量（平均水平），很难往上串了。 因为数据库存储层瓶颈的存在再多水平扩展的服务器都无法绕开，而从整个互联网的视角看，全世界电商的交易 TPS 可以轻松上亿。 这个例子带给我们一些思考：为啥几家互联网公司的 TPS 之和可以那么大，服务的用户数规模也极为吓人，而单个互联网公司的 TPS 却很难提升？ 究其本质，每家互联网公司都是一个独立的大型单元，他们各自服务自己的用户互不干扰。 这就是单元化的基本特性，任何一家互联网公司，其想要成倍的扩大自己系统的服务能力，都必然会走向单元化之路。 它的本质是分治，我们把广大的用户分为若干部分，同时把系统复制多份，每一份都独立部署，每一份系统都服务特定的一群用户。 以淘宝举例，这样之后，就会有很多个淘宝系统分别为不同的用户服务，每个淘宝系统都做到十万 TPS 的话，N 个这样的系统就可以轻松做到 N*十万的 TPS 了。 LDC 实现的关键就在于单元化系统架构设计，所以在蚂蚁内部，LDC 和单元化是不分家的，这也是很多同学比较困扰的地方，看似没啥关系，实则是单元化体系设计成就了 LDC。 小结：分库分表解决的最大痛点是数据库单点瓶颈，这个瓶颈的产生是由现代二进制数据存储体系决定的（即 I/O 速度）。 单元化只是分库分表后系统部署的一种方式，这种部署模式在灾备方面也发挥了极大的优势。 系统架构演化史 几乎任何规模的互联网公司，都有自己的系统架构迭代和更新，大致的演化路径都大同小异。 最早一般为了业务快速上线，所有功能都会放到一个应用里，系统架构如下图所示： 这样的架构显然是有问题的，单机有着明显的单点效应，单机的容量和性能都是很局限的，而使用中小型机会带来大量的浪费。 随着业务发展，这个矛盾逐渐转变为主要矛盾，因此工程师们采用了以下架构： 这是整个公司第一次触碰到分布式，也就是对某个应用进行了水平扩容，它将多个微机的计算能力团结了起来，可以完胜同等价格的中小型机器。 慢慢的，大家发现，应用服务器 CPU 都很正常了，但是还是有很多慢请求，究其原因，是因为单点数据库带来了性能瓶颈。 于是程序员们决定使用主从结构的数据库集群，如下图所示： 其中大部分读操作可以直接访问从库，从而减轻主库的压力。然而这种方式还是无法解决写瓶颈，写依旧需要主库来处理，当业务量量级再次增高时，写已经变成刻不容缓的待处理瓶 这时候，分库分表方案出现了： 分库分表不仅可以对相同的库进行拆分，还可以对相同的表进行拆分，对表进行拆分的方式叫做水平拆分。 不同功能的表放到不同的库里，一般对应的是垂直拆分（按照业务功能进行拆分），此时一般还对应了微服务