淺析 阿里 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 內存）， 再加上 固態硬盤 ，

可以達到 接近 或者 類似 阿里 淘寶 天貓 架構 的 效果 。