通过这种方法来保证数据不被意外修改的优势在于它是普遍适用的，不管提供存储服务的是数据库或者其他类型的存储组件，只要进程停了数据就不可能被修改。

但是这种处理方法的限制也是很明显的，首先就是应用可以随意重启。其次是在分布式环境下面，需要具备批量的启动或者关闭应用程序，以及修改操作系统定时任务的能力，不管是基于Ansible或者其他方式。除此以外也需要确保生产环境中应用程序和脚本的统计是正确的，也就是说所有应用程序和脚本都是运维和开发共同知晓的。例如运维为了短时间方便，编写脚本作用在生产环境的数据而不被其他同事所了解，那在停止应用的时候自然也不会被考虑到。

总结来说，结束应用程序的方式适合应用可以各自独立启停，且生产环境应用、脚本和数据库定时任务都完全统计清楚明确的情况下使用。

→ ACL网络隔离

通过ACL网络对数据存储服务做隔离是一个操作上相对比较简单的方法。简单来说，就是在网络环境上配置ACL，允许数据同步服务连接存储并且禁止其它应用主机连接。这种方法的优势在于规则的套用和解除都相对简单，在数据同步时直接对整个VPC子网生效，在割接时候只需要在控制台上解除，从而对整个VPC子网的存储服务做到批量控制。而且相比于数据库只读和结束应用进程这两种方法，通过网络ACL进行隔离则不用依赖于运维团队对全系统所有细节的掌握，对所有基于网络的存储服务进行覆盖，可以说完全具备了前面两种数据一致性保护方式的优点。

当然ACL网络隔离的方法也有它的适用场景限制。其中最主要的是这种方式的实施要求运维团队对各个子网的功能划分是清晰明确的，网络入口、业务应用和数据存储分别在不同的子网，所以如果应用习惯了大二层的部署方式，那么网络ACL的批量管理优势就会大打折扣。其次，由于对应用的网络中断，因此对于没有重连机制的应用，网络重新开通后依然需要重启应用。最后，这一方法对于不连网络的应用是无法限制的，例如云硬盘本地存储，这种情况需要以挂载云硬盘的主机为单位去考虑网络隔离。

经过对上面三种保障数据一致性方法的对比，可以发现这三种方法其实并没有相互冲突的点，在实际中我们可以灵活组合来匹配更多业务环境的要求，例如同时使用结束应用进程和ACL网络隔离。

【案例】

在XX公司的跨云迁移任务中，我们在前期调研中发现了几个问题。首先是数据库实例数量众多，源库和目标库既有自建的也有云平台产品，具体操作方式各有差异；其次是数据存储服务种类众多，除了MySQL以外，还有MongoDB、SQL Server、NFS存储、Elastic Search等，逐个组件去设计读写-只读切换的逻辑需要运维人员很大的精力投入。另一方面，由于目标系统对存储和应用有比较好的网段划分，虽然组件众多，但是至少都在相同子网内，适合使用ACL来隔离。最后，由于应用层面没有读写-只读的切换开关，也没有实现重连机制。

所以，在实际操作过程中，我们推荐客户使用了结束应用进程和ACL网络隔离的双重保险，因为应用不具备重连实现的情况下，割接测试前应用至少需要重启一次，ACL和结束应用的限制都会被接受。与此同时，ACL隔离也补充了结束应用的覆盖面，从网络层面保障不会有数据同步组件以外的系统连接到数据存储层面来进行操作。

数据割接阶段

不管是整体割接，还是以业务模块为单位的割接，时间窗口大小总是有限的，而且从业务角度也希望割接窗口越小越好。

1、数据校验时机

数据校验最早应该在完成数据规整阶段后才启动，这一点应该是可以简单理解的，因为数据规整前的数据不用作割接后投产，没有校验价值。而在前面数据校验章节中提到，数据校验分为两种，一种是sync_diff_inspector这类实体数据校验，另一种是select max(id)这类元数据校验，两种方法并不冲突，在实际任务中可以灵活安排来减少对割接时间窗口的压力。