模块 7 学习总结

模块 7 讲异地多活架构，这也是我报名架构实战营最想学习的一部分内容。不过我发现绝大多数异地多活架构都只关注数据库，虽然也需要考虑最终一致性，但同步的耗时也就在几十几百毫秒的范围内，业务上还可以通过其他日志、事务记录等进行补偿，以及直接通过算法生成数据。

但我实际工作中面临的需求有些不一样，我们是视频制作业务，涉及到大规模的二进制文件，制作团队分布在两个城市，由于对文件 IO 性能的高要求而不能跨城市使用共享存储，只能在两地分别部署本地文件存储。但同时两地又需要协作，也就是在一个城市产生的文件更新需要及时同步到另一个城市，此外还有两地公用的数据库（管理系统）对文件元数据进行管理，这样就会导致管理系统上已有文件更新信息，但文件还未同步到异地存储中，目前的办法也只能是在业务层面容忍，因为同步文件往往需要耗费几个小时，通常都是放在半夜进行。

这个需求看上去更多是关于数据同步，跟传统意义上的异地多活不太一样，异地多活的目标是应对城市级灾难，让用户访问异地机房仍能正常得到服务。而我们的需求是让制作人员无论在哪个机房（存储）上都能尽快访问到最新的、完整的文件数据，而对于管理系统来说也会选择就近为用户提供本地文件存储路径，而不是使用异地存储。而极端情况下，如果其中一处存储坏掉了，则异地存储需要顶上来，这时候传输速度会受到影响，最新的文件也可能因为未同步而丢失了，但仍能基本保证业务运转。