业务双活的数据切换思路设计（下）
这是学习笔记的第 2132 篇文章
前几天写了一篇关于业务双活的数据切换思路设计，我今天把下半部分补充一下。
首先整个业务的上游是流量入口，分为读流量和写流量，整体是分布式设计。
在完成数据迁移，数据同步之后，目前的流量是在“已有数据服务”侧，如果要实现服务的平滑迁移，我们可以按照这个流程来进行设计。
首先关闭两个数据服务间的数据旁路，类似下面的图。
为了描述更加清晰，我们把读流量和写流量都标识出来，方便区分理解。
所以上面步骤可以用下图来进行细化表示。
接下里我们需要把写流量逐步切换到“数据服务-new”上面，类似于下面的形式，这个时候写流量其实是写入两个数据服务中了。
当然在流量切换的过程中，势必会有一部分写流量没有完全同步过去，我们可以基于“已有数据服务”进行增量数据校正，这是一个底层的数据处理操作，而这个过程“数据服务-new”因为还没有对业务开放，这个过程是没有业务影响的。
我们接下来把读流量逐步切换过去，切换完成就是如下图所示的情况了，读写流量都切换到了新的数据服务中。
而“已有数据服务”的写流量照样是写入，这样就达到了一种“理想”的双写状态。
这个过程中可以自由进行数据流量的切换，如果发现“数据服务-new”的部分逻辑存在异常，我们可以直接把读流量切换原来的“已有数据服务”即可，然后在底层进行数据修复，满足情况之后，继续上面的步骤把流量切换过来。
这样一来，我们就可以顺利完成数据业务的整体迁移过程，在这个过程中会和开发团队进行密切的配合，迁移的很多工作不单单是DBA来处理，也需要业务的深度接入和配合，这样一来业务的稳定性和健壮性都有一定的保证。
昨天收集了一批读者的建议，我先建立一个QQ群，大家扫码来加入，我在后台做下审核。
QQ群号：763628645
QQ群二维码如下：
个人微信号：jeanron100, 添加请注明：姓名+地区+职位，否则不予通过