1.MySQL主从复制
在我们进行系统架构时，MySQL的master-slave模式是我们经常采用的一种模式。
为什么要用这种模式呢？
a.系统扩展性
扩展性是搭建系统要考虑的重要指标之一，在系统初期，我们采用单库模式，快速开发上线，db承载着系统所有的读写操作，随着系统负载的增加，
单个数据库很容易成为瓶颈。主从复制，让写入和更新操作在主库，从库分担读操作；
b.负载均衡
对于读远大于写的系统，这种架构优化效果明显，通过nginx或lvs等一些软件，我们可以达到负载均衡的效果。
c.更好的数据安全性
在单库中，如果db出了问题，会造成整个系统瘫痪，功能无法使用，而在主从模式中，如果主库宕机，从库还是可以提供读服务，而且可以切换成
主库进行读写操作，将影响降到最低。
那么有了主从架构，是不是db不需要备份了呢，当然不是，备份和主从是为了解决不同的问题，如果你误操作了数据表，主从最终会一致，如果没有备份，数据就无法恢复了，备份还是必须的，主从是让你的系统更健壮。
d.系统升级
作为程序猿，系统升级是家常便饭了，你的系统是怎么升级的呢；
停服-更新-开服，是这样吗，今天系统升级，估计又要通宵了，是不是让人很崩溃呢！
滚动升级，升级从库，从库提供服务，然后升级主库，主库再作为从库！
其实不仅仅是数据库，我们的web服务器、缓存服务、队列服务的集群升级都可以采用这种方法。
一般主从架构是这个样子的
master-slave架构2.主从复制过程：
MySQL的主从复制是通过binlog进行的，步骤如下：
a.主库写binlog
b.从库向master询问是否有写入
c.master上的binlog转储线程向IO线程发送binlog
d.slave把binlog写入自己的中继log中
e.slave对中继log事件进行回放。
大致流程如下：
m-s同步流程3.需要注意的问题
引入主从架构，是不是就高枕无忧了呢，当然不是，凡事都有两面性，没有完美的方案。
我们看一下对系统的影响：
a.性能上：主从复制对系统的影响主要在于binlog产生的IO开销，从库越多，开销越大；
b.功能延时：主从之间的sql线程和IO线程是异步的，所以主从之间会有延时。而且延时时间是不可控的，如果是多级复制，延时就更多。
当我们引入一个方案时，如何衡量好坏：
首先看它解决了什么问题，会带来哪些问题，很多方案都是一个权衡的过程。
对于性能的影响，开启binlog大概有1%的影响，对于高可用系统，这点性能损耗是可以接受的；
对于延时问题，数据敏感场景，我们一般采用读主库，或写cache；数据不敏感的场景，如后台功能、点赞、阅读量统计等这些，用户并不在乎。
最后：
对于一个数据库来说，最重要的是数据完整性，集群数据一致性，如果意外宕机，在单库场景，MySQL通过redo日志保证事务数据完整性，而主从模式下，主从通过binlog保证主从的一致性，那么redo日志和binlog会不会不一致，MySQL是如何保证两个日志的一致性呢，下篇文章我们再详细说。
redo流程图