数据迁移怎么做？( 二 ) _数据迁移

关于双写的实现方法，有多种选择，每种方法都有其优缺点和适用环境。根据增量数据的来源不同，主要有增量日志订阅方案和应用层双写方案。
增量日志订阅方案中，最常见的是使用开源工具Canal来订阅主库的Mysql binlog变化，并消费binlog以获取增量数据。这种方式只适用于Mysql作为源数据库的情况。虽然也有一些方案可以支持Oracle等商业数据库的数据迁移，例如愚公等工具，但它们需要额外的物化视图权限，并且可能对性能产生影响，实际应用中使用时会有一定限制。
应用层双写方案包括应用同步双写和异步双写两种方式。应用同步双写是指应用程序同时连接两个数据源，在写入数据时同时向两个数据库中写入数据。这种方式会在一定程度上降低应用程序的性能，因为现在需要同时插入两个库，而不仅仅是一个库。此外，该方式还要求应用与两个数据库必须在相同机房或者同一可用区，否则跨网络导致的时间开销会大大增加。应用异步双写方案与同步双写的不同之处在于，第二个库的写入是异步进行的。可以通过使用消息队列的方式来实现这种异步操作。由于采用了异步双写，对应用程序的性能影响非常小。

文章插图
异步双写方案的具体实现如上图所示。在这种方案中，应用在写入数据时同时将数据写入消息队列。为了确保单个表的时序正确性，可以为每个表配置一个独立的消费者来处理消息队列中的数据。此外，为了进一步保证数据的一致性，还需要设计一个基于增量行的检查程序，该程序依赖于源表中的last_update_time字段，用于确保两个数据库之间的数据一致性。
对于换数据库与上云同时存在的需求，其实应该考虑分步去实施，即先完成一项再完成另一项，这样在上云的过程中可以利用同构数据库的主从同步方案，在换数据库过程中不需要考虑跨机房网络损耗问题带来的各种限制。
迭代的迁移策略在实际情况中，数据迁移可能需要采取迭代进行的策略。例如，在云原生重构方案中，企业可以安排一部分人员对系统进行重构，同时让另一部分人员继续在旧系统中进行需求的迭代开发。支持迭代迁移的基础是前端能够灵活地支持路由策略，即前端可以同时将部分服务路由到新环境，将其他服务路由到旧环境中。前端需要支持路由策略设计见下图：

文章插图

与异构数据库迁移策略相比，迭代迁移策略需要持续的周期。这种策略通常伴随着系统的重构，并且一般按照模块进行。为了更好地实施迭代迁移，对每个模块的迁移甚至可以将迁移过程分为两个步骤：非实时读业务的迁移和实时读写业务的迁移。
缓存的数据迁移策略在进行缓存迁移时，一般不会直接迁移缓存数据，但需要考虑缓存的预热。对于中小规模的系统，也可以直接丢弃缓存数据，让新环境的系统在运行过程中逐渐生成新的缓存。然而，在高并发环境下，为了防止新环境系统在接收流量后发生缓存击穿并导致雪崩效应，我们需要进行缓存的预热。为了使预热的数据更符合实际情况，我们可以将旧环境中一定比例的写入缓存操作异步同步给新环境的缓存服务器，从而实现预热的效果。由于新缓存的更新是异步的且按比例进行，对系统性能的影响很小。