本以为过完年就好好写文章，因为疫情，新的需求很多。希望这次疫情能尽快过去。加油，武汉。今天我们就来说说数据库迁移。这其实很常见。比如我们想把我们机房的数据迁移到腾讯云或者阿里云等线上服务，或者有时候我们需要将一个业务拆分成多个子业务，为了降低系统的耦合度，我们通常也会选择拆库，这就需要进行数据迁移。很多公司在进行数据迁移的时候都会选择停止服务。这是一种懒惰的方法。是否可以在不停止服务的情况下进行数据迁移？今天我们就来介绍一下这个高速换胎技术，数据库迁移。这是最常见的数据迁移过程之一。一开始，我们的应用程序读写旧数据库。这个时候我们还没有开始数据迁移。紧接着，我们将有一个新的数据库。一般来说，这个时候我们会启用双写。什么是双写？它是对数据库的写操作。我们写信给旧图书馆和新图书馆。如果担心双写导致耗时增加，可以选择异步和同步的方式，但是异步必然会增加系统的复杂度，需要记录失败日志以备后期处理。第二步，我们还是读取旧数据库的数据。此时对线上业务几乎没有影响。接下来，我们就可以准备读取新数据库的数据了。为了降低影响，我们可以采取一定的灰度策略，先让一部分流量去读新库，然后慢慢扩大灰度范围。这时候所有的写请求还是双写的。一旦发现问题，可以回到第二步甚至第一步，减少对业务的影响。当服务稳定后，我们就可以去掉对旧库的写入，这样就可以完成一次数据迁移。相信很多人会问，说起来容易。那么对于历史数据，如何迁移到新的数据库呢？这里介绍两种常用的方法，一种是惰性迁移，一种是主动迁移。什么是惰性迁移？这个是从英文单词lazy翻译过来的，就是如果这行数据不用，我们就忽略，用了就迁移过来。一般我们会用一个key-value来记录哪些key被惰性迁移了。当我们更新旧表的时候，如果发现key没有被迁移，那么我们就将其写入到新表中，更新key值数据，说明key已经被迁移了。后面双写的时候，直接双写就可以了，不需要数据迁移。另一种是主动迁移。数据迁移过程中可能没有访问到某些数据。例如，用户可能几个月都没有登录。你不能因为数据迁移而丢弃他。所以我们需要对这些冷数据进行数据迁移。简单来说就是扫描数据库中的股票数据，写入到新的数据库中。综上所述，这里需要注意的是，在数据迁移过程中，如果用户频繁修改数据，可能会导致数据不一致。因此，我们一般会选择在用户活跃度较低的晚上进行数据迁移。甚至为了业务方便，也会限制用户的并发请求数，减少并发导致的数据不一致。上述解决方案对于大多数公司和企业来说已经足够了。当然，如果你的业务场景比较复杂，数据量比较大，还需要进一步分析制定迁移方案。欢迎大家关注我，一起学习，一起进步。您的支持是我继续聊天的动力。同名公众号（shachamin碎碎念）
