首先我们先来看下数据库的高可用一般都是怎么实现的。我们还是借用图来说明。真想手绘。
图片
如上图所示，两个相互同步的主库使用相同的虚拟IP，当主库挂掉的时候，虚拟IP自动漂移到另外一台主库，整个过程用户是无感知的。使用双主同步+keepalived+虚ip的方式进行。
如果遇到数据暴增，我们怎么办？
我们可以通过水平切分。
图片
上图所示，用户库user分布在两台服务器上，ip0和ip1。通过用户取模得方式，模2余0到ip0的机器上，反之到ip1的机器上，同时ip0和ip1并行做了双主同步，这样做到了水平切分和高可用。
新的问题来了，分成n库以后，随着数据量的不断增加，要增加到2*n库的时候，数据如何扩容，数据如何平滑迁移，如何对外提供服务，保证数据的可用性？(一连串的灵魂拷问)
1.停服升级（暂时跳过）2.假设上面每个库ip0和ip1每个库都有1亿数据，如何平滑扩容，增加实例数，降低单库数据量呢？
第一步：
图片
这样能保证原来的数据不变，还可以路由到原来的机器上。
第二步:
图片
这里需要服务层重新reload，高级一点可以通过配置中心向服务层发信息，重新读取配置文件，重新初始化连接数据库。完成之后，数据库实例从2变成4个，过程在秒级完成。
整个过程可以逐步重启，对服务的正确性和可用性完全没有影响：
（a）即使%2寻库和%4寻库同时存在，也不影响数据的正确性，因为此时仍然是双主数据同步的；
（b）即使%4=0与%4=2的寻库落到同一个数据库实例上，也不影响数据的正确性，因为此时仍然是双主数据同步的；
上面对数据库实例进行了扩展，但是数据的数量并没有降低，我们还需要再做一步。
图片
有这些一些收尾工作：
（a）把双虚拟ip修改回单虚拟ip；
（b）解除旧的双主同步，让成对库的数据不再同步增加；
（c）增加新的双主同步，保证高可用；
（d）删除掉冗余数据，例如：ip0里%4=2的数据全部删除，只为%4=0的数据提供服务；
这一步，数据库单实例数据量减半了。
InnoDB引擎为什么高效?
技术上怎么控制并发操作？
-锁
-数据多版本
锁
-简单暴力，任务执行过程的本质是串行的
-出现了共享锁和排它锁
--共享锁(S锁)，读取数据加S锁
--排他锁(X锁) 修改时加X锁
共享锁和排他锁的区别?
-共享锁，读可以并行
-排他锁跟任何锁互斥，读和写都不可以并行
总结下：一但写数据没有完成，数据是不能被其他任务读取的，这对并发有着比较大的影响。
有没有可能，进一步提高并发呢？
数据多版本
图片
-核心原理
（1）写任务发生的时候，将数据克隆一份，以版本号区分
（2）写任务操作克隆的数据，直至提交
（3）读取数据还是旧版本上，不阻塞
所以并发提高演进的思路
1.普通锁，串行执行
2.读写锁，读读可以并发
3.数据多版本，读写都可以并发
对应到innodb，是怎么处理的呢？
先了解三个概念：redo、undo、回滚段
redo：数据库事务提交之后，必须将更新后的数据刷新到硬盘上，保证ACID原则。这里是随机读写的，如果来个事务就写一次，相当影响吞吐量。
优化：将修改的行写到redo日志中，再定期刷新到硬盘中。这里的写日志是顺序写，可以提高性能。如果有一刻数据奔溃，可以读取redo日志恢复数据。
undo：事务未提交时，可以将修改前的数据存在undo日志里，当崩溃或者事务回滚时，利用undo日志撤销修改。
举例说明：
-insert操作，undo日志存储的是PK（rowid），回滚时直接删除
-update/delete操作，undo日志记录旧数据的row，回滚时直接恢复。
回滚段：存储undo日志的地方，就是回滚段。
Innodb是基于版本并发控制的存储引擎。
MVCC就是通过“读取旧版本数据”来降低并发事务的锁冲突，提高任务的并发度。
innodb为何能做到这么高的并发？
回滚段的数据，也就是历史数据的快照，这些数不会被改变,select操作可以为所欲为的并发读取
总结
(1)常见并发控制保证数据一致性的方法有锁，数据多版本；
(2)普通锁串行，读写锁读读并行，数据多版本读写并行；
(3)redo日志保证已提交事务的ACID特性，设计思路是，通过顺序写替代随机写，提高并发；
(4)undo日志用来回滚未提交的事务，它存储在回滚段里；
(5)InnoDB是基于MVCC的存储引擎，它利用了存储在回滚段里的undo日志，即数据的旧版本，提高并发；
(6)InnoDB之所以并发高，快照读不加锁；
(7)InnoDB所有普通select都是快照读；
