海量 并发 下 的 系统架构 和 数据库 发展之路

我们先作一个 设定：

每秒 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 是 从 通用 的 角度 来 进行 分库 分表，  目的 是 建造一个 通用 的 分布式 数据库 ，

分库 分表 是 针对 业务 进行 分布式 的 设计 。