100亿数据，非“双倍”扩容，如何不影响服务，数据平滑迁移？

前次《百亿级数据DB秒级滑腻扩容!》之后，许多伴侣提问，说假如不是“双倍”扩容，可否做到滑腻迁徙，不影响处事呢?

合用什么场景?

互联网有许多“数据量较大，并发量较大，营业伟大度较高”的营业场景，其典范体系分层架构如下：

(1)上游是营业层biz，实现本性化的营业逻辑;

(2)中游是处事层service，封装数据会见;

(3)下流是数据层db，存储固化的营业数据;

处事化分层架构的甜头是，处事层屏障下流数据层的伟大性，譬喻缓存、分库分表、存储引擎等存储细节不必要向挪用方袒露，而只向上游提供利便的RPC会见接口，当有一些数据层变革的时辰，全部的挪用方也不必要进级，只必要处事层进级即可。

互联网架构，许多时辰面对着这样一些需求：

(1)底层表布局改观：数据量很是大的环境下，数据表增进了一些属性，删除了一些属性，修改了一些属性。

(2)分库个数变革：因为数据量的一连增进，底层分库个数非成倍增进。

(3)底层存储介质变革：底层存储引擎由一个数据库换为另一个数据库。

各种需求，都必要举办数据迁徙，怎样滑腻迁徙数据，迁徙进程不断机，担保辖档同续处事，是文本将要接头的题目。

方案一：停机方案

在接头滑腻迁徙数据方案之前，先看下不服滑的停机数据迁徙方案，首要分三个步调。

步调一：挂一个相同“为了给宽大用户提供更好的处事，处事器会在破晓0:00-0:400举办停机维护”的通告，并在对应时段举办停机，这个时段体系没有流量进入。

步调二：停机后，研发一个离线的数据迁徙器材，举办数据迁徙。针对第一节的三类需求，会别分开拓差异的数据迁徙器材。

(1)底层表布局改观需求：开拓旧表导新表的器材;

(2)分库个数调动需求：开拓2库导3库的器材;

(3)底层存储介质调动需求：开拓Mongo导Mysql器材;

步调三：规复处事，并将流量切到新库，差异的需求，也许会涉及差异处事进级。

(1)底层表布局改观需求：处事要进级到会见新表;

(2)分库个数调动需求：处事不必要进级，只必要改寻库路由设置;

(3)底层存储介质调动需求：处事进级到会见新的存储介质;

总的来说，停机方案是相对直观和简朴的，但对处事的可用性有影响，很多游戏公司的处事器进级，游戏分区与合区，也许会回收相同的方案。

除了影响处事的可用性，这个方案尚有一个弱点，就是必需在指按时刻完成进级，这个对研发、测试、运维同窗来说，压力会很是大，一旦呈现题目譬喻数据纷歧致，必需在规按时刻内办理，不然只能回滚。按照履历，人压力越大越轻易堕落，这个弱点必然水平上是致命的。

无论怎样，停机方案并不是本日要接头的重点，接下来看一下常见的滑腻数据迁徙方案。

方案二：追日记方案

追日记方案，是一个高可用的滑腻迁徙方案，这个方案首要分为五个步调。

数据迁徙前，上游营业应用通过旧的处事会见旧的数据。

步调一：处事举办进级，记录“对旧库上的数据修改”的日记(这里的修改，为数据的insert, delete, update)，这个日记不必要记录具体数据，首要记录：

(1)被修改的库;

(2)被修改的表;

(3)被修改的独一主键;

详细新增了什么行，修改后的数据名目是什么，不必要具体记录。这样的甜头是，不管营业细节怎样变革，日记的名目是牢靠的，这样能担保方案的通用性。

这个处事进级风险较小：

(1)写接口是少数接口，窜改点较少;

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!