彻底解决分布式系统一致性问题

首先本章内容参考《分布式服务架构》整理，思考和总结纯个人理解。
要想解决一致性问题，就要先搞明白，什么是一致性问题，一致性问题是分布式常见问题，还可以再分为最终一致性和强一致性，但通常指强一致性，书中表示"你中有我，我中有你，浑然一体"；人多力量大，引申出分而治之的思想和逻辑。

水平拆分：这里所说的水平，我理解为横向的空间维度拆分，不单指数据库表的拆分和缓存的拆分，特指了池化技术，可以类比集群的概念，既：多个相同的服务部在同一个服务上。分布式既：一个服务拆分为不同的服务。

垂直拆分：“专业的人干专业的事”，这样简单单一，好维护，类比设计模式的单一职责原则，设计模式的单一职责指的是引起类变的原因只有一个。

一致性指：分布式服务化系统之间的弱一致性，包括应用系统的一致性和数据的一致性。

根据这个概念也可以细分下高并发的方向，细分为数据的高并发和请求的高并发来提出解决方案。

一致性问题

    案例一：下订单和扣库存


    电商系统中，如何保持下订单和扣库存的操作一致性。如果先下订单扣库存失败，会出现超卖；如果下订单不成功，扣库存成功，会导致少卖。


    案例二：同步调用超时


    系统A调用系统B超时，A得到反馈，但无法保证B是是否完成预设功能，导致A无法反馈调用方。


    案例三：异步回调超时


    大多数支付都是做的异步回调

    A调用B，B异步通知A，但A迟迟收不到成功信息，导致无法跳到订单页面


    案例四：缓存和数据库不一致


    为了应对高并发读操作，在访问数据库之前，先加一层缓存，比如电商商品详情页面展示，那么缓存和数据库之间的数据如何保持一致性？**如果对数据有强一致性要求，不能放缓存**


    案例一共8个，这里摘出我感兴趣的4个，特别是最后一个。


    解决一致性问题的模式和思路

    根据抛出的问题，进行分析和提出解决方案。

ACID原理

原子性(Atomicity)：原子意为最小的粒子，或者说不能再分的事物。数据库事务的不可再分的原则即为原子性。组成事务的所有查询必须：要么全部执行，要么全部取消。

一致性(Consistency)：指数据的规则,在事务前/后应保持一致。

隔离性(Isolation)：简单点说，某个事务的操作对其他事务不可见的.

持久性(Durability)：当事务提交完成后，其影响应该保留下来，不能撤消。

CAP原理

C：一致性

A：可用性

P：分区容错性

任何分布式系统无法同时满足三点，淘宝双11满足的就是AP原则，zookeeper与Eureka的区别也是zookeeper满足CP，Eureka满足AP原则

BASE模型

   BA：基本可用


   S：软状态，状态可以在一段时间内不同步


   E：最终一致


   BASE思想可以解决案例一一致性问题


   那么我们是如何解决案例四中缓存与数据库的一致性问题呢？


   现在的大多数方案都是先清缓存，再写库，再更缓存的操作，但高并发带来的问题还是无法真正解决，只是出现的条件比较苛刻。

两阶段提交，三阶段提交，TCC、

两阶段提交协议：准备阶段，提交阶段

三阶段提交协议：询问阶段，准备阶段，提交阶段

    TCC协议：Try，Confirm，Cancel，先执行try，没问题执行confirm，如果出现问题执行Cancel     

    下期整理

     A保证最终一致性的模式


     1.查询模式


     2.补偿模式


     3.异步确保模式


     4.定期校对模式


     5.可靠消息模式：消息处理器的幂等性


     6.缓存一致性模式 

     B超时处理模式