序
可以看上一篇文章，因此我有了写篇文章介绍数据库读写分离的想法
文
什么是读写分离
读写分离基本的原理是让主数据库处理事务性增、改、删操作（INSERT、UPDATE、DELETE），而从数据库处理SELECT查询操作
数据库复制被用来把事务性操作导致的变更同步到集群中的从数据库
通常，主数据库的性能综合内存较大而只读数据库的硬盘IO较大以提高读取速度
我个人习惯使用SSD硬盘
关于这个的重要性你可以看这篇文章
为什么要读写分离
因为数据库的“写”（写10000条数据到oracle可能要3分钟）操作是比较耗时的
但是数据库的“读”（从oracle读10000条数据可能只要5秒钟）
所以读写分离，解决的是，数据库的写入，影响了查询的效率
同时，从服务器只能提供读取数据，不能写入，实现备份的同时也实现了数据库性能的优化，以及提升了服务器安全
何时要读写分离
数据库不一定要读写分离
如果程序使用数据库较多时，而更新少（例如门户网站、博客），查询多（绝对量级非相对量级，个人博客请不要考虑读写分离）的情况下会考虑使用利用数据库 主从同步 从而减少数据库压力，提高性能
当然，数据库也有其它优化方案。memcache 或是 表折分，或是搜索引擎，都是解决方法
主从复制
在实际的生产环境中，对数据库的读和写都在同一个数据库服务器中，是不能满足实际需求的
无论是在安全性、高可用性还是高并发等各个方面都是完全不能满足实际需求的
因此，通过主从复制的方式来同步数据，再通过读写分离来提升数据库的并发负载能力
有点类似于前面我们学习过的rsync，但是不同的是rsync是对磁盘文件做备份，而mysql主从复制是对数据库中的数据、语句做备份
支持
- 基于语句的复制：在服务器上执行sql语句，在从服务器上执行同样的语句，mysql默认采用基于语句的复制，执行效率高
- 基于行的复制：把改变的内容复制过去，而不是把命令在从服务器上执行一遍
- 混合类型的复制：默认采用基于语句的复制，一旦发现基于语句无法精确复制时，就会采用基于行的复制
过程
- 在每个事务更新数据完成之前，master在二进制日志记录这些改变
- 写入二进制日志完成后，master通知存储引擎提交事务
- Slave将master的binary log复制到其中继日志
- 首先slave开始一个工作线程（I/O），I/O线程在master上打开一个普通的连接，然后开始binlog dump process
- binlog dump process从master的二进制日志中读取事件，如果已经跟上master，它会睡眠并等待master产生新的事件，I/O线程将这些事件写入中继日志
- Sql slave thread（sql从线程）处理该过程的最后一步，sql线程从中继日志读取事件，并重放其中的事件而更新slave数据，使其与master中的数据一致，只要该线程与I/O线程保持一致，中继日志通常会位于os缓存中，所以中继日志的开销很小
尾
微服务、低成本服务请不要考虑读写分离
写多读少的服务请不要考虑读写分离
没有高性能的只读数据库和主数据库请不要考虑读写分离
PV低的刚起步的服务请不要考虑读写分离
PS：本文部分知识点来自网络
