数据一致性问题
最近在整理线上问题时发现绝大部分的问题都是由于数据不一致导致的，而且这类问题往往也比较难处理，那一般数据一致性都是由哪些原因造成的呢。
问题case最多的就是分布式场景下的数据一致性问题，这也是比较难规避的的场景。
分布式数据一致性通常分为两种，一种是对实时性要求较高的一致性（同步链路一致性）； 一种是可以接受短暂不一致的场景（异步链路一致性）。
异步链路一致性问题一般有一部分主要数据与依赖数据组成，例如用户支付完成之后需要给用户发放红包，短信通知等。这种场景通常通过消息的方式来实现。消息实现最终一致性主要要考虑消息顺序、消息幂等以及事务性消息等问题。另外一种常用的方式是通过任务队列来进行重试。两种方式思路都是通过将次要系统的更新与主链路解耦开，然后通过重试的方式来达到一致性。
相比异步链路一致性问题，同步的处理起来会复杂一些。
比如经典的下单问题，下单过程中需要调用库存、优惠券等多个系统，过程中出现不一致如何处理。常见的处理方式通过两阶段提交加消息的方式来解决，即先生成不可见订单，然后依次调用库存、优惠券等系统，如果所有调用成功，将订单设置为可见；如果中间出现调用某个系统失败，这个时候会发送废单消息，各个系统通过监听废单消息做对应的反操作。可以看到同步链路是的第二阶段与异步链路的处理方式类似，只不过多了一步预先的操作。
另外一个问题与这个相反，当用户生成一笔付款单时，需要在支付平台生成一笔支付相关的单据，如果底层的支付单据成功而付款单没有成功，这个时候就会产生问题，用户可以通过线下转账成功，但是没有对应的付款单据，这个是不可接受的。也就是说付款单成功时支付单可以短暂的不成功，反过来却不行。但是系统的发起方又是从付款单开始。
单库场景出现数据不一致只能是数据的更新没有放到同一个事务中，目前我遇到的主要有两种情况。
例如在一个支付系统中，当支付完成时先更新了支付核心（p***core）的数据，在更新完支付核心之后再推进收单层数据的更新，当更新收单层时如果出现锁冲突等异常时，就会出现系统数据的不一致。
一个可选的方式是使用一个待更新的context，每个层次将要修改的数据先放到这个context中，然后最后在同一的公共模块中对所有的数据进行一次的更新操作。
另外一点值得注意的是系统的事务调用关系不要弄的太复杂，过多的事务嵌套会导致事务的边界不清，容易造成数据的不一致。如果所有的数据需要保证一致，***只开一次事务完成所有的更新。
最开始系统设计的时候只有数据B需要更新，而系统中存在多处更新的入口。
随着业务的发展，这时数据添加的了B1，当更新B时需要同时更新B1，而往往这个时候只考虑了主要链路，而忽视了其它分支入口。因此当新增了关联数据更新时，需要去评估更新的入口来源，将更新封装起来，修改所有的更新入口。
当我们进行系统设计时，首先需要去梳理下哪些数据需要保证一致性，然后思考下会有哪些不一致的情况，分别属于什么case，然后使用对应的一些解决方案。
在分布式场景很难保证数据的一致性，即使使用了重试机制等还是会出现少量的不一致，如果这些不一致是无法接受的，那还需要使用一些核对的机制（实时核对、离线核对）来快速的发现问题，保证及时的进行人工的处理。
参考：
数据一致性是什么？
数据一致性通常指关联数据之间的逻辑关系是否正确和完整。而数据存储的一致性模型则可以认为是存储系统和数据使用者之间的一种约定。如果使用者遵循这种约定，则可以得到系统所承诺的访问结果
常用的一致性模型有：
a、严格一致性（linearizability, strict/atomic Consistency）：读出的数据始终为最近写入的数据。这种一致性只有全局时钟存在时才有可能，在分布式网络环境不可能实现。
b、顺序一致性（sequential consistency）：所有使用者以同样的顺序看到对同一数据的操作，但是该顺序不一定是实时的。
c、因果一致性（c***sal consistency）：只有存在因果关系的写操作才要求所有使用者以相同的次序看到，对于无因果关系的写入则并行进行，无次序保证。因果一致性可以看做对顺序一致性性能的一种优化，但在实现时必须建立与维护因果依赖图，是相当困难的。
d、管道一致性（PRAM/FIFO consistency）：在因果一致性模型上的进一步弱化，要求由某一个使用者完成的写操作可以被其他所有的使用者按照顺序的感知到，而从不同使用者中来的写操作则无需保证顺序，就像一个一个的管道一样。 相对来说比较容易实现。
e、弱一致性（weak consistency）：只要求对共享数据结构的访问保证顺序一致性。对于同步变量的操作具有顺序一致性，是全局可见的，且只有当没有写操作等待处理时才可进行，以保证对于临界区域的访问顺序进行。在同步时点，所有使用者可以看到相同的数据。
f、 释放一致性（release consistency）：弱一致性无法区分使用者是要进入临界区还是要出临界区， 释放一致性使用两个不同的操作语句进行了区分。需要写入时使用者acquire该对象，写完后release，acquire-release之间形成了一个临界区，提供 释放一致性也就意味着当release操作发生后，所有使用者应该可以看到该操作。
g、最终一致性（eventual consistency）：当没有新更新的情况下，更新最终会通过网络传播到所有副本点，所有副本点最终会一致，也就是说使用者在最终某个时间点前的中间过程中无法保证看到的是新写入的数据。可以采用最终一致性模型有一个关键要求：读出陈旧数据是可以接受的。
h、delta consistency：系统会在delta时间内达到一致。这段时间内会存在一个不一致的窗口，该窗口可能是因为log shipping的过程导致。
什么是数据一致性和完整性,如何保证
数据一致性通常指关联数据之间的逻辑关系是否正确和完整.而数据存储的一致性模型则可以认为是存储系统和数据使用者之间的一种约定.如果使用者遵循这种约定,则可以得到系统所承诺的访问结果常用的一致性模型有：a、严...
什么是数据一致性和完整？
数据一致性通常指关联数据之间的逻辑关系是否正确和完整，而数据存储的一致性模型则可以认为是存储系统和数据使用者之间的一种约定。
如果使用者遵循这种约定，则可以得到系统所承诺的访问结果。
数据，在计算机系统中，各种字母、数字符号的组合、语音、图形、图像等统称为数据，数据经过加工后就成为信息。
在计算机科学中，数据是指所有能输入到计算机并被计算机程序处理的符号的介质的总称，是用于输入电子计算机进行处理，具有一定意义的数字、字母、符号和模拟量等的通称。是组成地理信息系统的最基本要素，种类很多。
数据一致性的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于redis集群数据一致性、数据一致性的信息别忘了在本站进行查找喔。