一.MySQL主从原理
二.怎样利用缓存保证数据的一致性
前言：今天单就MySQL主从及原理和遇到问题分析下，当然要支撑高并发仅仅靠MySQL是不可行的，上家公司用的是 MySQL+Nginx+redis+rabitMQ+elasticsearch+mongoDB等来支撑高并发；根据业务场景组合拳吧，下面进入正题.....
如果想从MySQL方便做到支持一定量的并发，那么必然会想到：读写分离
MySQL 做读写分离的前提，是把 MySQL 集群拆分成“主 + 从”结构的数据集群，这样才能实现程序上的读写分离，并且 MySQL 集群的主库、从库的数据是通过主从复制实现同步的。
在面试过程中，我们一般会被问到：
@1.你们公司MySQL有几台从库？每台从库作用是什么？(考察你对你用的系统熟悉程度)
@2.主从复制过程原理是什么？（考察你的基础知识）
总的来讲，MySQL 的主从复制依赖于 binlog ，也就是记录 MySQL 上的所有变化并以二进制形式保存在磁盘上。复制的过程就是将 binlog 中的数据从主库传输到从库上。这个过程一般是异步的，也就是主库上执行事务操作的线程不会等待复制 binlog 的线程同步完成。
上家公司用的一般是1主1从1备份，个别的实例和库会有多个从库；
主从复制大概分三个过程:
a:MySQL 主库在收到客户端提交事务的请求之后，会先写入 binlog，再提交事务，更新存储引擎中的数据，事务提交完成后，返回给客户端“操作成功”的响应。
b:从库会创建一个专门的 I/O 线程，连接主库的 log dump 线程，来接收主库的 binlog 日志，再把 binlog 信息写入 relay log 的中继日志里，再返回给主库“复制成功”的响应。
c:从库会创建一个用于回放 binlog 的线程，去读 relay log 中继日志，然后回放 binlog 更新存储引擎中的数据，最终实现主从的数据一致性。
下面找了张图：
在完成主从复制之后，你就可以在写数据时只写主库，在读数据时只读从库，这样即使写请求会锁表或者锁记录，也不会影响读请求的执行。
那么写入binlog日志记录数据方式有哪几种勒？
- statement: 会将对数据库操作的sql语句写道binlog中
- row: 会将每一条数据的变化写道binlog中。
- mixed: statement与row的混合。Mysql决定何时写statement格式的binlog, 何时写row格式的binlog。（MySQL4.0版本后）
既然可以有多个从库，那大促流量大时，是不是只要多增加几台从库，就可以抗住大促的并发读请求了？why?
当然不是；因为：
从库数量增加，从库连接上来的 I/O 线程也比较多，主库也要创建同样多的 log dump 线程来处理复制的请求，对主库资源消耗比较高，同时还受限于主库的网络带宽。所以在实际使用中，一个主库一般跟 2～3 个从库（1 套数据库，1 主 2 从 1 备主），这就是一主多从的 MySQL 集群结构。
MySQL 主从复制还有哪些模型？
主要有三种；
@1：同步复制：事务线程要等待所有从库的复制成功响应。
@2：异步复制：事务线程完全不等待从库的复制成功响应。
@3：半同步复制：MySQL 5.7 版本之后增加的一种复制方式，介于两者之间，事务线程不用等待所有的从库复制成功响应，只要一部分复制成功响应回来就行，比如一主二从的集群，只要数据成功复制到任意一个从库上，主库的事务线程就可以返回给客户端。
主从必会遇到主从延迟问题，怎么解决？
使用缓存解决；（通过缓存解决 MySQL 主从复制延迟时，会出现数据库与缓存数据不一致的情况，所以这块要处理好）
那么怎么保证redis的数据一致性，且听寡人缓缓道来。。
前言：缓存机制是互联网搬砖人必须要掌握的基础知识之一，在使用Redis中间件时数据的幂等性问题是每个搬砖人应该掌握的。本篇文章围绕一致性问题逐步引入讲解下Redis的一致性问题。
首先思考下为啥要使用缓存？
存储如mysql通常支持完整的ACID特性，因为可靠性，持久性等因素，性能普遍不高，高并发的查询会给mysql带来压力，造成数据库系统的不稳定。同时也容易产生延迟。根据局部性原理，80%请求会落到20%的热点数据上，在读多写少场景，增加一层缓存非常有助提升系统吞吐量和健壮性。
通常的开发模式中，都会使用mysql作为存储，而redis作为缓存，加速和保护mysql。但是，当mysql数据更新之后，redis怎么保持同步呢。强一致性同步成本太高，如果追求强一致，那么没必要用缓存了，直接用mysql即可。通常考虑的，都是最终一致性。
本篇列举三种方案解决一致性问题分析。在面试过程中，面试官可能会一一列举出来锤炼我们。所以我们必须都要去了解，然后拿出我胡汉三怕过谁的气势征服他们。
以下是三种方案：
1. 先更新数据库，再更新缓存
2. 先删除缓存，再更新数据库
3. 先更新数据库，再删除缓存
方案一：先更新数据库，再更新缓存
1、A更新数据库数据为a
2、B更新数据库数据为b
3、B更新缓存数据为b
4、A更新缓存数据为a
问题：这就出现请求A更新缓存应该比请求B更新缓存早才对，但是因为网络等原因，B却比A更早更新了缓存。会导致了脏数据，本方案可靠性不高。
方案二：先删除缓存，再更新数据库
1、A删除缓存
2、B查询缓存未查到
3、B查询数据库为b，并更新缓存
4、A修改数据库为a
问题：最终，数据库数据为a，而缓存数据为b
有个延时策略可以解决这个方法，就是在更新数据库之后，定时任务(例如1s后)执行删除缓存，把这期间保存的缓存数据删除掉，这个1s时间需要自己估项目的读数据业务逻辑的耗时。
针对删除失败，需要考虑到重试机制，详细见方案三。
方案三：先更新数据库，再删除缓存
1、缓存失效
2、A未查询到缓存，查询数据库
3、B更新数据库
4、B删除缓存
5、A更新缓存
问题：如果删除缓存出现异常呢？
我们可以基于通过使用 Canal 组件来获读取最新的 Binlog 日志数据添加到队列中来实现一套方案。
找了一张不错的图如下：
