我們先作一個 設定：

每秒 100 萬 ~ 1000 萬 的 併發量 稱為 “海量” ，  每秒 1000 萬 以上的 併發量 稱為 “天量”  。

我們 再來 看看 2 篇文章 ：

《架構設計之路：微信紅包百億級高併發資金交易系統設計架構》    http://www.dalbll.com/Group/Topic/ArchitecturedDesign/3890

《螞蟻金服CTO程立：金融級分散式交易的技術路徑》    https://mp.weixin.qq.com/s?__biz=MzI3MzEzMDI1OQ==&mid=2651820298&idx=1&sn=e01179f16295ac1fddc3c33696845fe4&pass_ticket=x5Fg0DIJJTts0Q0AOp8Pl7lE1IfSRHDbLIfxCyx2Jaepbwcp2%2F%2BW9%2Flg0GlB3aAD

第一篇 簡稱 《微》文， 第二篇 簡稱 《螞》文 。

我們再看看 我的 上一篇 文章  《論 大併發 下的 樂觀鎖定 Redis鎖定 和 新時代事務》    https://www.cnblogs.com/KSongKing/p/9934722.html

我的這篇 簡稱 《樂》文 。

在 《微》文 中， 提到 分庫 分表 的 架構， 在 《螞》文中， 提到了 OceanBase， 

在 我的 《樂》文中， 沒有涉及到 分庫 分表， 但是 提到了 行級鎖， 

從某個角度來看， 行級鎖 和 分庫分表 是 相似的，

比如， 如果  1 張表 只 包含 1 筆 記錄，  則 表鎖定 就是 行鎖定 。

對於 海量 併發， 以 1000 萬 每秒 來看，  假設每個 Sql 長度是 1K Bytes，  則 湧向 資料庫 的 流量 是 1K * 1000 萬 = 100 G Bytes = 800 G Bits  每秒 。

千兆網絡卡 的 頻寬 是   1K * 1M =  1 G Bits  ，

流量 是  800 個 千兆網絡卡 的 流量 。

然後 。

所以， 這種情況 不是 集中式 架構 能夠 處理的 。

應該 或者說 必然 要將 流量 分流 到 多臺 Server， 或者說， 將 Sql 請求 分流 到 多臺 資料庫伺服器 （DB Server） 。

並且， 集中式 的 負載均衡 是 不適用 的 。

應該是 由 應用伺服器（AP Server） 自主 選擇 連到 不同的 資料庫伺服器（DB Server） 。

分庫 分表 再加上 分機 ，    這算是一個  手工版  的   OceanBase   ？

所謂 分機，   是指 把分出來的 若干個庫 放到 若干臺 DB Server 上 。

比如 1 個 庫 放 1 臺 DB Server，   有 10 個 庫 就 放 10 臺 DB Server 。

也可以 幾個庫 放 1 臺 DB Server，

比如 有 10 個 庫， 1 ~ 3 放 DB Server 1， 4 ~ 6 放 DB Server 2， 7 ~ 10 放 DB Server 3  。

我覺得 差不多，

OceanBase 是 從 通用 的 角度 來 進行 分庫 分表，  目的 是 建造一個 通用 的 分散式 資料庫 ，

分庫 分表 是 針對 業務 進行 分散式 的 設計 。