OB君：你们都很关心的 “OB双11大促实战分享” 专题来啦！本系列将为你系统性的介绍OceanBase支撑蚂蚁双11背后的技术原理和实战分享。从平台到架构，再到实现，一起来探索蚂蚁双11这场神秘的技术之旅吧！
背景
伴随着蚂蚁业务的蓬勃发展，特别是每年双11大促不断创造新的高峰， 交易支付核心链路提出了未来实现百万笔支付/秒的能力 。为了实现这个宏伟目标，特别是提高数据库层面分布式扩展能力，如原生sharding/分布式事务优化，OceanBase 2.0分布式数据库应运而生。
百万支付
传统数据库扩容方案，主要是依赖分库分表拆分进行水平扩容，蚂蚁数据库初期也是同样思路，通过LDC单元化改造，核心表按用户UID维度拆分成百库百表。
但是随着业务发展，特别是2017年的双11大促，峰值需求已经远远超过单库单机的最大容量。针对这个问题，我们使用弹性架构，即在大促前，新增两套弹性数据库，多套库共同支持大促峰值。弹性架构虽然解决了大促容量需求，但是也存在一些缺陷，业务在数据路由、后期维护及数据配套设施都非常复杂繁琐。有没有更优雅的分布式数据库解决方案，即只使用一个库，就可以支持百万甚至更高的支付峰值，OceanBase 2.0分区提供了完美的解决方案。
OceanBase 2.0整体架构
原理分析
OceanBase 2.0分区方案思路和传统的分库分表拆分一样。我们在交易支付核心库上，在原有百库百表的基础上继续按用户UID进行更深层次拆分，每个分表再拆分成多个partition，应用端只看到一张表，在用户无感知的前提下把数据拆分到无限多的机器上，突破单机性能瓶颈，自动负载均衡，从而实现百万支付的能力。
同时为了极致性能，OceanBase 2.0提供了partition group功能，将业务使用的多张逻辑表（table_1、table_2、... table_n），按共同的partition聚合在同一台服务器上面，从而避免了分布式事务带来的额外开销。
OceanBase 2.0分区方案
关键点：
- APP端请求SQL，带上包含分区的字段—UID信息（如payment_id列)
- SQL如果没有分区信息，则在OBServer端并行计算优化
- OBClient负责分区计算及路由，确保第一跳准确定位到对应分区所在服务器，避免远程执行
- OBServer端基于生成列partition_id进行内部分区，不侵入业务
- OBServer端约束描述多维度分区，实现分区裁剪功能
优点：
- 业务友好：不改变SQL语义，应用代码不感知分区信息
- 架构通用：约束功能，实现分区裁剪；OBServer提供兜底访问能力
- 高性能低成本：使用低配置服务器，自动负载均衡，资源利用率高
OceanBase 2.0性能优化
- 分布式事务消除：partition group方式，事务涉及所有表的partition按照分区键存储至同一物理机
- 两阶段提交协议优化：结合事务与日志，事务prepare成功后内存不用持久保存状态，按需从日志中查询；commit状态持久化转换成后台批量完成
- Commit异步化：异步化后Worker不等待继续执行队列中下一个请求，日志持久化成功后会异步回调
- 内存分配器优化：组织了两层映射关系，既要提升性能又要支持大量分区
- 存储优化：数据编码技术实现高压缩
优化结果：
整体性能OceanBase 2.0版本较OceanBase 1.4版本性能提升50%，存储空间节省30%。
总结
2018天猫双11全球狂欢节成交额超过2135亿，OceanBase 2.0成功经受住了考验，全面支撑了支付宝核心链路 ，平稳抗住0:00:00时的峰值压力，夯实三年战略“百万支付”的底盘能力。
OceanBase 2.0还有很多重要特性，比如分布式全局索引、分布式全局一致性快照、分布式存储过程、索引实时生效、Flashback闪回功能等，这些新功能将强有力支持企业不同业务场景下的持续创新。
