我们先作一个 设定：
每秒 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 是 从 通用 的 角度 来 进行 分库 分表， 目的 是 建造一个 通用 的 分布式 数据库 ，
分库 分表 是 针对 业务 进行 分布式 的 设计 。