分布式系统数据一致性解决方案_分布式数据一致性解决方案

1.背景

微服务架构是一把双刃剑，我们在享受微服务拆分带来好处的同时，势必会遇到数据模型和服务之间不一致的问题。本文讨论的都是互联网企业在分布式架构下如何应对数据一致性问题的。

2.典型的一致性问题

案例1：下单和减库存的一致性

下单减库存有一致性的需求，如果下单了但是没减库存造成的结果是超卖；如果减库存了但下单失败会导致少卖。

案例2：缓存和数据库的数据一致性

电商系统一般会将热点数据缓存来减少数据库访问压力，这要求缓存和数据库数据是一致的，如果数据库数据发生变更但同步到缓存失败，这时就产生了缓存何数据库数据的不一致。

案例3：两系统协调的一致性

其实上面两个案例都可以归结为此案例，系统是上下游的关系，由于超时等原因可能导致两系统数据的状态不对。

3.一致性理论

ACID原理

即关系型数据库的事务特性：原子性、一致性、隔离性和持久性。ACID这里不多说，一般核心交易系统都要有强一致性的事务要求，因此在做技术选型时，核心数据基本也只考虑关系型数据库。

CAP原理

CAP其实是一种权衡平衡的思想，用于指导在系统可用性设计、数据一致性设计时做权衡取舍。CAP，即一致性、可用性、分区容忍性。一致性强调在同一时刻副本一致，可用性指的是服务在有限的时间内完成处理并响应，分区容忍性说的是分布式系统本身的特点可以独立运行并提供服务。

4.一致性协议

说到一致性协议，大家肯定都听过两阶段协议协议、三阶段提交协议、Paxos协议、Raft协议等。这里我们简单比较一下。

两阶段提交协议

两阶段提交协议，顾名思义分两个阶段：准备阶段（投票反馈阶段）和 提交阶段（执行阶段）。准备阶段参与者在本地执行事务，在本地写redo\undo log，但不提交，有点万事俱备只欠东风的态势。提交阶段由协调者发出。

两阶段协议提交存在的问题还挺多，具体包含：

1. 阻塞问题，所有参与者必须收到协调者发起的指令才会提交，否则资源会被锁定，但由于不可靠的网络，协调者可能无法收到所有反馈，参与者也可能无法接收到指令。
2. 单点故障，如果协调者宕机，参与者没有协调者指挥就会一致阻塞。
3. 数据不一致，协调者发出的指令可能导致部分参与者收到，部分参与者由于网络原因未