一、本地事务和分布式事务
1、本地事务
本地事务是关系型数据库中,由一组SQL组成的一个执行单元
它有一个缺点:仅支持单库事务,并不支持跨库事务
2、分布式事务
是指一个企业需要同时 *** 作多个数据库的情况下,而且必须保持ACID的特性。一般应用于微服务的多服务处理
在电商系统中,支付订单,就是一个分布式事务了
第一步:支付服务,修改支付订单状态
第二步:订单服务,订单状态修改为已支付
第三步:库存服务,减库存
第四步:积分服务,为该用户送积分
以上4个步骤,在分布式系统中,是一个整体,也就是一个分布式事务
该事务必须保证2点:
保证ACID特性
保证性能问题
二、分布式CAP定理
什么是分布式CAP定理
1、一致性(Consistency)
指数据的一致性,特指分布式系统中数据的一致性
2、可用性(Availability)
指服务的高可用,特指分布式系统中服务的高可用,某个服务瘫痪了不影响整个分布式系统的运行
3、分区容错性(Partition tolerance)
分区容错性:指网络故障,特指分布式系统中,服务之间出现了网络故障,整个分布式系统任然保持可用性和一致性
4、一句话概括
在分布式系统中,网络故障,服务瘫痪,整个系统仍然保持一致性
三、分布式CAP举例
1、张三有100元优惠券,在商城买了件衣服
2、3个问题
如何体现数据一致性?
如何体现可用性?
如何体现分区容错性?
四、什么是分区
1、在断网的情况下,2台系统变成了独立网络,各自访问不了,这种情况就是分区
在分区的情况下,如果要保持数据一致性和系统可靠性,那就是分区容错性了
五、CAP技术实现所面临的困惑
1、在分布式系统中,出现网络故障P,服务瘫痪A,整个系统的数据仍然保持一致性C(无法做到)
2、相对可以实现的方案
业界的做法是CAP,三选其二
当服务之间出现网络故障的情况下:
如何保证订单服务和卡券服务高可用?
一笔订单同时扣除100元优惠券如何实现?
3、AP
CAP牺牲一致性(AP):保证高可用(保证订单服务可以正常访问,保证卡券服务可以正常访问,是牺牲了数据的一致性。)
张三下单成功,但是不扣除100元优惠券,这种情况下,张三下订单成功后再去查看100元,居然还在。
那怎么办呢?如何解决这种问题?
一般的做法是,当网络恢复正常的情况下,订单服务重试请求卡券服务,再扣除100元优惠券。
4、CP
CAP牺牲可靠性(CP):保证数据一致性,即为了保证数据的强一致性,当张三来下订单的时候,提示“系统维护中”。等服务间的网络恢复正常后,张三再来下订单。
5、不要P,只留CA
不要P分区,即不允许网络出现故障,这是不可能实现的。
所以在分布式系统中,是不存在CA的。
即使单体系统也做不到CA,因为单体系统也会出现单一故障。
六、zookeeper的CAP定理
zookeeper选了CP
1、zookeeper是CP的原理,即保证了数据一致性,牺牲了可用性
zk的数据同步原理:
client1注册给了server1,server1同步给了server2,server2广播同步给各个follower,为了保证数据的一致性,只有这整个过程都成功了,client1才收到注册成功。
2、牺牲可用性说明
当leader重启或网络故障的情况下,整个zk就会重新选举leader,在选举期间,client是不能注册的,即zk不可用,所以牺牲了可用性。
3、zk重新选举后
只有等到整个系统选举成功后,系统才恢复注册,故zk为了保证数据一致性,牺牲了可靠性。
CP有一个致命的缺点,就是在大型分布式系统中,网络是非常复杂的,leader出现了故障的频率是非常高的,而且很容易引发雪崩。所以很多大型分布式系统都不选zk的原因。
七、eureka的CAP定理
eureka选了AP
1、eureka是AP原理,即保证可用性,牺牲了一致性
eureka的数据同步原理:
client1注册给了server1,server1直接告诉client成功。剩下的就是server1同步给server2,为了保证服务的可用性,他们都是异步同步的。
八、CAP定理常见面试题
如果你的简历有写dubbo或springcloud,那面试官一般就会问你CAP定理了。
1、请说说什么是分布式CAP定理?
2、一般还会细问什么是分区容错性?因为这个是CAP的核心。
3、zookeeper和eureka的CAP区别?
4、你们公司的分布式架构是怎么做的?哪些服务设计成了CP,哪些设计成了AP?
九、分布式BASE定理
先有CAP定理,再有BASE定理。
1、什么是BASE定理
BASE是Basically Available(基本可用)、Soft state(软状态)和Eventually consistent(最终一致性)三个短语的缩写。
BASE理论是由eBay架构师提出的。
BASE定理是CAP中一致性和可用性的权衡结果,它来自于大规模互联网分布式系统的实践总结,是基于CAP定理逐步演化而来的。
2、BASE定理的核心思想
即使无法做到强一致性,但是每个应用可以根据自身的业务特点,采用合适的方法来达到最终一致性。
3、什么是基本可用
CAP中可用是高可用,BASE定理中可用是基本可用
(1)第一个概念:损失响应时间
例子:访问商品服务,如果是读取redis是10ms,如果redis瘫痪,响应时间变成了1-2秒
CAP可用性的服务响应时间可能是10ms,而BASE基本可用性的响应时间是1-2s,即允许损失部分可用性的(时间上的损失)。
(2)第二个概念:损失系统功能
例子:访问聚合服务,此时商品服务瘫痪了。采用服务降级来保证用户的体验性。服务降级,通过降级接口,返回一批热门的商品列表数据给用户。
BASE的基本可用性是允许某个服务出现故障时,采用了服务降级等手段保证用户的体验性,即允许损失部分系统功能。
4、什么是软状态
(1)什么是硬状态
指ACID的原子性。
例子:硬状态只有在订单改状态、积分发送成功、仓库出单成功,即3者同时成功的情况下,才算支付成功。
(2)什么是软状态
不用完全符合ACID的原子性。
例子:先把订单状态改成已支付成功,然后告诉用户已经支付成功了。剩下再异步发送MQ消息通知积分服务和仓库服务。即使消费失败,MQ消息也会重新发送(重试)。
5、什么是最终一致性
(1)什么是强一致性
指ACID的原子性,和硬状态一样
(2)什么是最终一致性
和强一致性相反,数据不用即时一致。如何实现最终一致性。一般是通过异步来实现,失败了就重试。在不影响用户体验的情况下,可以延时,即使失败了采用重试处理。
例子:MQ第一次失败,重发第二次失败,会一直重试,直到成功
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)