对存储读写分离方式的思考

在项目中，我们一般连接的都是主库，当读比较多时，就会对主库的CPU、内存造成压力，而最常见的解决方案无非就是

扩容及读写分离。那么我们就从"形而上"来看看读写分离。

读写分离的本质

读写分离，更确切地应该称之为流量分离，使数据库请求的流量均衡地打到主从服务器上，实现资源的充分利用。本质上基于多资源的连接能力，分离流量。因为从库只能读，所以也经常会被成为读写分离。但在真实的场景中，不一定就是完全的读写分离。

隔离形式

读写分离的实现形式

目前还没有进行相关的分类，或者我没有找到相关的分类。所以下面是我的一个总结。

基于网关代理

实现方式:

在数据库的集群前面，加上一个网关代理，这样就可以实现路由、流量控制和监控等功能。

优点是:

1. 应用层无感知
2. 路由规则是集中式的，不会有分布式的问题

缺点是:
3. 增加了一层网络IO，造成性能下降和不稳定
4. 集中式的都有单点问题，并且网关通常是多个集群公用，单点问题更加严重
5. 比较难排查问题，网关通常达不到完全透明

基于本地路由规则

实现方式:
主要是解决网关代理的缺点，将路由规则存储到本地。路由规则可以是静态的(编译器确定)，也可以由路由中心动态和数据库请求类别进行路由(运行期确定)。

优点:

1. 效率比较高，路由规则在本地执行
2. 自由水平扩展，不再受网关单点的限制

缺点:
3. 静态的路由规则难以应对调整需求，动态的路由规则存在分布式一致性的问题
4. 动态下发的路由规则通常需要SDK，有可能需要SDK频繁升级
5. 根据数据库请求的类别划分的读写请求，路由能力固化，在扩展能力上依赖于MySQL集群的架构

基于数据源的分离

通过对集群的不同节点划分成不同的数据源，形成类似微服务的分组，然后应用主动配置对应的数据源，实现应用分组或应用服务和数据源的映射关系，映射关系通常是静态的。

优点是:

1. 静态的映射关系，简单而且效率高

缺点是:

1. 通常是静态的配置，在紧急情况下需要人工干预