3种数据库表拆分的解决方案

数据库拆分的方式有两种，即垂直拆分和水平拆分，分库分表是对数据库拆分的一种解决方案。根据分库分表方案中实施切片逻辑的层次不同，我们可以将数据库分库分表的实现方案分为三大类：

• 客户端分片
• 代理分片
• 支持事务的分布式数据库

客户端分片
就是使用分库分表的数据库的应用层直接操作分片的逻辑，分片规则需要在同一个应用的多个节点之间进行同步，每个应用层都嵌入一个操作切片的逻辑实现（分片规则），这个一般通过依赖jar包来实现。

具体的实现方案又可以分成三种：

• 在应用层直接实现
• 通过定制JDBC协议实现
• 通过定制ORM框架实现

若想了解这3种实现方案的具体内涵与内容，V信扫描下面二维码，关注后回复“实现方式”即可～

代理分片
就是在应用层和数据库层之间加一层代理层，把分片的路由规则配置在代理层，代理层对外提供与JDBC相兼容的接口给应用层，应用层的开发小伙伴们就不用关心分片规则了，只需要关心业务代码的实现，等业务代码实现完了以后，在代理层配置一个路由规则就搞定了。
优缺点：

优点：让应用层的开发小伙伴们更多去关注业务代码的实现，把分库分表的配置留给代理层做。

缺点：增加了代理层，增大了成本。

尽管代理层是轻量级的转发协议，但是毕竟要实现JDBC协议的解析，并且还有通过分片的路由规则来路由请求，对每个数据库操作都增加一个网络传输，这对新性能是很有影响的，需要维护增加的代理层，也有硬件成本，最主要的是需要有大牛在，大牛专门解决代理层出现的bug，哈哈，所以嘛，成本相对高不少。

比如：当前流行的分库分表使用代理分片实现的框架有Cobar、Mycat等。

支持事务的分布式数据库
现在有很多产品，比如：OceanBase、TiDB等对外提供可伸缩的体系架构，并提供一定的分布式事务支持，将可伸缩的特点和分布式事务的实现包装到分布式数据库内部实现，对其使用者透明，使用者不需要直接控制这些特性，例如：TiDB对外提供JDBC的接口，让应用层想使用Mysql等传统数据库依赖来使用TiDB，而不需要关注其内部是如何实现伸缩、分片以及处理分布式事务的。