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)写接口是少数接口，改动点较少;

（编辑：河北网）

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