读写分离
读写分离，字面上理解是讲读和写分开。拥有多台数据库，主节点负责写入和少量读取，多个从节点负责分担查询。
缓存，在绝大多数项目的地位举足轻重。缓存，它具有在快速响应大量请求，保护下层数据库不被过量请求压垮等优点。但是，缓存能完全代替数据库吗？当然是不能。
那么，接下来，看这样一个例子
大多数的应用最开始都是单体结构，一个程序包，一个数据库，好一点会有一个缓存层。现在有每秒8000个请求，其中1000个是写入请求，7000个是读取请求。4000个读取请求能在缓存层得到结果并正确响应。那么，这个时候，将会有3000个读取请求进入数据库，1000个写入请求进入数据库，共4000个请求，4000个请求进入数据库后，如果数据库性能低一点，会直接将数据库冲垮。那有没有好的解决方法呢？有，MySql主从复制。主库负责写入，从库负责分担查询。
MySql主从复制
这张图是MySql经典架构图。在这里引用，向大家说明基本原理。使用MySql主从复制最少需要两台数据库做主从架构，1台主数据库，用来进行写入操作。1台从数据库，用来分担查操作。
主库把SQL请求记录到自己的binlog日志中，从库去请求主库的binlog日志，并将binlog日志写到中继日志中，然后从库重做中继日志的SQL语句，并执行到从库。
这个同步过程可以同步进行，也可以异步进行。同步是指，主库确认从库收到消息才会提交。异步则是写入和推送消息变更分开。大多数情况下，我们的业务都是需要异步同步。
MySql主从复制延时
由此发现，异步同步数据的方式，同步时间不太好掌握。这样会带来一些问题。比如：
- 连续多次对同一数据进行变更。第一次变更后的数据还未同步到从库，第二次变更紧接着就进行。这样会导致，第二次变更的内容有可能是错误的。
- 数据变更后，页面进行列表展示，有可能展示到变更前的数据。
- 内部系统调用，内部实时统计有可能读取到旧数据。
如何解决这一问题呢？
- 程序上进行规避（例如：使用缓存层对新添加或者新修改的内容进行缓存一定时间）
- 数据库同步时间以及同步效率进行摸底，并配置相应的参数（MySql同步模式配置、参数调整）
一般情况下，MySql主从同步时间是毫秒内延时，压力上来后，才会明显感觉到延时问题存在。
MySql主从复制优缺点
优点：
- 对开发者透明
- 打破系统读性能瓶颈
- 数据库进行备份时，可是选择从库进行备份，降低对主库影响
- 使持久层变成高可用、高性能架构
缺点：
- 主从同步延时
- 需要系统对同步延时造成的数据不一致进行补偿
云顶云（yundingyun.com）是国内首批专注于云计算与大数据服务的提供商，致力于“让云计算更简单”。做为阿里云五星授权服务中心，云顶云致力于为企业和政府提供方案咨询、架构设计、部署实施、系统定制、运维托管、技术培训等全方位“4S”级公有云、私有云定制化服务。
