昨天去一个同事公司做技术交流，他们CTO聊到mysql的主从同步读写分离。
前面做主从同步的时候没有去深入了解读写分离，只管配置上了主从服务就完事，操作过程能满足业务需要就不管了。
今天特意来查了一下mysql的主从同步与读写分离
还是引用别人的图片来看一下：
从这张图上看来就是主提供写的服务，从提供查询的服务。
原理原理，别人要听原理。好来一段网站的原理：
Mysql的 Replication 是一个异步的复制过程，从一个 Mysql instace(我们称之为 Master)复制到另一个 Mysqlinstance(我们称之 Slave)。在 Master 与 Slave 之间的实现整个复制过程主要由三个线程来完成，其中两个线程(Sql线程和IO线程)在 Slave 端，另外一个线程(IO线程)在 Master 端。
MySQL 复制的基本过程如下：
1. Slave 上面的IO线程连接上 Master，并请求从指定日志文件的指定位置(或者从最开始的日志)之后的日志内容;
2. Master 接收到来自 Slave 的 IO 线程的请求后，通过负责复制的 IO 线程根据请求信息读取指定日志指定位置之后的日志信息，返回给 Slave 端的 IO 线程。返回信息中除了日志所包含的信息之外，还包括本次返回的信息在 Master 端的 BinaryLog 文件的名称以及在 Binary Log 中的位置;
3. Slave 的 IO 线程接收到信息后，将接收到的日志内容依次写入到 Slave 端的Relay Log文件(mysql-relay-bin.xxxxxx)的最末端，并将读取到的Master端的bin-log的文件名和位置记录到master- info文件中，以便在下一次读取的时候能够清楚的高速Master“我需要从某个bin-log的哪个位置开始往后的日志内容，请发给我”
4. Slave 的 SQL 线程检测到 Relay Log 中新增加了内容后，会马上解析该 Log 文件中的内容成为在 Master 端真实执行时候的那些可执行的 Query 语句，并在自身执行这些 Query。这样，实际上就是在 Master 端和 Slave 端执行了同样的 Query，所以两端的数据是完全一样的。
还是看不懂。
主库用二进制日志文件log-bin记录数据的变化，主从通信，slave发送了上次请求的位置，主就根据从的需求从相应位置后读取日志记录返回给从slave，然后slave自己操作数据。
看来看去还是只看到数据同步的原理，并没有看到读写分离的原理啊。
“假设slave可以主动的进行写操作，slave又无法通知master，这样就导致了master和slave数据不一致了。因此slave不应该进行写操作，至少是slave上涉及到复制的数据库不可以写。实际上，这里已经揭示了读写分离的概念。”
参考资料：
http://www.cnblogs.com/alvin_xp/p/4162249.html 相应配置
http://www.cnblogs.com/zhankx/p/5618522.html 问题解答