随着企业规模的扩大，企业系统变得越来越复杂。在这种复杂的分布式系统架构下，出现了远程调用失败、消息发送失败、并发错误等问题。将不可避免地发生。这些问题最终会导致系统间数据不一致，导致用户体验受损、用户兴趣受损，甚至平台资本损失。因此，如何持续保证系统的业务稳定性是企业非常重要的课题。本文旨在介绍一些常见业务应用场景下确保业务数据一致性的最佳实践。
离线或在线，事前或事后
处理业务数据不一致问题的正常操作是配置定时任务，在每个固定时间点提取一段时间的历史数据进行比较，判断是否有数据故障。例如，hadoop用于执行批量MapReduce操作。这种离线计算方法时效性差。对于电子商务系统或实时性要求高的系统，问题发现得越晚，损失就越大。因此，我们需要一种在线验证模式来实时发现数据不一致的问题。
在线验证模式指的是每次出现数据时的比较。这种比较模式也可以分为比较前和比较后。
先验比较是一种强业务耦合的验证方法。我们在业务系统代码中执行类似AOP的操作，并水平插入一段验证码。如果在验证中发现问题，业务操作将被阻止。虽然这种模式对时间敏感，可以保证每个数据的正确性，但由于与业务耦合太重，很容易遇到一些灾难性的问题，如验证码性能差或异常处理不正确，这将直接导致业务操作被阻塞，影响正常的业务活动。
严格来说，后验证不能被视为实时验证，因为验证的时间点滞后于实际业务行为发生的时间点。这是一个准实时验证。这种验证的优点是，它可以与业务分离，不妨碍业务的正常运行，还可以“实时”地发现不一致的数据。在某些特殊情况下(如异步业务，这将在下面描述)，只能使用后验证。缺点是显而易见的，即及时性比预先核实差。
这是一个冗长的句子。有些人可能会读到这封信，然后问，既然检查是在业务行为发生后进行的，那么它有多重要？的确，与之前的验证相比，他不能保证每个数据都是正确的，但是在实际操作中，在像电子商务这样的场景中，我们将经历业务功能迭代的日常环境-
先进的环境-
测试-
在线环境过程中，特别是在预测试环境和Beta测试的情况下，一般会进行一些在线排水或模拟数据测试，其特点是数量少，即使出现问题也不会造成灾难。在这种情况下，后测试的意义非常大，可以提前验证功能和数据的正确性，不会对在线造成很强的耦合效应。该功能完全在线后，事件后验证的功能是及时发现不一致的数据，以避免问题的进一步扩散。总之，对于业务数据验证的及时性不高、开发和访问成本较低的场景，离线验证是更合适的方法。对于对业务数据验证的及时性有一些要求的场景，事后验证是更合适的方法。对于业务验证的及时性非常严格并且可以投入更多资源的场景，事前验证更合适。
数据一致性测试的实际案例
在这个业务场景中，买方在商店会员页面上启动一个会员应用程序，并成功地向外部发送一个会员元q消息。下游业务系统根据元数据信息给用户标记标签，用户在下单时根据标签判断自己是否有权先购买。既然有会员，就会有退出。撤回还将向用户发出取消投标的元报价信息。因此，无论会员资格或退出，企业都要求商店系统的会员资格状态(会员资格或退出)必须与用户系统的标签状态(是或否)一致。一旦发现数据不一致，如果已经退出商店的用户仍然拥有用户的会员标签，用户可以购买受限商品，这将导致商业资本的损失。因此，必须有对账业务来确保数据的一致性。一旦发现数据不一致，必须通知相关人员检查数据。如有问题，应修改数据。
本案例对对账系统:的选择有以下要求
实时:必须在同一天尽快处理。
可以报警
必须支持不同的域模型。
接口调用需要一些延迟，以便下游系统可以在处理完所有进程后进行检查。
由于加入或离开俱乐部时，metaq可能会丢失或出现故障，因此无法根据此消息进行协调。
在这个业务场景中，我们可以看到业务是异步的。成员系统启动成员操作后，不能立即在用户系统上进行标记。因此，实时预验证不适合这种情况。由于当会员系统启动会员操作时，在用户系统中找不到标记状态，因此需要延迟一段时间，因此只能通过后验证来完成。
在这个场景中，我们的方法是从存储成员数据库中提取实时binlog日志数据，并将其提供给验证系统。验证系统分析日志数据并获得要标记的成员的id。延迟一段时间后，我们将进入成员系统查询成员的成员身份状态，并将一致性与日志中的状态进行比较。如果发现任何不一致，我们将发出警报。
案例2:新旧图书馆的迁移
当新老系统需要更换时，通常会涉及数据迁移。因为数据量非常大，不允许停机，所以迁移必须是一个渐进的过程。整个过程将分为两个部分。第一部分是双重写入，确保新添加数据的两侧同步。第二步是开始迁移股票数据，并缓慢地完成后台任务。在此过程中，一些字段可能不同步，更新数据可能不正常，导致数据内容不一致。因此，有必要对迁移进行数据一致性检查，并及时发现数据问题进行修订或缺陷修复。因为我们的目标是将数据迁移到新系统，所以数据验证的触发条件是新系统已经写入了数据。这里的一些人可能会问，如果旧系统的同步失败，那么新系统将不会写入数据，也不会触发验证。这里有一个检查边界的问题，也就是说，我们假设同步系统将成功同步。如果同步失败，不允许跳过，并且将一直尝试同步。因此，如果同步失败，同步将暂停，并将打印同步错误日志。这不是检查系统的问题。我们将通过同步进程或同步日志来观察这种现象。
因此，我们在这个场景中的方法是:接收新库的数据库更改的binlog日志数据，分析日志内容，并通过该数据id查询旧库的相应数据以比较数据内容。由于双重写入的存在，一段数据可能会发生多次变化。这要求我们的核查必须实时进行。否则，获得的日志数据的内容似乎是旧的(该数据已被再次更新)，导致旧数据库中的数据查询不一致。事实上，这是一场虚惊。
上海IT外包服务网 链接：http://www.linemore.com
中文
电话咨询
微信咨询
公众号
