架构师技术联盟的业务多活架构和分布式CAP实战，数据库分库分表演进的学习笔记
数据库单实例
不管是第一张单体应用，还是第二张分布式服务架构应用，里边的数据库都是单实例。
第二张分布式服务架构，只是对某个应用进行了水平扩容，它将多个微机的计算能力团结了起来，可以完胜同等价格的中小型机器。
数据库多实例之单实例读和写
数据库单实例挂了，整个系统也就跟着挂了，该系统没有高可用性可言。
数据库变为多实例(2个或3个)，但只从数据库的主节点读和写。
数据库多实例之读写分离(单实例写)
随着业务量上涨，应用服务器 CPU 都很正常了，但是有很多慢请求，究其原因，是因为单点数据库带来了性能瓶颈。
于是程序员们决定使用主从结构的数据库集群，如下图所示：
其中大部分读操作直接访问从库，从而减轻主库的压力。然而这种方式还是无法解决写瓶颈，写依旧需要主库来处理，当业务量量级再次增高时，写已经变成刻不容缓的待处理瓶。
数据库多实例之分库分表
随着业务量上涨，单实例写暴露出无法满足写瓶颈的问题。这时候，分库分表方案出现了：
分库分表不仅可以对相同的库进行拆分，还可以对相同的表进行拆分，对表进行拆分的方式叫做水平拆分。
不同功能的表放到不同的库里，一般对应的是垂直拆分（按照业务功能进行拆分），此时一般还对应了微服务化。
这种方法做到极致基本能支撑 TPS 在万级甚至更高的访问量了。然而随着相同应用扩展的越多，每个数据库的链接数也巨量增长，这让数据库本身的资源成为了瓶颈。
这个问题产生的本质是全量数据无差别的分享了所有的应用资源，比如 A 用户的请求在负载均衡的分配下可能分配到任意一个应用服务器上，因而所有应用全部都要链接 A 用户所在的分库，数据库连接数就变成笛卡尔乘积了。
数据库多实例之单元化
在本质点说，以上这种数据库分库分表模式的资源隔离性还不够彻底。要解决这个问题，就需要把识别用户分库的逻辑往上层移动，从数据库层移动到路由网关层。
这样一来，从应用服务器 a 进来的来自 A 客户的所有请求必然落库到 DB-A，因此 a也不用链接其他的数据库实例了，这样一个单元化的雏形就诞生了。
思考一下，应用间其实也存在交互（比如 A 转账给 B），也就意味着，应用不需要链接其他的数据库了，但是还需要链接其他应用。
如果是常见的 RPC 框架如 Dubbo 等，使用的是 TCP/IP 协议，那么等同于把之前与数据库建立的链接，换成与其他应用之间的链接了。
为啥这样就消除瓶颈了呢？首先由于合理的设计，应用间的数据交互并不巨大，其次应用间的交互可以共享 TCP 链接，比如 A->B 之间的 Socket 链接可以被 A 中的多个线程复用。
而一般的数据库如 MySQL 则不行，所以 MySQL 才需要数据库链接池。
如上图所示，我们把整套系统打包为单元化时，每一类的数据从进单元开始就注定在这个单元被消化，由于这种彻底的隔离性，整个单元可以轻松的部署到任意机房而依然能保证逻辑上的统一。
网友评论