共计 4560 个字符，预计需要花费 12 分钟才能阅读完成。
8 月 10 日，2022 OceanBase 年度发布会在京沪深三地同时召开， 支付宝资深数据库专家邓荣伟在会上分享了《从“小”到“大”，支付宝分布式降级之路》的主题演讲 ，为咱们带来了支付宝的架构演进以及上线 OceanBase 的故事。
以下为演讲实录分享：
大家都晓得支付宝是 OceanBase 的“元老级”用户，支付宝的每一次架构演进都与 OceanBase 的版本迭代非亲非故。明天，我将从支付宝的数据库架构演进开展，次要围绕以下三个方面进行分享：
第一，支付宝在线库架构演进；
第二，支付宝历史库架构，面对 PB 级数据归档，如何横向有限扩大；
第三，面对多样化存储需要，支付宝的将来摸索。
支付宝在线库架构演进
过来式：OceanBase 1.0 时代的进化
支付宝一开始诞生在“IOE”时代，数据库首选 IBM 小型机 +Oracle 数据库 +EMC 的传统搭配。然而，当支付宝迎来第一个“双 11”，与之而来呈现“峰值脉冲”，原单库单表的集中式数据库计划天然扛不住如此高的流量。所以，支付宝在很晚期就进行了拆库拆表，由此诞生了基于中间件计划的第一代分布式架构。
随着支付宝的用户规模一直增长，以及历年“双 11”都须要应答超高并发，传统架构性能瓶颈凸显，数据存储老本攀升。2013 年 5 月，支付宝下线最初一台 IBM 小型机之后，开始下一步的降级迭代，家喻户晓，外围底层存储的替换挑战十分大，支付宝对新数据库不仅要求成本低，还要求具备高性能、可扩大、高可用等个性，OceanBase 就在这种背景下诞生了。
如下图所示，是支付宝在 2017 年之前整个数据库架构的演进。首先是底层存储全副替换为 X86，而后是数据库从 Oracle 降级为 OceanBase 0.5、再到 OceanBase 1.0。
阳老师在《OceanBase 4.0 核心技术解读》中分享了 OceanBase 的版本迭代历程。在 0.5 时代，OceanBase 因为读是分布式的，写是集中式的，所以没有方法将性能做到极致。在 1.0 时代，OceanBase 实现了一个集群内所有节点都是对等的，每个节点都能够进行读写，成为真正的分布式数据库。
OceanBase 1.0 是支付宝投产工夫最长、利用范畴最广的版本，次要有以下三个特点：
多租户。多租户能在中小数据库整合场景中很好地晋升资源利用率，例如，咱们上线一套 MySQL 或 Oracle，遇到流量激增时会不得不进行拆库拆表，但 OceanBase 能以租户为资源载体的形式进行动静扩容。
高可用。支付宝的金融场景，要求数据库必须满足机房级容灾、城市级容灾，OceanBase 是基于 Paxos 协定的分布式数据库，先天满足这些诉求。
弹性伸缩。历年“双 11”，支付宝都会转移一部分流量去一个“泡”在湖水中的数据中心——千岛湖数据中心。当支付宝还在应用传统关系型数据库时，数据库弹出只能通过主备库的形式先在千岛湖数据中心搭一个备库，而后主备切换过来。但这种形式会有切换闪断问题，业务有感知。迁徙至 OceanBase 后，数据库弹出能够间接应用 OceanBase 的加减正本、平滑切主个性，在用户不感知的状况下实现弹出。此外，OceanBase 能够做到在大促峰值完结 30 分钟内开释数千台服务器给其余业务应用。
当初式：稳固撑持每秒百万笔领取申请
大家都晓得，每年双 11 的各项数据都在增长，到了 2017 年的双 11 期间，1 % 的压力峰值就曾经超过了单库单机的最大容量。传统数据库扩容计划次要依赖分库分表拆分进行程度扩容，用多套库的形式独特扛流量峰值。尽管这种计划可行，但存在很多弊病，比方多套数据源、多套 DB 集群，减少了配置管理、日常治理老本。
咱们须要更优雅的分布式数据库解决方案，即只应用一个库，就能够反对百万甚至更高的领取峰值，让横向扩容间接在数据库闭环，做到利用不感知，OceanBase 2.0 分区提供了完满的解决方案。
OceanBase 2.0 分区计划思路和传统的分库分表拆分一样。咱们在交易领取外围库上，在原有百库百表的根底上持续按用户 UID 进行更深层次拆分，每个分表再拆成一百个 Partition，利用端只看到一张表，在用户无感知的前提下把数据拆分到更多的机器上，冲破单机性能瓶颈，主动负载平衡，从而实现稳固撑持每秒百万笔领取申请的能力。
这时候大家可能会有两个疑难，为什么曾经领有分区能力，还要用分表加上分区的计划。支付宝是一个单元化部署架构，分库分表是架构的一个根底，所以分库分表不能变，在此基础上能够持续分区。这样，用户看起来还是百库百表，而后通过 OceanBase 主动负载平衡，把 1% 的表主动均摊到多台机器上，以此冲破单机容量下限。
那么，OceanBase 是否在不分区的前提下应用多台机器资源？答案是能够的，支付宝外部也有很多零碎没有分区，间接将单库多表均摊到多台机上的利用场景。以及，OceanBase 的分区表，是否肯定要业务指定分区 ID，这其实须要依据业务场景而定，如果业务场景谋求极致性能，倡议指定分区 ID，咱们能够依照肯定的规定分区，通过利用或中间件计算出分区 ID，只有让 OBProxy 感知到分区，SQL 路由到正确的机器上即可，否则须要 OceanBase 外部二次路由，性能稍有衰减。
同时，OceanBase 2.0 为了极致性能引入 Partition Group，将业务应用了一组逻辑表的雷同分区，汇集在雷同的 OceanBase 节点，使分布式事务进化为单机事务做到极致性能。具体来说，假如当初是单库单表，当某业务做一笔领取申请要在这三张表里落数据时，当初是依照用户的 UID 维度，依照雷同的分表分区规定做拆分，用户领取之后肯定是在这三个表的同一个分区落数据，也就是说，这三个表雷同分区就能够满足用户的整个业务逻辑，所有操作不须要跨机、不须要产生分布式事务。
当初，OceanBase 2.0 版本在支付宝也承当了十分多的外围业务，次要有以下三个特点：
高兼容。OceanBase 反对 MySQL/Oracle 语法，让支付宝在数据库迁徙时老本代价更低。
性能晋升，老本降落。单库单表能够扩大到多机，单库容量不再受限于单机硬件能力。绝对 OceanBase 1.0，数据库整体性能晋升 50%，存储空间节俭 30%。
更低的运维老本，更好的弹性能力。以前支付宝做数据库弹出的时候，须要业务配合。当初，OceanBase 数据库能够横向伸缩，在数据库上就曾经闭环，业务不感知，根本一键实现了这件事。
迁徙 OceanBase 之路
Oracle/MySQL 是支付宝最早投入使用的数据库，体量十分大，这种传统关系型数据库在扩大、容灾等能力上存在短板，没方法满足支付宝的倒退诉求。此外，对于咱们 DBA 来说，一是常常要去放心数据一致性问题，二是不得不反复保护多套运维体系、容灾体系以及生态工具，代价十分大。所以，支付宝开始规模化地将 Oracle/MySQL 全副迁徙至 OceanBase。当初，支付宝全栈都运行在 OceanBase 上。
异构数据库迁徙是一个简单的过程——次要是兼容性和数据品质的问题。为了高效迁徙，OMS（OceanBase Migration Service，OceanBase 数据迁徙工具）提供一站式的异构数据库上 OceanBase，首先为了应答兼容性问题，平台提供动态代码评估，动静流量回放评估，其次数据品质通过全量校验，增量校验，离线校验等多重伎俩实时保证数据一致性。
迁徙至 OceanBase 后，一方面是效率晋升，DBA 能够更从容地应答日常的容量容灾问题，日常容量应急、故障切换配合运维体系曾经齐全自动化，打算内的大促弹性和容灾演练都能够一键实现；一方面是老本升高，首先是 OceanBase 的多租户整合 Oracle/MySQL 长尾业务，优化碎片资源，其次是 OceanBase 的超高数据压缩比。让我印象十分粗浅的是，过后支付宝最初一批传统集中式数据库下线，本来须要上百台机器，迁徙至 OceanBase 后，10 台左右机器就解决了。
PB 级数据归档
随着越来越多的业务迁徙到 OceanBase，以及支付宝的业务倒退迅猛，咱们面临生产库磁盘有余、IOPS 性能降落，以及备份工夫变长等问题，数据归档就变得十分重要。
如何高效且低成本地把这些数据归档呢？过来，咱们要么引入高端商业存储阵列，要么引入新一代分布式存储。当初，咱们只须要用 SATA 盘 X86 加 OceanBase 的分布式能力，就能够轻松搞定单库 PB 级存储。
其实，历史库总结起来就两个外围点，即负载平衡和故障复原。
外围点一：负载平衡
负载平衡最次要的目标就是在老本尽量低的状况下让存储利用率和计算资源利用率尽量高。
存储利用率最大化。随着集群规模一直变大，一直接入更多业务，再加上不同年份洽购机器型号的差别，会逐步呈现木桶短板效应，少部分机器影响整个集群磁盘使用率，节约存储的问题。OceanBase 针对该问题做了非凡优化——基于分区级别进行动静的负载平衡，能最大限度利用每台机器的磁盘空间。
计算资源利用率最大化。历史库个别依照工夫分区，很容易呈现雷同月份的分区汇集在大量机器，导致写入热点，压力不平衡。OceanBase 针对该问题也做了非凡优化——为了充分发挥每台机器的计算资源，OceanBase 将不同表雷同月份的分区打散到不同机器，所有 Parition 的 leader 也平衡打散到所有机器，扩散写入，避免写入热点。
外围点二：故障复原
不管故障机器是否彻底宕机，替换的新机器都会作为指标迁入数据，瓶颈都在新机器单机的写入能力。依照一般 SATA 盘 200MB/s 的写入能力计算，100TB 数据迁徙简直须要一周工夫。过长的替换工夫会带来十分多的弊病，如可能呈现二次宕机呈现单正本，变更周期过长，容易呈现失误。
鉴于惯例替换工夫长的种种弊病，咱们利用 OceanBase 的原生分布式能力，减速替换。只须要两步，首先新机器上线，其次故障机器间接永恒下线，OceanBase 的总控服务 RootService 检测正本缺失，间接走补正本模式，补正本是多机到多机拷贝，生产可达 30-50GB/s，100TB 数据迁徙只需两三个小时就能够实现。
支付宝的将来摸索
支付宝的业务场景十分丰盛，对存储能力的需要也是多样化的，将来，咱们 DBA 团队次要会围绕 HTAP 和多模这两方面做一些摸索，继续打磨 OceanBase 的能力。
一是 HTAP 方面的摸索。目前蚂蚁实现 HTAP 链路简单，和传统计划一样，订阅在线日志到数仓进行计算，不仅保护老本过高，而且过多依赖第三方组件，经常出现可用性事件。将来咱们将在 OceanBase OLTP 能力的根底上扩大 OLAP 的能力，能够实现一个零碎、一份数据同时解决交易和实时剖析的高性价比计划，“一份数据”的多个正本能够存储成多种状态（行存 / 列存），用于不同的工作负载。
二是多模方面的摸索。过来为了满足一种业务场景对存储的需要，比方文档、KV、时序等，咱们须要引入全新的一种数据库，保护多套运维零碎，反复建设容灾体系。在将来，咱们将在 OceanBase 对立的存储引擎和分布式引擎之上倒退多模型能力，实现一份数据，多种拜访形式，更加轻松应答多样化的存储需要。
我明天的分享就到这里，心愿能对大家有所帮忙，谢谢大家。
