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

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

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

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

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

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

一致性问题

案例一:下订单和扣库存

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

案例二:同步调用超时

系统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超时处理模式

原文发布于微信公众号 - 赵KK日常技术记录(gh_cc4c9f1a9521)

原文发表时间:2019-08-27

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券