前言：高并发这个阶段，肯定是需要做MySQL读写分离的。实际上大部分的互联网网站或者App，其实都是读多写少。所以针对这个情况，就是写一个主库，但是主库挂多个从库，然后从多个从库来读，那不就可以支撑更高的读并发压力了吗？
一、 MySQL 读写分离
1.1、如何实现 MySQL 的读写分离？
其实很简单，就是基于主从复制架构。简单来说，就搞一个主库，挂多个从库，然后我们就单单只是写主库，然后主库会自动把数据给同步到从去，多个从库用于读。
读写分离就是对于
本文来源gao!%daima.com搞$代*!码9网(
一条SQL该选择哪一个数据库去执行，至于谁来做选择数据库这件事，有两个，要么使用中间件帮我们做，要么程序自己做。一般来说，读写分离有两种实现方式。第一种是依靠中间件MyCat或Sharding-JDBC，也就是说应用程序连接到中间件，中间件帮我们做SQL分离，去选择指定的数据源；第二种是应用程序自己去做分离。这里我用程序自己来做，主要是利用Spring提供的路由数据源，以及AOP。
1.2、MySQL 主从复制原理？
主库将变更写入 binlog 日志，然后从库连接到主库之后，从库有一个 IO 线程，将主库的 binlog 日志拷贝到自己本地，写入一个 relay 中继日志中。接着从库中有一个 SQL 线程会从中继日志读取 binlog，然后执行 binlog 日志中的内容，也就是在自己本地再次执行一遍 SQL，这样就可以保证自己跟主库的数据是一样的。
mysql-master-slave
这里有一个非常重要的一点，就是从库同步主库数据的过程是串行化的，也就是说主库上并行的操作，在从库上会串行执行。所以这就是一个非常重要的点了，由于从库从主库拷贝日志以及串行执行 SQL 的特点，在高并发场景下，从库的数据一定会比主库慢一些，是有延时的。所以经常出现，刚写入主库的数据可能是读不到的，要过几十毫秒，甚至几百毫秒才能读取到。
而且这里还有另外一个问题，就是如果主库突然宕机，然后恰好数据还没同步到从库，那么有些数据可能在从库上是没有的，有些数据可能就丢失了。
所以 MySQL 实际上在这一块有两个机制，一个是半同步复制，用来解决主库数据丢失问题；一个是并行复制，用来解决主从同步延时问题。
这个所谓半同步复制，也叫 semi-sync 复制，指的就是主库写入 binlog 日志之后，就会将强制此时立即将数据同步到从库，从库将日志写入自己本地的 relay log 之后，接着会返回一个 ack 给主库，主库接收到至少一个从库的 ack 之后才会认为写操作完成了。
所谓并行复制，指的是从库开启多个线程，并行读取 relay log 中不同库的日志，然后并行重放不同库的日志，这是库级别的并行。
1.3、MySQL 主从同步延时问题（精华）
线上会发现，每天总有那么一些数据，我们期望更新一些重要的数据状态，但在高峰期时候却没更新。用户跟客服反馈，而客服就会反馈给我们。
转载请注明原文链接：SpringBoot+MyBatis+AOP实现读写分离的示例代码
