场景
不知道大家看到数据一致性，第一时间想到的是什么? 我第一时间想到的是缓存和数据库的一致性，或者是一个数据库内的多个表的数据一致性。
关于缓存和数据库的一致性大家肯定都已经很熟悉了，无非是先改数据库还是先改缓存，分别会对应什么样的问题，我这里便不再一一赘述了。
同一个数据库内多个表的一致性也好解决，一般用事务足以。
那么这里请大家想一下，一个调用链路下来，一共十几个甚至几十个系统，如何保证他们各自系统的数据一致性。如何保证整个链路的连续性呢。
我举一个具体的场景，用户使用优惠券选择商品下单。这里面的资金流包括券资产的核销、用户实际的资金从第三方支付渠道比如支付宝、微信或者银行卡支付划拨到平台；用户确认收货后，资金根据商品的性质划分到商家、平台、推广佣金等等、用户方账单和商家方账单的更新、对应物理资金的流转，每一步都不能错，即使一分钱对不上就是资损、就是事故。
解决方案
数据量大了之后，难免会因为网络抖动、数据库抖动、云服务商抖动等原因，导致出现一些异常数据。这种情况既然无法避免，就要想办法能及时快速的排查出来，确保整个调用链路的最终一致性。想达到这样的效果，要怎么做呢？要防止这些小概率事件，只能多做冗余保护措施。
一般分为实时核对和离线核对两种思路。
实时核对
目前最常用的数据库当属MySQL，我们便以MySQL为例。通过监听MySQL产生的binlog，解析出特定类型的DML语句作为触发点来进行某些操作。比如可以将 DML语句中牵扯到的字段作为参数来发送MQ、调用RPC由接收方负责具体的业务核对逻辑。或者将表的关联规则和具体核对业务规则都写在负责实时核对的平台，解析出来后由平台进行统一的核对操作。-
离线核对
为了保证数据的准确性，还可以每日将数据库中的数据同步到HBase等离线表中，根据业务需要同步全量或者增量，然后通过写Hive SQL将多个离线表Join在一起，核对数据有无缺失、不一致。
总结
凡事必有代价，技术方案总有取舍，一般来说在比较重要尤其涉及到钱的部分，会通过实时核对和离线核对两种方案来保证数据的一致性，这背后的代价就是成本，包括离线表的储存使用成本、核对规则的编写成本、数据的同步成本等。 第一次创作，文笔略微有点生疏，请大家多多指教，一起讨论有没有更好的方式。
我是星辰与日暮之间，希望在掘金和大家一起进步成长。
本文由博客一文多发平台 OpenWrite 发布！