在线数据迁移经验：如何为正在飞行的飞机更换引擎.docxVIP

在线数据迁移阅历：如何为正在飞行的飞机更换引擎 编写双写的代码规律之前，首先要依据业务规章和功能目标确定 HBase 的表结构和主键设计。?对于列表类的需求，HBase 有两种典型的用法，一种是高表模式，与传统的 Mysql 模式格外类似，列表中的每一项存一行，每一行有固定的属性列；另一种是宽表模式，一个列表存一行，列表中的每一项存成一个单独的列，各种属性都打包到列内部的 value 中。如图： 图 3：粉丝列表业务分别使用 HBase 高表模式和宽表模式存储示意图 高表模式的好处在于与 Mysql 类似，各种业务规律的实现也比较像，认知和改形成本较低，劣势在于由于 HBase 的实现机制导致单个列表可能被分别存储在多个不同的 Region 里，查询的功能较差。而宽表的优劣势正好与高表相反。在高并发大流量系统中，技术方案很多特性都可以妥协，但唯独功能永久是不能妥协的，所以我们选择宽表模式。 很多高并发系统都接受上行异步化，通过将操作转化为消息，写入消息队列，后台异步处理的方式来削峰填谷，并获得更好的可用性。大部分消息队列都支持单个消息被多个业务模块反复处理，并支持串联和并联。所以在这里我们将写入 HBase 的代码规律单独封装到一个模块中，将它配置为与写入旧 Mysql 代码串联或并联即可。 为了支持消息异步处理的重试机制，建议将业务模块设计成具有幂等特性，即同一条消息可以重试多次，而不会破坏最终的结果。有一些模块，如计数器，提示等，业务本身不支持重试，可以通过“反复消息检测模块”为它们供应短时间内的重试支持。大部分 Mysql 存储都通过主键或者单独的 Unique key 索引来达到幂等要求，相应的，HBase 高表模式通过主键保证，宽表模式通过 column qualifier 保证。在粉丝列表迁移过程中，由于 column qualifier 不能保证幂等，导致数据全都性无法达到要求，最终也是通过引入额外的反复消息检测模块处理。 另外，HBase 当前不供应二级索引、掩盖索引、join、order by 等 Mysql 高级查询功能，需要在迁移之前做好评估，确定新方案能够支持全部的业务特性。比如粉丝列表一般都是查询最新的 5000 个粉丝，但假如还要支持查询最后 100 个粉丝列表的功能，就会比较费劲。 上线双写完成后，需要对双写的数据进行全都性校验。数据全都性校验需要从两个维度进行：存储维度和业务维度。存储维度是指直接取 Mysql 和 HBase 里的数据进行对比；业务维度是指从最终用户看到的数据维度进行校验，即访问粉丝列表页面，看结果能否与原来全都。大型系统的数据全都性校验建议及格线是 6 个 9，即 99.9999%，也就是说每一百万条数据中，差别不能超过 1 条。 历史数据搬迁 上线双写并校验确认通过后，就可以开头搬迁历史数据了。 搬迁历史数据的步骤中，最大的困难是保证搬迁过程与线上业务写入互不干扰。对于列表类功能，最大的干扰是来自于这样一种业务场景：搬迁程序从 Mysql 中 select 出来一个列表，在插入到 HBase 之前，这个列表发生了变化。假如是添加一个元素，由于 HBase 的幂等保证，最终结果并不会产生偏差，但假如是删除一个或多个元素，那么最终会表现为 HBase 中删除操作未生效，由于线上业务执行完删除操作后，搬迁程序又执行了插入操作。本质上，这是由于我们在这样的数据量规模下不能使用事务引起的，假如引入事务，能够处理这个问题，但同时也会将搬迁耗时从几天延长到几周甚至几个月。为了处理这个问题，可以通过引入轻量级的 Memcache 锁来模仿 Serializable 级别的事务隔离。 历史数据搬迁完成后也需要进行全都性校验。实际上，建议在搬迁全量数据之前，先搬迁部分数据，并进行全都性校验。部分数据全都性校验通过后，再对全量数据进行搬迁。这种方式可以极大的节省搬迁时间，降低由于搬迁流程或代码不完善导致的延期风险。 切读 全量数据搬迁并校验完成后，即可以进行读恳求切换了。通用的切换方式是在代码中埋入开关，通过 Config Service 或类似机制进行切换操作。切换的流程为：Tcpcopy 环境 -- 线上环境 uid 白名单（内部工程师）-- 线上环境百分比灰度 0.01%，1%，10% -- 线上环境全量。tcpcopy 环境用来验证代码在线上环境能否正常，uid 白名单用来验证功能能否正常，百分比灰度用来验证功能和资源压力能否正常，全部验证都通过后，最终才进行全量切换。一般这个过程会持续一周到两周。 清理沉淀 切读完成后，整个数据迁移过程可以认为已经完成了。但项目工作并没有完结，旧的规律代码清理，旧的配套系统下线，旧资源回收，以及最重要的一个环节：阅历教训总结、共享，流程完善，工具通