浅析 阿里 OceanBase 双十一 淘宝天猫 天量交易 承载能力 原理

我们先看看 这 2 篇文章：

《秘诀！支付宝支撑双十一4200万次/秒的数据库请求峰值的技术实现》  https://mp.weixin.qq.com/s?__biz=MzI3MzEzMDI1OQ==&mid=2651820306&idx=1&sn=6220b250d8970822e8c63a49fc1c4442&chksm=f0dcc76ec7ab4e782a683c4532304eb75cef2d8f24fa9abcdc692e865a97e7fd0d145ee0452f&mpshare=1&scene=1&srcid=05110uUhHlasVkvsuwF1pZsd&pass_ticket=lfqxD4r1E1dgDxTqGUsQTSjApCKuffPi3swo8QNXfC9dq3nzpLHNpn4f7IJMM42n#rd

《蚂蚁金服CTO程立：金融级分布式交易的技术路径》  https://mp.weixin.qq.com/s?__biz=MzI3MzEzMDI1OQ==&mid=2651820298&idx=1&sn=e01179f16295ac1fddc3c33696845fe4&chksm=f0dcc776c7ab4e604e1d7d3171708a40331e1e0dce100579026df9b4365be1f7af0e37da5e0a&mpshare=1&scene=1&srcid=0509JF8HPfpgyAQL3orPFGXq&pass_ticket=lfqxD4r1E1dgDxTqGUsQTSjApCKuffPi3swo8QNXfC9dq3nzpLHNpn4f7IJMM42n#rd

我之前也写过 2 篇文章 ：

《海量 并发 下 的 系统架构 和 数据库 发展之路》  https://www.cnblogs.com/KSongKing/p/9937135.html

《论 大并发 下的 乐观锁定 Redis锁定 和 新时代事务》  https://www.cnblogs.com/KSongKing/p/9934722.html

阿里 的 OceanBase 高速的数据处理 和 应对大并发 的 能力 的 基础 是 内存计算， 即 在 内存 里 对 数据 进行计算， 而不是在计算时 频繁的 读写 外部存储器 。

对于 事务（Transaction），  OceanBase 应该不会把 事物日志 写到 外部存储器（磁盘 固态硬盘）， 而是 写入 多个 服务器节点 的 内存，

通过 多节点 来实现 可靠性 。 比如 要超过 2/3 的 节点 正常的 写入了 事务日志 ， 才会开始 事务 。

这同样是为了 提升速度，  事务日志 如果写入 外部存储器 的话， 时间上来不及，  对 天量交易 来说 太慢了。

从 内存计算 这一点 来看，  OceanBase 和  12306 搭建 的 Gemfire 集群 是 相似 的 。

有关 12306 架构， 可以参考我之前写的另一篇文章  《漫谈 12306 架构》  https://www.cnblogs.com/KSongKing/p/9550000.html

Gemfire 也是一个 内存数据库， 不过不是 关系数据库， 是一个 Key Value 数据库， 支持 组建集群， 也就是 水平扩展， 这样可以 增加 处理器 和 内存 数量 来 支持 大并发 。

而 OceanBase 和 Gemfire 集群 两者 在 实际中 对 并发 的 处理规模 也是可以 相提并论 的 。

但是， 光凭 内存计算 等 技术 实现的 卓越性能 是否能够 应对 “天量”交易 ？

不能 。

我们 可以作一个 设定，  每秒 1000万次 以上 的 交易量 称为 “天量" 。

下面 我们 以 每秒 1000万次 作为目标 来 分析 如何达到 每秒 1000万次 这样的并发量 。

一个 CPU 核， 能够处理 每秒 1000次 的 事务 就已经不错了 。 即使采用了 内存计算， 能够达到 每秒 1000次， 已经不错了 。

这是一个什么概念呢？   就是    1 毫秒（ms） 处理一个 事务 。 也就是     1 秒 能处理  1000 个 事务 。

所以， 对于 每秒 1000万次 的 事务， 需要    1000万 / 1000  =  1 万 个 CPU 核 ，

如果 以  每台服务器   100 核 来看， 需要 100 台 服务器，

如果 以  每台服务器   50 核 来看， 需要 200 台 服务器 。

大概是 这么一个 体量 。

其次， 需要在 业务层面 进行 很细 的 分库分表 。

因为  事务  会 锁定 表，  这会导致 即使 有 1 万 个 CPU 核 ，  但是对于 A 表 的 操作 同时也只能有  一个 核（线程）能进行 。

这就又回到了 和  单核（单线程） 等价 的 情形 。

大家可能会 提出，  能不能用 行锁定 和 乐观锁定 来 代替 表锁定 ？

这 2 种方式 我在 上面 引用的 我写的 另外一篇文章  《论 大并发 下的 乐观锁定 Redis锁定 和 新时代事务》 里都分析过 。

但 ，   ……

而且 除了锁， 事务 还有另外一个作用， 就是 数据完整性， 即 交易失败 时， 数据 可以恢复原样 。

所以， 总的来说，  传统事务 还是 必需 的 。

所以， 需要在 业务层面 进行 很细 的 分库分表 。

既然 有 1 万 个 核 ，  最好能 分成  1 万 个 表，  这样每个 核 一个 表，  大家互相不会干扰， 可以 跑 的 很开心 。

1 万 个  核  一起 欢快的 奔跑 着，   啦啦啦   ~~~

至于 分几个 库，   那 大家 看着办 好了 。

而实际上，  对于 淘宝 天猫 的 业务 来讲， 还真 可以 分  1 万 个 表 。

对于 淘宝 天猫 这样的 零售业 来讲，  交易 大部分 是 购买 付账 ，  在 交易 里 要做的事 是 判断 库存剩余量， 修改商品状态， 修改库存 。

这样就可以 按照      商户 商品类别    来 分库 分表 。

那么， 既然这样的话，  我们提出一个问题，

能不能不用 OceanBase ，  用 其它 常用的 数据库， 比如  Oracle,  SqlServer,   MySql,   PostgreSql   等 来 实现 和 阿里 类似 的 架构 和 效果 ？

能 。

我们以  Sql Server  为例 ，  Sql Server 发展到现在， 在 利用 多核 和 内存 上 做的很好 。

我们 以  SqlServer 2017  为例， 按照上面计算出来的 体量，  部署 200 台 服务器，  每台 服务器 CPU 50 核， 内存 100 G（相当于 每个 核  2 G 内存）， 再加上 固态硬盘 ，

可以达到 接近 或者 类似 阿里 淘宝 天猫 架构 的 效果 。