面试官:"谈谈分库分表吧？"

野性酷女 2022-03-27 01:49 340阅读 0赞

> **面试官：“有并发的经验没？” **
> 
> **应聘者：“有一点。”  **
> 
> **面试官：“那你们为了处理并发，做了哪些优化？”  **
> 
> **应聘者：“前后端分离啊，限流啊，分库分表啊。。”  **
> 
> **面试官:"谈谈分库分表吧？"  **
> 
> **应聘者：“bala。bala。bala。。”  **

### 1、分库分表的原因 ###

1、随着单库中的数据量越来越大，相应的，查询所需要的时间也越来越多，这个时候，相当于数据的处理遇到了瓶颈  
2、单库发生意外的时候，需要修复的是所有的数据，而多库中的一个库发生意外的时候，只需要修复一个库（当然，也可以用物理分区的方式处理这种问题）

### 2、分库分表的常用策略 ###

2.1 垂直切分：

根据业务的不同，将原先拥有很多字段的表拆分为两个或者多个表，这样的代价我个人觉得很大，原来对这应这个表的关系，开始细分，需要一定的重构，而且随着数据量的增多，极有可能还要增加水平切分；

![640_wx_fmt_png][]

2.2 水平切分：

数据表结构，将数据分散在多个表中；

![640_wx_fmt_png 1][]

**1.有瑕疵的简单分库分表（按id的大小分库分表）**

按照分片键（我们这里就用id表示了）的大小来进行分库分表，如果你的id是自增的，而且能保证在进行分库分表后也是自增的，那么能进行很好的改造，以id大小水平切分，而且极有可能不用迁移数据。

![640_wx_fmt_other][]

当然，这里只列举了比较小的数据量，实际情况的分库的界限还是要依据具体的情况而定。这样的分库分表，因为新的数据总在一个库里，很可能导致热点过于集中（读写可能集中在一个库中），这是采取这种方式需要考虑的事情。  
如果无法保证你的id是自增长的，那么你的数据就会凌乱的分散在各个数据库，这样热点确实就分散了，可是每当你增加一个数据库的时候，你就有可能进行大量的数据迁移，应对这种情况，就是尽量减少数据迁移的代价，所以这里运用`一致性hash`的方式进行分库分表比较好，可以尽可能的减少数据迁移，并且也能让解决热点过于集中的问题。一致性hash的分库策略去百度一下或者谷歌一下应该很容易搜到。  
这里按id的大小来分库，还可以发散到按照时间来分库，比如说一个月的数据放在一个库，这个使用mycat比较容易实现按时间分库，不过你需要思考的数据的离散性，数据集中于一个两月，而剩下的几个月数据稀疏，这样的又可能需要按照数据的生产规律合并几个月到一个库中，使得数据分布均匀。

**2.比较方便的取模分库**

一般的`取模分库分表`是就是将id mod n，然后放入数据库中，这样能够使数据分散，不会有热点的问题，那么，剩下的是，在扩容的时候，是否会有数据迁移的问题，一般的扩容，当然是会有数据迁移的。

![640_wx_fmt_other 1][]

取模.PNG

例子中，对3取模，当需要扩容的时候(假设增加两个库)，则对5取模，这样的结果必然是要进行数据迁移的，但是可以运用一些方法，让它不进行数据迁移，`scale-out扩展方案`能够避免在取模扩容的时候进行数据迁移。

**(1)第一种扩容的方式：根据表的数据增加库的数量**

首先，我们有一个数据库——DB\_0,四张表——tb\_0,tb\_1,tb\_2,tb\_3  
那么我们现在数据到数据库是这样的:  
DB="DB\_0"  
TB=“tb\_"+id%4

![640_wx_fmt_other 2][]

当数据增加，需要进行扩容的时候，我增加一个数据库DB\_1  
DB="DB\_"+((id%4)/2)  
TB=“tb\_"+id%4

![640_wx_fmt_other 3][]

当我们的数据继续飙升，这个时候又需要我们增加库，这个时候进行加库操作的时候，就不是增加一个库，而必须是两个，这样才能保证不进行数据迁移。  
DB="DB\_"+id%4  
TB=“tb\_"+id%4

![640_wx_fmt_other 4][]

这个时候到了这个方案的加库上限，不能继续加库了，否则就要进行数据迁移，所以这个方案的弊端还是挺大了，这样的方式，也应该会造成单表的数据量挺大的。

**(2)第二种扩容的方式：成倍的增加表**

首先，我们还是一个数据库——DB\_0,两张表——tb\_0,tb\_1  
那么我们现在数据到数据库是这样的:  
DB="DB\_0"  
TB=“tb\_"+id%2

![640_wx_fmt_other 5][]

假设当我们数据量打到一千万的时候，我们增加一个库，这时需要我们增加两张表tb\_0\_1,tb\_1\_1,并且原来的DB\_0中库的表tb\_1整表迁移到DB\_1中，tb\_0和tb\_0\_1放在DB\_0中，tb\_1和tb\_1\_1放到DB1中。  
DB="DB\_"+id%2  
tb:  
if(id<1千万)    \{  return  "tb\_" + id %  2 \}  
else if(id>=1千万)   \{   return "tb\_"+ id % 2 + "\_1" \}

![640_wx_fmt_other 6][]

数据的增长不可能到此为止，当增加到两千万的时候，我们需要加库，这个时候，按照这种做法，我们需要增加两个库(DB\_2,DB\_3)和四张表(tb\_0\_2,tb\_1\_2,tb\_2\_2,tb\_3\_2)，将上次新增的表整表分别放进两个新的库中，然后每个库里再生成一张新表。  
DB:  
if(id < 1千万)    \{  return  "DB\_" + id %  2 \}  
else if(1千万 <= id < 2千万)   \{   return  "DB\_"+ id % 2 +2 \}  
else if(2千万 <= id )   \{   return  "DB\_"+ id % 4 \}  
tb:  
if(id < 1千万)    \{  return  "tb\_" + id %  2 \}  
else if(1千万 <= id < 2千万)   \{   return "tb\_"+ id % 2 +"*1" \}  
else if(id >= 2千万) \{ return "tb*"+ id % 4+"\_2" \}

![640_wx_fmt_other 7][]

值得注意的一点，在id超出范围的时候，该给怎么样的提示是值得思考的。

### 3、常用的分库分表中间件 ###

3.1 简单易用的组件：

*  当当sharding-jdbc
 *  蘑菇街TSharding

3.2 强悍重量级的中间件：

*  sharding
 *  TDDL Smart Client的方式（淘宝）
 *  Atlas(Qihoo 360)
 *  alibaba.cobar(是阿里巴巴（B2B）部门开发)
 *  MyCAT（基于阿里开源的Cobar产品而研发）
 *  Oceanus(58同城数据库中间件)
 *  OneProxy(支付宝首席架构师楼方鑫开发)
 *  vitess（谷歌开发的数据库中间件）

### 4、分库分表需要解决的问题 ###

> 1、事务问题

解决事务问题目前有两种可行的方案：分布式事务和通过应用程序与数据库共同控制实现事务下面对两套方案进行一个简单的对比。

方案一：使用分布式事务

*  优点： 交由数据库管理，简单有效
 *  缺点：性能代价高，特别是shard越来越多时

方案二：由应用程序和数据库共同控制

*  原理：将一个跨多个数据库的分布式事务分拆成多个仅处 于单个数据库上面的小事务，并通过应用程序来总控 各个小事务。
 *  优点：性能上有优势
 *  缺点：需要应用程序在事务控制上做灵活设计。如果使用 了spring的事务管理，改动起来会面临一定的困难。

> 2、跨节点Join的问题

只要是进行切分，跨节点Join的问题是不可避免的。但是良好的设计和切分却可以减少此类情况的发生。解决这一问题的普遍做法是分两次查询实现。在第一次查询的结果集中找出关联数据的id,根据这些id发起第二次请求得到关联数据。

> 3、跨节点的count,order by,group by以及聚合函数问题

这些是一类问题，因为它们都需要基于全部数据集合进行计算。多数的代理都不会自动处理合并工作。解决方案：与解决跨节点join问题的类似，分别在各个节点上得到结果后在应用程序端进行合并。和join不同的是每个结点的查询可以并行执行，因此很多时候它的速度要比单一大表快很多。但如果结果集很大，对应用程序内存的消耗是一个问题。

> 4、数据迁移，容量规划，扩容等问题

来自淘宝综合业务平台团队，它利用对2的倍数取余具有向前兼容的特性（如对4取余得1的数对2取余也是1）来分配数据，避免了行级别的数据迁移，但是依然需要进行表级别的迁移，同时对扩容规模和分表数量都有限制。总得来说，这些方案都不是十分的理想，多多少少都存在一些缺点，这也从一个侧面反映出了Sharding扩容的难度。

> 5、事务

5.1 分布式事务

*  参考：   
    关于分布式事务、两阶段提交、一阶段提交、Best Efforts 1PC模式和事务补偿机制的研究
 *  优点  
    基于两阶段提交，最大限度地保证了跨数据库操作的“原子性”，是分布式系统下最严格的事务实现方式。  
    实现简单，工作量小。由于多数应用服务器以及一些独立的分布式事务协调器做了大量的封装工作，使得项目中引入分布式事务的难度和工作量基本上可以忽略不计。
 *  缺点  
    系统“水平”伸缩的死敌。基于两阶段提交的分布式事务在提交事务时需要在多个节点之间进行协调,最大限度地推后了提交事务的时间点，客观上延长了事务的执行时间，这会导致事务在访问共享资源时发生冲突和死锁的概率增高，随着数据库节点的增多，这种趋势会越来越严重，从而成为系统在数据库层面上水平伸缩的"枷锁"， 这是很多Sharding系统不采用分布式事务的主要原因。

**基于Best Efforts 1PC模式的事务**

参考spring-data-neo4j的实现。鉴于Best Efforts 1PC模式的性能优势，以及相对简单的实现方式，它被大多数的sharding框架和项目采用

5.2 事务补偿（幂等值）

对于那些对性能要求很高，但对一致性要求并不高的系统，往往并不苛求系统的实时一致性，只要在一个允许的时间周期内达到最终一致性即可，这使得事务补偿机制成为一种可行的方案。事务补偿机制最初被提出是在“长事务”的处理中，但是对于分布式系统确保一致性也有很好的参考意义。笼统地讲，与事务在执行中发生错误后立即回滚的方式不同，事务补偿是一种事后检查并补救的措施，它只期望在一个容许时间周期内得到最终一致的结果就可以了。事务补偿的实现与系统业务紧密相关，并没有一种标准的处理方式。一些常见的实现方式有：对数据进行对帐检查;基于日志进行比对;定期同标准数据来源进行同步，等等。

> 6、ID问题

一旦数据库被切分到多个物理结点上，我们将不能再依赖数据库自身的主键生成机制。一方面，某个分区数据库自生成的ID无法保证在全局上是唯一的；另一方面，应用程序在插入数据之前需要先获得ID,以便进行SQL路由.  
一些常见的主键生成策略

6.1 UUID

使用UUID作主键是最简单的方案，但是缺点也是非常明显的。由于UUID非常的长，除占用大量存储空间外，最主要的问题是在索引上，在建立索引和基于索引进行查询时都存在性能问题。

**结合数据库维护一个Sequence表**

此方案的思路也很简单，在数据库中建立一个Sequence表，表的结构类似于：

1CREATE TABLE `SEQUENCE` (  
    2    `table_name` varchar(18) NOT NULL,  
    3    `nextid` bigint(20) NOT NULL,  
    4    PRIMARY KEY (`table_name`)  
    5) ENGINE=InnoDB

每当需要为某个表的新纪录生成ID时就从Sequence表中取出对应表的nextid,并将nextid的值加1后更新到数据库中以备下次使用。此方案也较简单，但缺点同样明显：由于所有插入任何都需要访问该表，该表很容易成为系统性能瓶颈，同时它也存在单点问题，一旦该表数据库失效，整个应用程序将无法工作。有人提出使用Master-Slave进行主从同步，但这也只能解决单点问题，并不能解决读写比为1:1的访问压力问题。

6.2 Twitter的分布式自增ID算法Snowflake

在分布式系统中，需要生成全局UID的场合还是比较多的，twitter的snowflake解决了这种需求，实现也还是很简单的，除去配置信息，核心代码就是毫秒级时间41位 机器ID 10位 毫秒内序列12位。

*  10---0000000000 0000000000 0000000000 0000000000 0 --- 00000 ---00000 ---000000000000  
    在上面的字符串中，第一位为未使用（实际上也可作为long的符号位），接下来的41位为毫秒级时间，然后5位datacenter标识位，5位机器ID（并不算标识符，实际是为线程标识），然后12位该毫秒内的当前毫秒内的计数，加起来刚好64位，为一个Long型。

这样的好处是:**整体上按照时间自增排序，并且整个分布式系统内不会产生ID碰撞（由datacenter和机器ID作区分），并且效率较高，经测试，snowflake每秒能够产生26万ID左右，完全满足需要。**

> 7、跨分片的排序分页

一般来讲，分页时需要按照指定字段进行排序。当排序字段就是分片字段的时候，我们通过分片规则可以比较容易定位到指定的分片，而当排序字段非分片字段的时候，情况就会变得比较复杂了。为了最终结果的准确性，我们需要在不同的分片节点中将数据进行排序并返回，并将不同分片返回的结果集进行汇总和再次排序，最后再返回给用户。如下图所示：

![640_wx_fmt_png 2][]

上面图中所描述的只是最简单的一种情况（取第一页数据），看起来对性能的影响并不大。但是，如果想取出第10页数据，情况又将变得复杂很多，如下图所示：

![640_wx_fmt_png 3][]

有些读者可能并不太理解，为什么不能像获取第一页数据那样简单处理（排序取出前10条再合并、排序）。其实并不难理解，因为各分片节点中的数据可能是随机的，为了排序的准确性，必须把所有分片节点的前N页数据都排序好后做合并，最后再进行整体的排序。很显然，这样的操作是比较消耗资源的，用户越往后翻页，系统性能将会越差。

那如何解决分库情况下的分页问题呢？有以下几种办法：

如果是在前台应用提供分页，则限定用户只能看前面n页，这个限制在业务上也是合理的，一般看后面的分页意义不大（如果一定要看，可以要求用户缩小范围重新查询）。

如果是后台批处理任务要求分批获取数据，则可以加大page size，比如每次获取5000条记录，有效减少分页数（当然离线访问一般走备库，避免冲击主库）。

分库设计时，一般还有配套大数据平台汇总所有分库的记录，有些分页查询可以考虑走大数据平台。

> 8、分库策略

分库维度确定后，如何把记录分到各个库里呢?

8.1 两种方式：

*  根据数值范围，比如用户Id为1-9999的记录分到第一个库，10000-20000的分到第二个库，以此类推。
 *  根据数值取模，比如用户Id mod n，余数为0的记录放到第一个库，余数为1的放到第二个库，以此类推。

优劣比较：

> 评价指标按照范围分库按照Mod分库  
> 库数量前期数目比较小，可以随用户/业务按需增长前期即根据mode因子确定库数量，数目一般比较大  
> 访问性能前期库数量小，全库查询消耗资源少，单库查询性能略差前期库数量大，全库查询消耗资源多，单库查询性能略好  
> 调整库数量比较容易，一般只需为新用户增加库，老库拆分也只影响单个库困难，改变mod因子导致数据在所有库之间迁移  
> 数据热点新旧用户购物频率有差异，有数据热点问题新旧用户均匀到分布到各个库，无热点  
> 实践中，为了处理简单，选择mod分库的比较多。同时二次分库时，为了数据迁移方便，一般是按倍数增加，比如初始4个库，二次分裂为8个，再16个。这样对于某个库的数据，一半数据移到新库，剩余不动，对比每次只增加一个库，所有数据都要大规模变动。  
> 补充下，mod分库一般每个库记录数比较均匀，但也有些数据库，存在超级Id，这些Id的记录远远超过其他Id，比如在广告场景下，某个大广告主的广告数可能占总体很大比例。如果按照广告主Id取模分库，某些库的记录数会特别多，对于这些超级Id，需要提供单独库来存储记录。

> 9、分库数量

分库数量首先和单库能处理的记录数有关，一般来说，Mysql 单库超过5000万条记录，Oracle单库超过1亿条记录，DB压力就很大(当然处理能力和字段数量/访问模式/记录长度有进一步关系)。

在满足上述前提下，如果分库数量少，达不到分散存储和减轻DB性能压力的目的；如果分库的数量多，好处是每个库记录少，单库访问性能好，但对于跨多个库的访问，应用程序需要访问多个库，如果是并发模式，要消耗宝贵的线程资源；如果是串行模式，执行时间会急剧增加。

最后分库数量还直接影响硬件的投入，一般每个分库跑在单独物理机上，多一个库意味多一台设备。所以具体分多少个库，要综合评估，一般初次分库建议分4-8个库。

> 10、路由透明

分库从某种意义上来说，意味着DB schema改变了，必然影响应用，但这种改变和业务无关，所以要尽量保证分库对应用代码透明，分库逻辑尽量在数据访问层处理。当然完全做到这一点很困难，具体哪些应该由DAL负责，哪些由应用负责，这里有一些建议：

对于单库访问，比如查询条件指定用户Id，则该SQL只需访问特定库。此时应该由DAL层自动路由到特定库，当库二次分裂时，也只要修改mod 因子，应用代码不受影响。

对于简单的多库查询，DAL负责汇总各个数据库返回的记录，此时仍对上层应用透明。

> 11、使用框架还是自主研发

目前市面上的分库分表中间件相对较多，其中基于代理方式的有MySQL Proxy和Amoeba，基于Hibernate框架的是Hibernate Shards，基于jdbc的有当当sharding-jdbc，基于mybatis的类似maven插件式的有蘑菇街的蘑菇街TSharding，通过重写spring的ibatis template类是Cobar Client，这些框架各有各的优势与短板，架构师可以在深入调研之后结合项目的实际情况进行选择，但是总的来说，我个人对于框架的选择是持谨慎态度的。一方面多数框架缺乏成功案例的验证，其成熟性与稳定性值得怀疑。另一方面，一些从成功商业产品开源出框架（如阿里和淘宝的一些开源项目）是否适合你的项目是需要架构师深入调研分析的。当然，最终的选择一定是基于项目特点、团队状况、技术门槛和学习成本等综合因素考量确定的。

### 5、如何部署 ###

### **停机部署法 ** ###

大致思路就是，挂一个公告，半夜停机升级，然后半夜把服务停了，跑数据迁移程序，进行数据迁移。

步骤如下:

（1）出一个公告，比如“今晚00:00～6:00进行停机维护，暂停服务”  
（2）写一个迁移程序，读`db-old`数据库，通过中间件写入新库`db-new1`和`db-new2`，具体如下图所示

![640_wx_fmt_png 4][]

（3）校验迁移前后一致性，没问题就切该部分业务到新库。

顺便科普一下，这个中间件。现在流行的分库分表的中间件有两种，一种是`proxy`形式的，例如`mycat`，是需要额外部署一台服务器的。还有一种是`client`形式的，例如当当出的`Sharding-JDBC`，就是一个jar包，使用起来十分轻便。我个人偏向`Sharding-JDBC`，这种方式，无需额外部署，无其他依赖，DBA也无需改变原有的运维方式。

评价：

大家不要觉得这种方法low，我其实一直觉得这种方法可靠性很强。而且我相信各位读者所在的公司一定不是什么很牛逼的互联网公司，如果你们的产品凌晨1点的用户活跃数还有超过1000的，你们握个爪！毕竟不是所有人都在什么电商公司的，大部分产品半夜都没啥流量。所以此方案，并非没有可取之处。

但是此方案有一个缺点，**累！**不止身体累，心也累！你想想看，本来定六点结束，你五点把数据库迁移好，但是不知怎么滴，程序切新库就是有点问题。于是，眼瞅着天就要亮了，赶紧把数据库切回老库。第二个晚上继续这么干，简直是身心俱疲。

`ps：`这里教大家一些技巧啊，如果你真的没做过分库分表，又想吹一波，涨一下工资，建议答这个方案。因为这个方案比较low，low到没什么东西可以深挖的，所以答这个方案，比较靠谱。

> **你刚才刚好有提到分库分表的相关问题，我们当时部署的时候，先停机。然后半夜迁移数据，然后第二天将流量切到新库，这种方案太累，不知道贵公司有没有什么更好的方案？**

那么这种情况下，面试官会有两种回答。第一种，面试官硬着头皮随便扯。第二种，面试官真的做过，据实回答。记住，面试官怎么回答的不重要。重点的是，你这个问题出去，会给面试官一种错觉:"这个小伙子真的做过分库分表。"

如果你担心进去了，真派你去做分库分表怎么办？OK，不要怕。我赌你试用期碰不到这个活。因为能进行分库分表，必定对业务非常熟。还在试用期的你，必定对业务不熟，如果领导给你这种活，我只能说他有一颗大心脏。

ok，指点到这里。面试本来就是一场斗智斗勇的过程，扯远了，回到我们的主题。

### **双写部署法（一）** ###

这个就是不停机部署法，这里我需要先引进两个概念:**历史数据**和**增量数据**。

假设，我们是对一张叫做`test_tb`的表进行拆分，因为你要进行双写，系统里头和`test_tb`表有关的业务之前必定会加入一段双写代码，同时往老库和新库中写，然后进行部署，那么

**历史数据：**在该次部署前，数据库表`test_tb`的有关数据，我们称之为历史数据。  
**增量数据：**在该次部署后，数据库表`test_tb`的新产生的数据，我们称之为增量数据。

然后迁移流程如下

（1）先计算你要迁移的那张表的`max(主键)`。在迁移过程中，只迁移`db-old`中`test_tb`表里，主键小等于该`max(主键)`的值，也就是所谓的历史数据。

这里有特殊情况，如果你的表用的是uuid，没法求出`max(主键)`，那就以创建时间作为划分历史数据和增量数据的依据。如果你的表用的是uuid,又没有创建时间这个字段，我相信机智的你，一定有办法区分出历史数据和增量数据。

（2）在代码中，与`test_tb`有关的业务，多加一条往消息队列中发消息的代码，将操作的sql发送到消息队列中，至于消息体如何组装，大家自行考虑。**需要注意的是，**只发写请求的sql，只发写请求的sql，只发写请求的sql。重要的事情说三遍！  
原因有二：

（1）只有写请求的sql对恢复数据才有用。

（2）系统中，绝大部分的业务需求是读请求，写请求比较少。

注意了，在这个阶段，我们不消费消息队列里的数据。我们只发写请求，消息队列的消息堆积情况不会太严重！

（3）系统上线。另外，写一段迁移程序，迁移`db-old`中`test_tb`表里，主键小于该`max(主键)`的数据，也就是所谓的历史数据。

上面步骤（1）～步骤（3）的过程如下

![640_wx_fmt_png 5][]

等到`db-old`中的历史数据迁移完毕，则开始迁移增量数据，也就是在消息队列里的数据。  
（4）将迁移程序下线，写一段订阅程序订阅消息队列中的数据  
（5）订阅程序将订阅到到数据，通过中间件写入新库  
（6）新老库一致性验证，去除代码中的双写代码，将涉及到`test_tb`表的读写操作，指向新库。  
上面步骤（4）～步骤（6）的过程如下

![640_wx_fmt_png 6][]

这里大家可能会有一个问题，在步骤(1)～步骤(3),系统对历史数据进行操作，会造成不一致的问题么？

OK，不会。这里我们对`delete`操作和`update`操作做分析，因为只有这两个操作才会造成历史数据变动，`insert`进去的数据都是属于增量数据。

（1）对`db-old`中`test_tb`表的历史数据发出`delete`操作，数据还未删除，就被迁移程序给迁走了。此时`delete`操作在消息队列里还有记录，后期订阅程序订阅到该`delete`操作，可以进行删除。

（2）对`db-old`中`test_tb`表的历史数据发出`delete`操作，数据已经删除，迁移程序迁不走该行数据。此时`delete`操作在消息队列里还有记录，后期订阅程序订阅到该`delete`操作，再执行一次`delete`，并不会对一致性有影响。  
对`update`的操作类似，不赘述。

### **双写部署法（二）** ###

上面的方法有一个硬伤，注意我有一句话

> **(2)在代码中，与test\_tb有关的业务，多加一条往消息队列中发消息的代码，将操作的sql发送到消息队列中，至于消息体如何组装，大家自行考虑。**

大家想一下，这么做，是不是造成了严重的代码入侵。将非业务代码嵌入业务代码，这么做，后期删代码的时候特别累。

**有没什么方法，可以避免这个问题的？**

有的，订阅`binlog`日志。关于`binlog`日志，我尽量下周写一篇《研发应该掌握的binlog知识》，这边我就介绍一下作用

> **记录所有数据库表结构变更（例如CREATE、ALTER TABLE…）以及表数据修改（INSERT、UPDATE、DELETE…）的二进制日志。binlog不会记录SELECT和SHOW这类操作，因为这类操作对据本身并没有修改。**

还记得我们在**双写部署法(一)**里介绍的，往消息队列里发的消息，都是写操作的消息。而`binlog`日志记录的也是写操作。所以订阅该日志，也能满足我们的需求。

于是步骤如下

（1）打开binlog日志，系统正常上线就好  
（2）还是写一个迁移程序，迁移历史数据。步骤和上面类似，不啰嗦了。  
步骤（1）~步骤（2）流程图如下

![640_wx_fmt_png 7][]

（3）写一个订阅程序，订阅binlog(mysql中有`canal`。至于oracle中，大家就随缘自己写吧)。然后将订阅到的数据通过中间件，写入新库。  
（4）检验一致性，没问题就切库。  
步骤（3）~步骤（4）流程图如下

![640_wx_fmt_png 8][]

### **怎么验数据一致性** ###

这里大概介绍一下吧，这篇的篇幅太长了，大家心里有底就行。

（1）先验数量是否一致，因为验数量比较快。

**至于验具体的字段，有两种方法：**

（2.1）有一种方法是，只验关键性的几个字段是否一致。

（2.2）还有一种是 ，一次取50条(不一定50条，具体自己定，我只是举例),然后像拼字符串一样，拼在一起。用md5进行加密，得到一串数值。新库一样如法炮制，也得到一串数值，比较两串数值是否一致。如果一致，继续比较下50条数据。如果发现不一致，用二分法确定不一致的数据在0-25条，还是26条-50条。以此类推，找出不一致的数据，进行记录即可。

**END**

## ============================================================ ##

## 欢迎关注公众号：程序员面试经验分享(jobbible) ##

![70][]

[640_wx_fmt_png]: /images/20220327/055db0de87ec4e789b7698678a56c0db.png
[640_wx_fmt_png 1]: /images/20220327/c0c152794cfa46739223b9c91bb71797.png
[640_wx_fmt_other]: /images/20220327/a40b2854ea9e47a491beb05e0f226684.png
[640_wx_fmt_other 1]: /images/20220327/26505691c6db448f8d9bcfed173e10cd.png
[640_wx_fmt_other 2]: /images/20220327/97a299c0c335429cb7e3d4fe11391608.png
[640_wx_fmt_other 3]: /images/20220327/5c96bcaf0af344229ab253c09fbc37ab.png
[640_wx_fmt_other 4]: /images/20220327/7082fbef0d3a42228ed47bdabcb9d8d7.png
[640_wx_fmt_other 5]: /images/20220327/cf1bdcf1fe65402cb4850555e4fd9c61.png
[640_wx_fmt_other 6]: /images/20220327/30e5a6afdfea450288bf9a6db1aea957.png
[640_wx_fmt_other 7]: /images/20220327/0b7ddc39bc044ff0828f632a78368452.png
[640_wx_fmt_png 2]: /images/20220327/e1d3626cdb8845cbb2c70ea80361902a.png
[640_wx_fmt_png 3]: /images/20220327/082e9055644b4369bd656843395ed89b.png
[640_wx_fmt_png 4]: /images/20220327/bc9bf1bcd91a4226a84df1129942b049.png
[640_wx_fmt_png 5]: /images/20220327/8592807cc790487bb2925b10e58380aa.png
[640_wx_fmt_png 6]: /images/20220327/de0c3b0beeed46e6910d71d33328e1a2.png
[640_wx_fmt_png 7]: /images/20220327/798d121600974689a67258bdc31b936b.png
[640_wx_fmt_png 8]: /images/20220327/b5ebc0447f824be4a7b2494c89649677.png
[70]: /images/20220327/9739d53dda7844aba75d2dca22a4d1a1.png