文章目录提示：学习笔记 欢迎指点
一个小项目从最初的一台数据库设计可以满足我们的业务需求，后期随着用户量的增加，用户产生的数据信息被源源不断的添加到数据库中，最终达到数据库的最佳存储容量。如果此时继续向数据库中新增数据，会导致数据库的CRUD等基本操作变慢，进而影响整个服务的响应速度。这时，我们需要考虑增加新的节点，对数据库进行水平扩容。
停止服务之后， 能够保证迁移工作的正常进行， 但是服务停止，伤害用户体验， 并造成了时间压力， 必须在指定的时间内完成迁移。
优点：简单，易操作！！！
缺点：不高可用，用户体验不好！！！
适用：游戏系统；对高可用要求不高的服务。
基础步骤：
二、停写方案1.发布公告
为了进行数据的重新拆分，在停止服务之前，我们需要提前通知用户，比如：我们的服务会在yyyy-MM-dd进行升级，给您带来的不便敬请谅解。
2.停止服务
关闭Service
3.离线数据迁移（拆分，重新分配数据）
将旧库中的数据按照Service层的算法，将数据拆分，重新分配数据
4.数据校验
开发定制一个程序对旧库和新库中的数据进行校验，比对
5.更改配置
修改Service层的配置算法
6.恢复服务
重启Service服务
7.回滚预案
针对上述的每个步骤都要有数据回滚预案，一旦某个环节（如：数据迁移，恢复服务等）执行失败，立刻进行回滚，重新再来
停机方案的妥协方案。
缺点：在据的复制过程需要消耗大量的时间，停写时间太长，数据需要先复制，再清理冗余数据。
基础步骤：
三、平滑2N方案（推荐）1.支持读写分离
数据库支持读写分离，在扩容之前，每个数据库都提供了读写功能，数据重新分配的过程中，将每个数据库设置为只读状态，关闭写的功能
2.升级公告
为了进行数据的重新拆分，在停写之前，我们需要提前通知用户，比如：我们的服务会在yyyy-MM-dd进行升级，给您带来的不便敬请谅解。
3.中断写操作，隔离写数据源（或拦截返回统一提示）
在Service层对所有的写请求进行拦截，统一返回提示信息，如：服务正在升级中，只对外提供读服务
4.数据同步处理
将旧库中的数据按照Service层的算法，将数据重新分配，迁移（复制数据）
5.数据校验
开发定制一个程序对旧库中的数据进行备份，使用备份的数据和重新分配后的数据进行校验，比对
6.更改配置
通过配置中心，修改Service层的配置算法，这个过程不需要重启服务
7.恢复写操作
设置数据库恢复读写功能，去除Service层的拦截提示
8.数据清理
使用delete语句对冗余数据进行删除
9.回滚预案
针对上述的每个步骤都要有数据回滚预案，一旦某个环节（如：数据迁移等）执行失败，立刻进行回滚，重新再来
优点：扩容期间，服务照常进行，保证高可用；每个数据库少了一半的数据量。
缺点：程序复杂，需要配置双主、主主双写、检测数据同步等额外技术。
适用：对高可用要求高的服务。
线上数据库，为了保障其高可用，一般每台主库会配置一台从库，主库负责读写，从库负责读取。下图所示，A，B是主库，A0和B0是从库。
当需要扩容的时候，我们把A0和B0升级为新的主库节点，如此由2个分库变为4个分库。同时在上层的分片配置，做好映射，规则如下:
把uid%4=0和uid%4=2的数据分别分配到A和A0主库中
把uid%4=1和uid%4=3的数据分配到B和B0主库中
因为A和A0库的数据相同，B和B0数据相同，此时无需做数据迁移。只需调整变更一下分片配置即可，通过配置中心更新，不需要重启。
由于之前uid%2的数据是分配在2个库里面，扩容之后需要分布到4个库中，但由于旧数据仍存在（uid%4=0的节点,还有一半uid%4=2的数据），所以需要对冗余数据做一次清理。
这个清理，并不会影响线上数据的一致性，可以随时随地进行。
处理完成之后，为保证数据的高可用，以及将来下一步的扩容需求。可以为现有的主库再次分配一个从库。
适合的，才是最好的！！！根据项目和业务需要，停机或平滑2N方案都有适合它的场景。
