数倍数据平滑扩容迁移方案

首先我们先来看下数据库的高可用一般都是怎么实现的。我们还是借用图来说明。真想手绘。

图片

如上图所示，两个相互同步的主库使用相同的虚拟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都是快照读；