支付宝单元化架构和异地多活

[TFdream]

转载自 【Java基基】支付宝架构有多牛？还没看完我就跪了：https://mp.weixin.qq.com/s/xNsNNRau20OatgIlXbW-ng

[TFdream]

大纲

• LDC 和单元化
• 系统架构演化史
• 蚂蚁单元化架构实践
• 支付宝单元化的异地多活和灾备
• 蚂蚁单元化架构的 CAP 分析
• 蚂蚁单元化 LDC 架构 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 魔咒么？

如果你对这些感兴趣，不妨看一场赤裸裸的论述，拒绝使用晦涩难懂的词汇，直面最本质的逻辑。