什么是MVCC
即多版本并发控制，读取数据时通过一种类似快照的方式将数据保存下来，这样读写与写锁就不会
冲突，不同的事务session只会看到自己特定版本的数据，版本链
MVCC只会在READ COMMITTED(已提交读)和REPEATABLE READ(可重复读)两个隔离级别下工作，已提交读和可重复读的区别在于他们生成ReadView的策略不同
开始事务创建readview，readVIew维护维护当前活动的事务id，即未提交的事务id，排序生成一个数组访问数据，获取数据中的事务id(获取事务id最大的记录，对比readView)；
如果在readview的左边(比raedview都小)，可以访问(在作弊意味着该事务已经提交)
如果在readview的右边(比readview都大)或者就在readview中，不可以访问，获取roll_pointer,取上一版本重新对比（在右边意味着，该事务在readview生成之后出现，在readview中意味着该事务还未提交）
已提交读隔离级别下的事务在每次查询的开始都会生成一个独立的ReadView，而可重复读隔离级别则在第一次读的时候生成ReadView，之后的读都复用之前的ReadView。
这就是MySQL的MVCC，通过版本链，实现多版本，可并发读-写，写-读，通过ReadView生成策略的不同实现不同的隔离级别。
MySQL主从同步原理
MySQL主从同步的作用主要有以下几点：
1、故障切换。
2、提供一定程度上的备份服务。
3、实现MySQL数据库的读写分离。
MySQL的主从复制主要有三个线程：master(binlog dump thread)，slave(I/O) thread,SQL thread）,Master一条线程和和Slave 中两条线程
主节点binlog ，主从赋值的基础是主库记录数据库的所有变更记录到binlog，binlog 是数据库服务器启动的那一刻起，保存所有修改数据库结构或内容的一个文件。
主节点log dump线程，当binlog由变动时，log dump线程读取其内容并发送给节点
从节点i/o线程接受binlog内容，并将其写入relay log 文件中。
从节点的sql线程读取relay log文件内容对数据更新进行重放，最终导致主从数据库的一致
注意：主从节点使用binlog 文件 +position 偏移量来定位同步的位置，从节点会保存其已接受的偏移量，如果从节点发生宕机，则会从position的位置发起同步
由于mysgl默认的复制方式是异步的，主库把日志发送给从库后不关心从库是否已经处理，这样会
产生一个问题，假设主库挂了，从库处理失败了，这时候从库升为主库后，日志就丢失了。由此产生两个概念。
全同步复制
主库写入binlog后强制同步日志到从库，所有的从库都执行完成后才返回给客户端，但是很显然这
个方式的话，性能会受到严重影响。
半同步复制
和全同步不同的是，半同步复制的逻辑是这样，从库写入日志成功后返回ACK确认给主库，主库
收到至少一个从库的确认就认为写操作完成。
