往往读多写少，这时候数据库的读会首先成为数据库的瓶颈。如果我们已经优化了SQL，但是读依旧还是瓶颈时，这时就可以选择“读写分离”架构了。读写分离首先需要将数据库分为主从库，一个主库用于写数据，多个从库完成读数据的操作，主从库之间通过主从复制机制进行数据的同步，如图所示：
在应用中可以在从库追加多个索引来优化查询，主库这些索引可以不加，用于提升写效率。读写分离架构也能够消除读写锁冲突从而提升数据库的读写性能，同时也存在两个问题：主从同步延迟和读写分配机制问题。
一、主从同步延迟
使用读写分离架构时，数据库主从同步具有延迟性，数据一致性会有影响，对于一些实时性要求比较高的操作，可以采用以下解决方案。
1）写后立刻读：在写入数据库后，某个时间段内读操作就去主库，之后读操作访问从库。
2）二次查询：先去从库读取数据，找不到时就去主库进行数据读取。该操作容易将读压力返还给主库，为了避免恶意攻击，建议对数据库访问API操作进行封装，有利于安全和低耦合。
3）根据业务特殊处理：根据业务特点和重要程度进行调整，比如重要的，实时性要求高的业务数据读写可以放在主库。对于次要的业务，实时性要求不高可以进行读写分离，查询时去从库查询。
二、读写分配机制
读写路由分配机制是实现读写分离架构落地最关键的一个环节，就是控制何时去主库写，何时去从库读。目前较为常见的实现方案分为以下两种：
基于编程和配置实现（应用端）
程序员在代码中封装数据库的操作，代码中可以根据操作类型进行路由分配，增删改时操作主库，查询时操作从库。这类方法也是目前生产环境下应用最广泛的。优点是实现简单，因为程序在代码中实现，不需要增加额外的硬件开支，缺点是需要开发人员来实现，运维人员无从下手，如果其中一个数据库宕机了，就需要修改配置重启项目。(Spring Boot数据访问之多数据源配置及数据源动态切换 - 池塘里洗澡的鸭子 是一种实现，具体什么样的业务场景使用哪个数据库根据具体业务逻辑判定)
基于服务器端代理实现（服务器端）
中间件代理一般介于应用服务器和数据库服务器之间，从图中可以看到，应用服务器并不直接进入到master数据库或者slave数据库，而是进入MySQL proxy代理服务器。代理服务器接收到应用服务器的请求后，先进行判断然后转发到后端master和slave数据库。
市场上目前有很多性能不错的数据库中间件，常用的有MySQL Proxy、MyCat以及Shardingsphere等等，后续将介绍一些数据库中间件的使用。
