系统的数据一致性到底是在说什么？我到今天才算真明白了( 五 ) _数据一致性

Eventually Consistent ，最终一致性
数据不会一直处在中间状态，就如上面的例子所说，处于中间状态的数据会有采用类似定时任务一样的补偿处理，将数据修复成正确的状态，最终数据达成一致。
重说“带来了新问题”
前文说到分布式架构解决了单体架构的一些问题，但是同时也带来了一些新的问题，这里我们着重说一下，本来不是大问题的“数据一致性”问题。前面举了一个电商系统中的经典案例：下订单与扣库存。单体架构的应用我们直接用数据库事务的ACID特性就可解决，但是采用分布式架构的系统就没有那么好解决了，我们先说一下在分布式架构下的系统是如何完成“下订单与扣库存”的，这里就不画图了直接用伪代码来展示：
public void buildOrder(OrderDto orderDto) {// 1.保存订单orderService.saveOrder(orderDto);// 2.扣除产品库存inventoryService.deductInventory(orderDto);}这步骤一保存订单是在订单系统中执行，步骤二扣除产品库存是在库存系统执行，这个下订单与扣库存两个步骤分别涉及到了两个系统，使用RPC的方式和两个系统进行交互。由于这两个步骤不是原子的，不能保持一致的话会导致很多的问题：

比如先保存订单成功，然后扣除产品库存失败，那订单就要回滚处理；
如果先扣除产品库存成功，然后保存订单失败，那库存就要回滚；
或者说先保存订单然后扣除产品库存时请求超时，其实库存已经扣除成功等等问题。

这些问题你不解决，就有可能导致产品多卖或者是产品出现少卖，不管出现哪个都会造成资损或者客诉，任何一种情况都不是我们想发生的。
由于库存系统和订单系统分别使用各自的数据库，那原先使用数据库事务的ACID特性保证数据的一致性就不能奏效了，分布式架构的系统就产生了数据一致性的问题，这种跨多个数据库的事务问题，其实就是分布式事务问题。要解决分布式架构的系统的数据一致性问题，其实就是解决分布式事务的问题。
目前业界也出现了很多分布式事务的解决方案，例如两阶段提交2PC、三阶段提交3PC、TCC还有基于可靠消息等方案，他们用不同的方案实现分布式事务，解决数据一致性的问题，这里就不再详述。