分布式概念:分布式事务(通过分布式消息来确保事务最终一致性)

分布式事务,就是在分布式系统中运行的事务,由多个本地事务组合而成。
例子:
对于网上购物的每一笔订单来说,电商平台一般都会有两个核心步骤:一是订单业务采取下订单操作,二是库存业务采取减库存操作。
通常,这两个业务会运行在不同的机器上,甚至是运行在不同区域的机器上。
针对同一笔订单,当且仅当订单操作和减库存操作一致时,才能保证交易的正确性。也就是说一笔订单,只有这两个操作都完成,才能算做处理成功,否则处理失败。

事务的特征 ACID特征:
原子性(Atomicity):全部执行成功和全部不执行。
一致性(Consistency):是指事务操作前和操作后,数据的完整性保持一致或满足完整性约束。如转账,A-200, B+200.
隔离性(Isolation):指当系统内有多个事务并发执行时,多个事务不会相互干扰.
持久性(Durability):指一个事务完成了,那么它对数据库所做的更新就被永久保存下来了.

Base理论
基本可用(Basically Available):分布式系统出现故障的时候,允许损失一部分功能的可用性。
柔性状态(Soft State):在柔性事务中,允许系统存在中间状态,且这个中间状态不会影响系统整体可用性。
最终一致性(Eventual Consistency):事务在操作过程中可能会由于同步延迟等问题导致不一致,但最终状态下,数据都是一致的。

该理论的一个关键点就是采用最终一致性代替强一致性。

实现分布式事务有以下 3 种基本方法
基于 XA 协议的二阶段提交协议方法;
核心思想:
系统中的事务管理器作为协调者,负责各个本地资源的提交和回滚,资源管理器是分布式事务的参与者;通过投票阶段和提交阶段,协调事务的操作,保持数据的一致性。
缺点:同步阻塞、单点故障、数据不一致、性能低。

三阶段提交协议方法;

缺点:
2PC 和 3PC 这两种方法,有两个共同的缺点,一是都需要锁定资源,降低系统性能;二是,没有解决数据不一致的问题。因此,便有了通过分布式消息来确保事务最终一致性的方案。

基于消息的最终一致性方法

引入了一个消息中间件(Message Queue,MQ),用于在多个应用之间进行消息传递。
核心思想:将事务通过消息或日志方式来异步执行,消息或日志可以保存到本地文件、数据库或消息队列中,再通过业务规则进行失败重试。
特点:最终一致性  异步执行  无同步阻塞问题   无单点故障问题  性能高  
缺点:算法复杂度高

以网上购物为例。假设用户 A 在某电商平台下了一个订单,需要支付 50 元,发现自己的账户余额共 150 元,就使用余额支付,支付成功之后,订单状态修改为支付成功,然后通知仓库发货。
在该事件中,涉及到了订单系统、支付系统、仓库系统,这三个系统是相互独立的应用,通过远程服务进行调用。

用户 A 通过终端手机首先在订单系统上操作流程如下:

1.订单系统把订单消息发给消息中间件,消息状态标记为“待确认”。
2.消息中间件收到消息后,进行消息持久化操作,即在消息存储系统中新增一条状态为“待发送”的消息。
3.消息中间件返回消息持久化结果(成功 / 失败),订单系统根据返回结果判断如何进行业务操作。失败,放弃订单,结束(必要时向上层返回失败结果);成功,则创建订单
4.订单操作完成后,把操作结果(成功 / 失败)发送给消息中间件
5.消息中间件收到业务操作结果后,根据结果进行处理:失败,删除消息存储中的消息,结束;成功,则更新消息存储中的消息状态为“待发送(可发送)”,并执行消息投递。
6.如果消息状态为“可发送”,则 MQ 会将消息发送给支付系统表示已经创建好订单,需要对订单进行支付
7.支付系统也按照上述方式进行订单支付操作。订单系统支付完成后,会将支付消息返回给消息中间件,中间件将消息传送给订单系统。订单系统再调用库存系统,进行出货操作

©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页