浅析 阿里 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 内存), 再加上 固态硬盘 ,

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

 

 

 

原文地址:https://www.cnblogs.com/KSongKing/p/10208644.html