流量突增方案

主从读写分离来应付流量突增，此方案有两个主要技术关键点

1. 数据拷贝
2. 读写分离后的开发方式的变化

数据拷贝的方案

数据拷贝主要使用MySQL支持的主从复制方式，其原理是使用binlog日志，由一个名叫log dump线程关联上从库的IO线程传输binlog日志，从库接收到日志之后存入到名叫relay log的文件中，最后再由从库的SQL线程去执行relay log文件。此主从复制方式主要是为了避免从库写入的耗时过大会导致主库和从库的延迟变长。

主从复制如何解决主从延迟

除了部署的复杂度以外，主从复制还会带来主从延迟的问题，同样需要开发人员避坑。

主从延迟的案例

以电商系统下订单为例，当用户确认订单时，会执行同步的写主库操作，并且会写入发送短信等任务到消息队列中，消费消息时一般在从库进行读取消息对应的数据，此时如果主从复制的延迟大于消息消费速度，将可能出现消息消费时在从库读取不到对应的数据。

解决方案

1. 数据冗余。将消息消费时需要读取到的内容冗余到消息中，避免在从库读取。
2. 使用缓存。在用户确认订单操作，同步写主库时，也同步将数据写入到缓存中，在消息消费时，先读取缓存中的数据，这样也可以保证一致性。但要注意缓存的不一致，例如：线程A写入数据库1，线程B写入数据库2，线程B写入缓存2，线程A写入缓存1，此时更新数据的并发情况下， 缓存会存在与数据库内容不一致，因此使用缓存适合新增数据的场景。
3. 直接查询主库。此方案不建议使用，让查询请求打到主库上，会影响主库的性能。

读写分离后开发方式的变更

1. 客户端代理。例如：sharding-jdbc
2. 中间件服务端代理（独立部署）。例如：mycat