1、读写分离 是什么
读写分离，基本的原理是让主数据库处理事务性增、改、删操作（INSERT、UPDATE、DELETE），而从数据库处理SELECT查询操作。数据库复制被用来把事务性操作导致的变更同步到集群中的从数据库。
2、为什么要读写分离呢？
- 增加冗余
- 增加机器的处理能力
- 对于读操作作为主的应用，使用读写分离是最好的场景，因为可以确保写的服务器压力更小，而读又可以接受点时间上的延迟。
因为数据库的“写”（写10000条数据到oracle可能要3分钟）操作是比较耗时的。
但是数据库的“读”（从oracle读10000条数据可能只要5秒钟）。
所以读写分离，解决的是，数据库的写入，影响了查询的效率。
3、 什么时候要读写分离？
数据库不一定要读写分离，如果程序使用数据库较多时，而更新少，查询多的情况下会考虑使用，利用数据库 主从同步 。可以减少数据库压力，提高性能。当然，数据库也有其它优化方案。memcache 或是 表折分，或是搜索引擎。都是解决方法。
4、读写分离提高性能之原因
1.物理服务器增加，负荷增加
2.主从只负责各自的写和读，极大程度的缓解X锁和S锁争用
3.从库可配置myisam引擎，提升查询性能以及节约系统开销
4.从库同步主库的数据和主库直接写还是有区别的，通过主库发送来的binlog恢复数据，但是，最重要区别在于主库向从库发送binlog是异步的，从库恢复数据也是异步的。
5.读写分离适用与读远大于写的场景，如果只有一台服务器，当select很多时，update和delete会被这些select访问中的数据堵塞，等待select结束，并发性能不高。 对于写和读比例相近的应用，应该部署双主相互复制
6.可以在从库启动是增加一些参数来提高其读的性能，例如--skip-innodb、--skip-bdb、--low-priority-updates以及--delay-key-write=ALL。当然这些设置也是需要根据具体业务需求来定得，不一定能用上
7.分摊读取。假如我们有1主3从，不考虑上述1中提到的从库单方面设置，假设现在1 分钟内有10条写入，150条读取。那么，1主3从相当于共计40条写入，而读取总数没变，因此平均下来每台服务器承担了10条写入和50条读取（主库不 承担读取操作）。因此，虽然写入没变，但是读取大大分摊了，提高了系统性能。另外，当读取被分摊后，又间接提高了写入的性能。所以，总体性能提高了，说白 了就是拿机器和带宽换性能。MySQL官方文档中有相关演算公式：官方文档 见6.9FAQ之“MySQL复制能够何时和多大程度提高系统性能”
8.MySQL复制另外一大功能是增加冗余，提高可用性，当一台数据库服务器宕机后能通过调整另外一台从库来以最快的速度恢复服务，因此不能光看性能，也就是说1主1从也是可以的。
这里提供了一个mysql主从复制和读写分离模型：(本次是一主二从模型)
Master：172.25.254.7
slave1：172.25.254.8
slave2：172.25.254.9
mysql_proxy：172.25.254.10
- Java web app：是客户端请求，会对数据库发起读写操作请求，具体是发送SQL指令
- Mysql Proxy：对读写操作请求的SQL指令进行路由，使得读写分离
- direct：一个负载分发引擎，对Mysql Proxy分发得读操作，按照一定得算法进行分发至后端得从服务器
- master：主服务器，主要接受用户的写操作，并且负责将二进制日志同步给从服务器
- slave-n：从服务器，主要负责用户的读操作(分担主服务器的读写压力)，并且负责重放master的写操作，还能实现容灾能力，保证高可用(如果主服务器挂掉，slvae顶上去)
mysql主从复制
4.1、 mysq支持的复制类型
1） 基于语句的复制。在服务器上执行sql语句，在从服务器上执行同样的语句，mysql默认采用基于语句的复制，执行效率高。
2） 基于行的复制。把改变的内容复制过去，而不是把命令在从服务器上执行一遍。
3） 混合类型的复制。默认采用基于语句的复制，一旦发现基于语句无法精确复制时，就会采用基于行的复制。
4.2、 复制的工作过程
1） 在每个事务更新数据完成之前，master在二进制日志记录这些改变。写入二进制日志 binary log完成后，master通知存储引擎提交事务。
2） Slave将master的binary log复制到其中继日志。首先slave开始一个工作线程（I/O），I/O线程在master上打开一个普通的连接，然后开始binlog dump process。binlog dump process从master的二进制日志中读取事件，如果已经跟上master，它会睡眠并等待master产生新的事件，I/O线程将这些事件写入中继日志。
3） Sql slave thread（sql从线程）处理该过程的最后一步，sql线程从中继日志读取事件，并重放其中的事件而更新slave数据，使其与master中的数据一致，只要该线程与I/O线程保持一致，中继日志通常会位于os缓存中，所以中继日志的开销很小。
mysql主从复制的思路：
配置主服务器，即Msater，使之具备一下能力
-
记录二进制日志
-
为从服务提供一个用户(设置密码)，提高二进制日志同步得安全性
配置从服务器，即slave，使之具备一下能力
-
记录中继日志
-
连接到mysql可以启动SLAVE功能，并且设置Master信息，通过配置信息，开启IO_THREAD和SQL_THREAD线程
mysql主动复制的意义：
为mysql服务提供高可用能力
通过远程主从复制，提供容灾能力
如果主服务器挂掉，从服务器可以快速顶替，并成为新的主服务器前较为常见的Mysql读写分离分为以下两种
1）基于程序代码内部实现
在代码中根据select 、insert进行路由分类，这类方法也是目前生产环境下应用最广泛的。
优点是性能较好，因为程序在代码中实现，不需要增加额外的硬件开支，缺点是需要开发人员来实现，运维人员无从下手。
实现 ：Spring提供的路由数据源 +AOP
2） 基于中间代理层实现
代理一般介于应用服务器和数据库服务器之间，代理数据库服务器接收到应用服务器的请求后根据判断后转发到，
后端数据库，有以下代表性的程序。
MySQL数据库主从同步延迟解决方案。
架构方面
- 业务的持久化层实现采用分库架构，MySQL服务可平行拓展，分散压力。
- 单个库读写分离，一主多从，主写从读，分散压力，这样从库压力比主库高，保护主库。
- 服务的基础架构在业务和MySQL之间加入缓存层，memcache，redis,cache,降低MySQL的读压力。
- 不同业务的MySQL物理上放不同机器，分散压力。
- 使用比主库更好的设备作为slave。
总结，mysql压力小，延迟自然会变小。
硬件方面
1.采用好服务器，比如4u比2u性能明显好，2u比1u性能明显好。 2.存储用ssd或者盘阵或者san，提升随机写的性能。 3.主从间保证处在同一个交换机下面，并且是万兆环境。 总结，硬件强劲，延迟自然会变小。一句话，缩小延迟的解决方案就是花钱和花时间。