作者：高超来源：云栖社区
随着业务规模的扩张，企业系统变得越来越复杂，在这种复杂的分布式系统架构下，难免会出现远程调用失败，消息发送失败，并发 bug 等等问题，这些问题最终会导致系统间的数据一致性保障最佳实践。
离线or在线,事前or事后
应对业务数据不一致问题的常规操作是，配置定时任务，在每个固定时间点去拉取历史一段时间的数据出来进行比对，判断是否有数据故障出现，比如利用hadoop做一些批处理MapReduce作业，这种离线计算的方式时效性比较差，对于电商系统或者对于实时性要求较高的系统来说，问题发现的越晚损失也就越大，所以我们需要一种在线的校验模式来实时发现数据不一致问题。
在线的校验模式指的是每出现一笔数据就进行一次比对，这种比对方式还可以分为事前和事后比对。
事前比对是一种业务强耦合的校验方式，我们在业务系统代码中进行类似 AOP 的操作，横插一段校验代码，如果校验发现问题，则阻断这次业务操作，这种模式虽然时效性很高，能够保证每一笔数据的正确性，但是因为和业务耦合的太重，很容易出现一些灾难性的问题，比如校验代码的性能差或者异常处理不正确，会直接导致业务操作受阻，影响正常业务活动。
事后校验严格上来说不能算是实时校验，因为校验的时间点滞后于真实的业务动作发生时间点，这算是一种准实时校验，这种校验的好处在于，可以和业务解耦，不阻断业务的正常进行，还能较为"实时"的发现数据不一致问题，并且在一些特殊场景下(比如异步业务，下面会介绍)只能使用事后校验，缺点也很明显，就是时效性相比于事前校验来说会比较差。
这里在啰嗦一句，可能读到这里，有些人会问，既然是业务动作发生之后再进行校验，它的意义还有多大呢?的确相比于事前校验来说，他并不能保证每一笔数据都正确，但是在实际操作中，像电商这种场景下，我们进行业务功能迭代，会经过日常环境 -> 预发环境 -> Beta测试 -> 线上环境的流程，尤其是在预发环境和 Beta 测试的情况下，一般会进行一些线上引流或者模拟数据测试，特点是量小，即使发生问题也只是局部不会引起灾难，那在这种场景下，事后校验的意义就显得很大，可以提前验证功能和数据的正确性，又不会对线上造成强耦合的影响;在功能完全上线后，事后校验的作用在于及时发现数据不一致问题，避免问题的进一步扩散。
综上所述，对于业务数据校验时效性不是那么高的场景下，离线校验是一种比较合适的方式，开发接入成本都较低，对于业务数据校验时效性有一些要求的场景下，事后校验是一种比较适合的方式，对于业务校验时效性要求非常严格，并且能够投入较多资源的情况下，事前校验比较适合。
数据一致性检测实践案例
案例一、会员系统
某店铺会员入会业务，需要结合店铺系统、打标系统、会员系统进行入会退会操作，如下图所示: