数据一致性问题

Posted 2023-05-15

参考技术A 最近在整理线上问题时发现绝大部分的问题都是由于数据不一致导致的，而且这类问题往往也比较难处理，那一般数据一致性都是由哪些原因造成的呢。

问题case最多的就是分布式场景下的数据一致性问题，这也是比较难规避的的场景。

分布式数据一致性通常分为两种，一种是对实时性要求较高的一致性（同步链路一致性）； 一种是可以接受短暂不一致的场景（异步链路一致性）。

异步链路一致性问题一般有一部分主要数据与依赖数据组成，例如用户支付完成之后需要给用户发放红包，短信通知等。这种场景通常通过消息的方式来实现。消息实现最终一致性主要要考虑消息顺序、消息幂等以及事务性消息等问题。另外一种常用的方式是通过任务队列来进行重试。两种方式思路都是通过将次要系统的更新与主链路解耦开，然后通过重试的方式来达到一致性。

相比异步链路一致性问题，同步的处理起来会复杂一些。

比如经典的下单问题，下单过程中需要调用库存、优惠券等多个系统，过程中出现不一致如何处理。常见的处理方式通过两阶段提交加消息的方式来解决，即先生成不可见订单，然后依次调用库存、优惠券等系统，如果所有调用成功，将订单设置为可见；如果中间出现调用某个系统失败，这个时候会发送废单消息，各个系统通过监听废单消息做对应的反操作。可以看到同步链路是的第二阶段与异步链路的处理方式类似，只不过多了一步预先的操作。

另外一个问题与这个相反，当用户生成一笔付款单时，需要在支付平台生成一笔支付相关的单据，如果底层的支付单据成功而付款单没有成功，这个时候就会产生问题，用户可以通过线下转账成功，但是没有对应的付款单据，这个是不可接受的。也就是说付款单成功时支付单可以短暂的不成功，反过来却不行。但是系统的发起方又是从付款单开始。

单库场景出现数据不一致只能是数据的更新没有放到同一个事务中，目前我遇到的主要有两种情况。

例如在一个支付系统中，当支付完成时先更新了支付核心（paycore）的数据，在更新完支付核心之后再推进收单层数据的更新，当更新收单层时如果出现锁冲突等异常时，就会出现系统数据的不一致。

一个可选的方式是使用一个待更新的context，每个层次将要修改的数据先放到这个context中，然后最后在同一的公共模块中对所有的数据进行一次的更新操作。

另外一点值得注意的是系统的事务调用关系不要弄的太复杂，过多的事务嵌套会导致事务的边界不清，容易造成数据的不一致。如果所有的数据需要保证一致，最好只开一次事务完成所有的更新。

最开始系统设计的时候只有数据B需要更新，而系统中存在多处更新的入口。

随着业务的发展，这时数据添加的了B1，当更新B时需要同时更新B1，而往往这个时候只考虑了主要链路，而忽视了其它分支入口。因此当新增了关联数据更新时，需要去评估更新的入口来源，将更新封装起来，修改所有的更新入口。

当我们进行系统设计时，首先需要去梳理下哪些数据需要保证一致性，然后思考下会有哪些不一致的情况，分别属于什么case，然后使用对应的一些解决方案。

在分布式场景很难保证数据的一致性，即使使用了重试机制等还是会出现少量的不一致，如果这些不一致是无法接受的，那还需要使用一些核对的机制（实时核对、离线核对）来快速的发现问题，保证及时的进行人工的处理。

参考：

https://www.jianshu.com/p/1156151e20c8

redis读写一致性遇到的问题

1、最初级的缓存不一致问题以及解决方案

问题：先修改数据库，再删除缓存，如果删除缓存失败了，那么会导致数据库中是新数据，缓存中是旧数据，数据出现不一致

解决思路

先删除缓存，再修改数据库，如果删除缓存成功了，如果修改数据库失败了，那么数据库中是旧数据，缓存中是空的，那么数据不会不一致

因为读的时候缓存没有，则读数据库中旧数据，然后更新到缓存中

2、比较复杂的数据不一致问题分析

数据发生了变更，先删除了缓存，然后要去修改数据库，此时还没修改

一个请求过来，去读缓存，发现缓存空了，去查询数据库，查到了修改前的旧数据，放到了缓存中

数据变更的程序完成了数据库的修改

完了，数据库和缓存中的数据不一样了。。。。

大家可以思考下如何解决呢？