读写分离：应用缓存的原则之一是保证缓存命中率足够高，在大量不同请求下的读多写少，“读写分离”是提升系统并发能力的重要手段。在完成主从复制之后，可以在写数据时只写主库，在读数据时只读从库
-
主从复制原理：从库数量增加，从库连接上来的 I/O 线程也多，主库要创建同样多的 log dump 线程来处理复制的请求，对主库资源消耗比较高，一般一主两从一备主
-
写入binlog：主库写 binlog （二进制）日志，提交事务，并更新本地存储数据。
- MySQL 主库在收到客户端提交事务的请求之后，会先写入 binlog，再提交事务，更新存储引擎中的数据，事务提交完成后，返回给客户端“操作成功”的响应。
-
同步 Binlog：异步把 binlog 复制到所有从库上，每个从库把 binlog 写到暂存日志中。
- 从库会创建一个专门的 I/O 线程，连接主库的 log dump 线程，来接收主库的 binlog 日志，再把 binlog 信息写入 relay log 的中继日志里，再返回给主库“复制成功”的响应。
-
回放 Binlog：回放 binlog，并更新存储数据。
- 从库会创建一个用于回放 binlog 的线程，去读 relay log 中继日志，然后回放 binlog 更新存储引擎中的数据，最终实现主从的数据一致性。
-
-
binlog格式：Statement、Row 及 Mixed
- Statement：binlog 会记录每一条修改数据的 SQL 操作，从库拿到后在本地进行回放
- Row（默认）：行为维度，记录每一行数据修改的细节，不记录执行 SQL 语句的上下文相关的信息，仅记录行数据的修改。类似redolog
- Mixed：Statement 与 Row 的结合，在这种方式下，不同的 SQL 操作会区别对待,一般的数据操作使用 row 格式保存，有些表结构的变更语句，使用 statement 来记录
-
其他主从复制模型：
- 同步复制：事务线程要等待所有从库的复制成功响应。
- 异步复制：事务线程完全不等待从库的复制成功响应。数据一致性要求不高，当发生故障时，能容忍数据的丢失，甚至大量的丢失时用异步复制
- 半同步复制5.5引入：事务线程不用等待所有的从库复制成功响应，存储引擎提交事务后只要一部分复制成功响应回来就行
- 增强（无损）半同步复制5.7.2引入：主库在存储引擎提交事务前，必须先收到从库数据同步完成的确认信息后，才能提交事务，以此来解决幻读问题。Master 宕机了，由于最后一个事务还没有提交，所以本身这个数据对外也不可见，不存在丢失的问题。
- 多源复制：N 个 Master 对应 1 个 Slave
- 延迟复制：允许Slave 延迟回放接收到的二进制日志，为了避免主服务器上的误操作，马上又同步到了从服务器，导致数据完全丢失。金融行业来说，延迟复制必须考虑的架构部分
-
解决主从延迟：主从延迟影响读取从库的实时性
- 数据冗余：直接向读取方发送目标数据，不必发送id在读从库。数据太大会占带宽
- 缓存解决：数据优先存缓存，读从库方优先读缓存
- 直接查询主库：即使主从分离了少部分情况也可读主库，但慎读，数据太大会主库写请求锁行
- 关键业务不进行读写分离：对一致性不敏感的业务不读写分离
- 大事务拆分成小事务：大事务除了会导致提交速度变慢，还会导致主从复制延迟。
- 主从复制延迟监控不能依赖 Seconds_Behind_Master 的值，最好的方法是额外配置一张心跳表；（太深入可不记）
- 通过配置 MTS 并行复制机制，可以进一步缩短主从数据延迟的问题，推荐使用 MySQL 5.7版本，并配置成基于 WRITESET 的复制；（太深入可不记）
-
实现主库和从库的数据库访问：1、配置数据源并在代码中判断发给指定数据源。2、使用中间件代理如mycat
