对数据库读写分离思考

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

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

读写分离的本质

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

读写分离的实现形式

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

协议隔离

通过协议识别，可以在应用无感知情况下，实现流量分离。

常见的实现方式:

这种方式好处就是应用无感知，缺点是无法手动选择，性能可能也有些损耗。

服务隔离

根据场景的不同，分为多个服务目录空间，挂载相关的服务。通常的实现方式，使用配置的方式将数据源和多个服务进行绑定。

这里会出现一个服务可能对多种数据源，通过服务标签进行区分。