目录

• 数据库扩容
  • 1.停机方案
  • 2.停写方案
  • 3.日志方案
  • 4.双写方案（适合中小数据库，百万以内）
  • 5.平滑2N方案（适合大数据量）

数据库扩容

一般只在数据量较小的时候进行操作。

分库分表的缺点：影响分页

数据分区概念

把一个表分区，mysql是自动支持分区的。例，根据时间分区。读取的时候就可以根据分区进行查询。容易出现尾部热点问题，大多数情况下，都是读取新写入的数据，QPS问题难解决。

QPS（TPS）= 并发数/平均响应时间

并发数 = QPS*平均响应时间

1.停机方案

停服务公告，在停止时间进行数据库迁移

1.发布公告
为了进行数据的重新拆分，在停止服务之前，我们需要提前通知用户，比如：我们的服务会在yyyy-MM-dd进行升级，给您带来的不便敬请谅解。
2.停止服务
关闭Service
3.离线数据迁移（拆分，重新分配数据）
将旧库中的数据按照Service层的算法，将数据拆分，重新分配数据
4.数据校验
开发定制一个程序对旧库和新库中的数据进行校验，比对
5.更改配置
修改Service层的配置算法，也就是将原来的uid%3变为uid%4
6.恢复服务
重启Service服务
7.回滚预案 
针对上述的每个步骤都要有数据回滚预案，一旦某个环节（如：数据迁移，恢复服务等）执行失败，立刻进行回滚，重新再来

停止服务之后， 能够保证迁移工作的正常进行， 但是服务停止，伤害用户体验， 并造成了时间压力， 必须在指定的时间内完成迁移。

2.停写方案

只支持读，不支持写。

最好的方式是在http请求到达控制层的时候。难点在于区分写请求和读请求

1.支持读写分离
数据库支持读写分离，在扩容之前，每个数据库都提供了读写功能，数据重新分配的过程中，将每个数据库设置为只读状态，关闭写的功能
2.升级公告
3.中断写操作，隔离写数据源（或拦截返回统一提示）
在Service层对所有的写请求进行拦截，统一返回提示信息，如：服务正在升级中，只对外提供读服务
4.数据同步处理
将旧库中的数据按照Service层的算法，将数据重新分配，迁移（复制数据）
5.数据校验
6.更改配置
7.恢复写操作  
设置数据库恢复读写功能，去除Service层的拦截提示
8.数据清理
使用delete语句对冗余数据进行删除
9.回滚预案
针对上述的每个步骤都要有数据回滚预案，一旦某个环节（如：数据迁移等）执行失败，立刻进行回滚，重新再来

缺点：在数据的复制过程需要消耗大量的时间，停写时间太长，数据需要先复制，再清理冗余数据

3.日志方案

老数据库继续服务，并记录写日志。

新数据库在完成迁移数据后，根据老数据库的日志对数据进行更新。

当最终一致时，切换服务。蓝绿更新、滚动更新。

日志记录
库 表 主键 操作
db t1 id1 update
db t1 id1 insert
db t1 id1 delete

4.双写方案（适合中小数据库，百万以内）

mysql有四种常用日志文件：redo log/undo log/bin log/relay log

redo log：
前进日志：所有写请求，先写入buffer,再写入硬盘。
undo log：
回滚日志：当对数据库进行update、delete、insert操作时，将反向日志记录下来。
快照读：所有select 操作都是基于快照读。基于mvcc控制
（update、delete、insert使用）
bin log：用于主从复制，主数据库完成写操作，写入日志，从库会有一个专门的线程读bin log
relay log：中继日志，用于主从复制，读取bin log ，对从数据库进行操作

1、断开主从同步。

2、使用从库中的数据，对新数据库进行同步，同步完成后进行校验。

3、同步完成之后，使用cancel-server监听主数据库bin log。

4、使用cancel-client写入增量数据，直至差距接近秒级（当最终一致时，切换服务）。

5.平滑2N方案（适合大数据量）

相当于节省了数据同步的操作

1.两个数据库，双向主从复制（两者数据高度一致）

2.扩容时，停止两者间的主从复制。

3.按照约定进行分库操作。

4.后续可以根据情况，删除脏数据

标签：回滚,log,Service,狂野,超强,架构师,日志,数据,数据库
来源： https://www.cnblogs.com/xieshier/p/16652700.html