您好,登录后才能下订单哦!
大数据中如何彻底解决分布式系统一致性问题,针对这个问题,这篇文章详细介绍了相对应的分析和解答,希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。
要想解决一致性问题,就要先搞明白,什么是一致性问题,一致性问题是分布式常见问题,还可以再分为最终一致性和强一致性,但通常指强一致性,书中表示"你中有我,我中有你,浑然一体";人多力量大,引申出分而治之的思想和逻辑。
水平拆分:这里所说的水平,我理解为横向的空间维度拆分,不单指数据库表的拆分和缓存的拆分,特指了池化技术,可以类比集群的概念,既:多个相同的服务部在同一个服务上。分布式既:一个服务拆分为不同的服务。
垂直拆分:"专业的人干专业的事",这样简单单一,好维护,类比设计模式的单一职责原则,设计模式的单一职责指的是引起类变的原因只有一个。
一致性指:分布式服务化系统之间的弱一致性,包括应用系统的一致性和数据的一致性。
根据这个概念也可以细分下高并发的方向,细分为数据的高并发和请求的高并发来提出解决方案。
一致性问题
案例一:下订单和扣库存
电商系统中,如何保持下订单和扣库存的操作一致性。如果先下订单扣库存失败,会出现超卖;如果下订单不成功,扣库存成功,会导致少卖。
案例二:同步调用超时
系统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。
关于大数据中如何彻底解决分布式系统一致性问题问题的解答就分享到这里了,希望以上内容可以对大家有一定的帮助,如果你还有很多疑惑没有解开,可以关注亿速云行业资讯频道了解更多相关知识。
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。