共计 2749 个字符，预计需要花费 7 分钟才能阅读完成。
作为开发人员，咱们有很大概率会遇到须要将以后正在应用的数据库迁徙到另一个数据库的场景。比方你在我的项目晚期抉择了 MySQL 作为数据库，尽管它曾经能满足大多数业务场景和性能要求，但随着你的数据量越来越大业务日趋简单，持续应用 MySQL 则可能成为瓶颈，这时候你可能要开始思考将 MySQL 替换为更适宜的数据库比方 HBase（或 Cassandra…）。
对于一个在线业务零碎来说，迁徙数据库的挑战在于不仅要做到不停机无缝迁徙还要保障迁徙过程危险可控，这也正是本文要分享的内容，介绍如何应用性能开关无缝、平安地实现数据库迁徙。
迁徙案例：将 MySQL 迁徙到 HBase
接下来将通过一个案例介绍整个迁徙的实现过程。某个在线音讯业务因为受限于 MySQL 性能和存储瓶颈，所以须要将数据迁徙到 HBase 以便于进一步扩充业务规模。
1、应用性能开关实现迁徙管制
咱们这里假如利用程序逻辑都是通过 DAO（数据存取对象）来查问 / 读取 MySQL 长久化数据。为了能将数据存取切换到 HBase 中，所以第一步是编写一个针对 HBase 的 DAO，并且和 MySQL DAO 实现雷同的接口以提供雷同数据读写能力。
当初曾经有两种 DAO 接口实现，一种有反对 MySQL，另一种是反对 HBase。此时开始引入咱们的性能开关治理服务 FeatureProbe。
先在 eatureProbe 上创立四个 Boolean 类型性能开关来独立管制对 MySQL 和 HBase 的读写，以其中一个开关（messages-mysql-write）为例配置如下所示：
接下来咱们对外对立提供 saveMessage 办法保留一个音讯，代码如下所示：
public void storeMessage(Message message, FPUser fpUser) {if(fpClient.booleanValue('messages-mysql-write', fpUser, true)) {mysqlMesseageDao.save(message)
}
if(fpclient.BooleanValue('messages-hbase-write', fpUser, true)) {hbaseMesseageDao.save(message)
}
}须要留神的是，咱们容许同一音讯可能会保留在两个中央，其目标是保障了旧存储（MySQL）的完整性的同时开始将音讯写入新数据存储。对于读取来说其实现思路大抵和存储相似，例如实现一个能依据 ID 查问音讯的办法，代码如下所示：
public Message findMessageById(Long id, FPUser fpUser) {
// 同时获取查问 mysql 和 hbase 的开关后果
boolean shouldReadMySQL = fpClient.booleanValue('events-mysql-read', fpUser, true)
boolean shouldReadHbase = fpClient.booleanValue('events-hbase-read', fpUser, true)
if (shouldReadMySQL && shouldReadHbase) { // 当开关被同时开启时，将比照两者后果，但依然返回旧存储数据
mysqlMessage = mysqlMessageDao.findMessageById(id)
hbaseMessage = hbaseMessageDao.findMessageById(id)
if(deepEqualsEntity(mysqlMessage, hbaseMessage)) {
logger.error("MySQL and Hbase message differ: mysql: {}, hbase: {}",
mysqlMessage,
hbaseMessage)
}
return mysqlMessage
} else if (shouldReadMySQL) { // 只从 MySQL 查问
return mysqlMessageDao.findMessageById(id)
} else { // 只从 HBase 中查问
return hbaseMessageDao.findMessageById(id)
}
}这里的点在于，咱们查看两个“读取”的开关后果，当发现两者都启用时，咱们会别离两个数据库读取数据，并比拟后果是否统一，当发现不统一时，咱们会记录谬误，并最终返回旧存储（MySQL）中的数据。
2、渐进式放量迁徙
当初咱们曾经将从新老存储读写的代码封装在性能开关中，接下来须要部署代码并进行测试。此时只须要敞开 HBase 读写开关，并关上 mysql 读写开关，便能够平安地将代码部署上线。
咱们测试迁徙时，只须要在 FeatureProbe 上批改 HBase“写开关”的人群规定，仅为特定用户 QA 开启，此时只有 QA 的音讯会存储到 HBase，过程中察看性能指标和谬误日志，如果所有合乎预期，进一步批改人群规定将写 HBase 在更多的用户上失效，直到所有用户的“写操作”均同时写入了两个数据库。
当咱们写入性能感到称心时，此时能够开始为一小部分用户关上 HBase 的读取开关，而后再次察看性能指标和谬误日志，其中特地须要关注是否有 **“MySQL and Hbase message differ…”的日志来确保两个存储数据的一致性。当然，这里即使咱们看到数据不统一的谬误日志，对用户也不会产生任何影响，因为他们仍在应用旧数据存储中的数据。如果数据和指标均合乎预期，您能够为局部用户敞开 MySQL 的读关开，将应用 HBase 的数据，并最终直到所有用户均从 HBase 中读取。
最初，当咱们向所有用户开启 HBase 读取和写入操作后，应该将所有旧数据从旧数据存储迁徙到新数据存储（确保以幂等形式执行此操作）来保证数据的整体完整性。
可见，通过上述性能开关渐进式放量迁徙的形式，不仅让使得迁徙能够无缝进行（对用户无感知），还无效保障的迁徙的安全性。
3、收尾工作
最初一步，咱们须要确保敞开了旧数据库 (MySQL) 的读写开关，同时删除代码中对所有四个开关的所有援用，使代码中最终只剩下对 HBase (新数据库)的读 / 写。再次部署上线后，便实现了整个数据库的迁徙工作。
在 FeatureProbe 开关治理也很简略，因为以上四个开关曾经实现了数据库迁徙的使命，对于曾经过期、已实现工作的开关都能够应用下线操作进行治理。
FeatureProbe 就是一个高效的性能治理 （Feature management） 开源服务，它提供了灰度放量、AB 试验、实时配置变更等针对性能粒度的一系列治理能力。目前 FeatureProbe 应用 Apache 2.0 License 协定曾经齐全开源, 开源地址：https://github.com/FeaturePro…。
