软件工程常见术语概念

用户3448045726722
245 阅读13分钟

  • 原子操作

"原子操作(atomic operation)是不需要synchronized"，这是多线程编程的老生常谈了。
所谓原子操作是指不会被[线程调度]机制打断的操作；这种操作一旦开始，就一直运行到结束，
中间不会有任何 context switch [1][ ]() （切换到另一个线程）。

  • 补偿事务

事务的逆操作序列。用于恢复时撤销该事务的运行对数据库产生的影响。

  • 幂等

幂等（idempotent、idempotence）是一个数学与计算机学概念，常见于[抽象代数]中。

在编程中一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。
幂等函数，或幂等方法，是指可以使用相同参数重复执行，并能获得相同结果的函数。
这些[函数]不会影响系统状态，也不用担心重复执行会对系统造成改变。
例如，“setTrue()”函数就是一个幂等函数,无论多次执行，其结果都是一样的
更复杂的操作幂等保证是利用唯一交易号(流水号)实现。

  • MQ生产消费消息幂等

为了防止消息重复消费导致业务处理异常，消息队列RocketMQ版的消费者在接收到消息后，
有必要根据业务上的唯一Key对消息做幂等处理。本文介绍消息幂等的概念、适用场景以及处理方法。

## 什么是消息幂等
当出现消费者对某条消息重复消费的情况时，重复消费的结果与消费一次的结果是相同的，
并且多次消费并未对业务系统产生任何负面影响，那么这整个过程就可实现消息幂等。

例如，在支付场景下，消费者消费扣款消息，对一笔订单执行扣款操作，扣款金额为100元。
如果因网络不稳定等原因导致扣款消息重复投递，消费者重复消费了该扣款消息，但最终的业务结果是只扣款一次，
扣费100元，且用户的扣款记录中对应的订单只有一条扣款流水，不会多次扣除费用。
那么这次扣款操作是符合要求的，整个消费过程实现了消费幂等。

## 适用场景
在互联网应用中，尤其在网络不稳定的情况下，消息队列RocketMQ版的消息有可能会出现重复。
如果消息重复会影响您的业务处理，请对消息做幂等处理。

消息重复的场景如下：
-   发送时消息重复
    当一条消息已被成功发送到服务端并完成持久化，此时出现了网络闪断或者客户端宕机，导致服务端对客户端应答失败。 
    如果此时生产者意识到消息发送失败并尝试再次发送消息，消费者后续会收到两条内容相同并且Message ID也相同的消息。

-   投递时消息重复
    消息消费的场景下，消息已投递到消费者并完成业务处理，当客户端给服务端反馈应答的时候网络闪断。
    为了保证消息至少被消费一次，消息队列RocketMQ版的服务端将在网络恢复后再次尝试投递之前已被处理过的消息，
    消费者后续会收到两条内容相同并且Message ID也相同的消息。

-   负载均衡时消息重复（包括但不限于网络抖动、Broker重启以及消费者应用重启）
    当消息队列RocketMQ版的Broker或客户端重启、扩容或缩容时，会触发Rebalance，此时消费者可能会收到重复消息。

## 处理方法
因为不同的Message ID对应的消息内容可能相同，有可能出现冲突（重复）的情况，所以真正安全的幂等处理，
不建议以Message ID作为处理依据。最好的方式是以业务唯一标识作为幂等处理的关键依据，
而业务的唯一标识可以通过消息Key设置。

以支付场景为例，可以将消息的Key设置为订单号，作为幂等处理的依据。

消费者收到消息时可以根据消息的Key，即订单号来实现消息幂等

  • 事务的四个属性ACID

把多条语句作为一个整体进行操作的功能，被称为数据库事务。数据库事务可以确保该事务范围内的所有操作都可以全部成功或者全部失败。

事务具有 4 个属性：原子性、一致性、隔离性、持久性。这四个属性通常称为 ACID 特性。

  • Atomicity（原子性）：一个事务中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被恢复到事务开始前的状态，就像这个事务从来没有执行过一样。

  • Consistency（一致性）：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。完整性包括外键约束、应用定义的等约束不会被破坏。

  • Isolation（隔离性）：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。

  • Durability（持久性）：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。 假如我们的业务系统不复杂，可以在一个数据库、一个服务内对数据进行修改，完成转账，那么，我们可以利用数据库事务，保证转账业务的正确完成。

  • 数据库事务一致性

数据库一致性的解决降低代码层面实现一致性的灾难

CAP的一致性是指线性一致性，主要描述了在故障和延时下的副本之前的协同问题。

一致性哈希是为了解决分布式缓存问题。

分布式多副本一致性则是保持分布式系统中各个节点之间的数据一致。

  • 数据库一致性，是一种约束，方法比如 CASCADE（父表更新同步更新子表）、trigger

  • 若已对数据库库存场景非0执行update，数据报错这是执行了一致性管理。但仅此而已，比如飞天茅台超卖（同时多人对数据库库存减一，动作被另外一个用户操作覆盖的事故），这里的一致性应由程序兜底实现。

  • 那如何解决数据库一致性，用各种锁解决 悲观锁（select xxx from xxx for update）、乐观锁(mvcc，select xxx from xxx lock in share mode)等

  • 分布式事务BASE理论

    • 基本业务可用性（Basic Availability）
    • 柔性状态（Soft state）
    • 最终一致性（Eventual consistency）

  • 分布式事务的解决方案1 - 两阶段提交/XA

XA是由X/Open组织提出的分布式事务的规范，XA规范主要定义了(全局)事务管理器(TM)和(局部)资源管理器(RM)之间的接口。本地的数据库如mysql在XA中扮演的是RM角色

XA一共分为两阶段：

第一阶段（prepare）：即所有的参与者RM准备执行事务并锁住需要的资源。参与者ready时，向TM报告已准备就绪。
第二阶段 (commit/rollback)：当事务管理者(TM)确认所有参与者(RM)都ready后，向所有参与者发送commit命令。
目前主流的数据库基本都支持XA事务，包括mysql、oracle、sqlserver、postgre

XA 事务由一个或多个资源管理器（RM）、一个事务管理器（TM）和一个应用程序（ApplicationProgram）组成。

这里的RM、TM、AP三个角色是经典的角色划分，会贯穿后续Saga、Tcc等事务模式。 如果有任何一个参与者prepare失败，那么TM会通知所有完成prepare的参与者进行回滚。

XA事务的特点是：

  • 简单易理解，开发较容易
  • 对资源进行了长时间的锁定，并发度低

进一步研究XA，go语言以及PHP、Python、Java、C#、Node等都可参考DTM

  • 分布式事务的解决方案2 - SAGA

Saga是这一篇数据库论文sagas提到的一个方案。其核心思想是将长事务拆分为多个本地短事务，由Saga事务协调器协调，如果正常结束那就正常完成，如果某个步骤失败，则根据相反顺序一次调用补偿操作。

Saga一旦到了Cancel阶段，那么Cancel在业务逻辑上是不允许失败了。如果因为网络或者其他临时故障，导致没有返回成功，那么TM会不断重试，直到Cancel返回成功。

Saga事务的特点：

  • 并发度高，不用像XA事务那样长期锁定资源
  • 需要定义正常操作以及补偿操作，开发量比XA大
  • 一致性较弱，对于转账，可能发生A用户已扣款，最后转账又失败的情况

论文里面的SAGA内容较多，包括两种恢复策略，包括分支事务并发执行，我们这里的讨论，仅包括最简单的SAGA

SAGA适用的场景较多，长事务适用，对中间结果不敏感的业务场景适用

进一步研究SAGA，可参考DTM，里面包括了SAGA成功、失败回滚的例子，还包括各类网络异常的处理。

  • 分布式事务的解决方案3 - TCC

关于 TCC（Try-Confirm-Cancel）的概念，最早是由 Pat Helland 于 2007 年发表的一篇名为《Life beyond Distributed Transactions:an Apostate’s Opinion》的论文提出。

TCC分为3个阶段

  • Try 阶段：尝试执行，完成所有业务检查（一致性）, 预留必须业务资源（准隔离性）
  • Confirm 阶段：确认执行真正执行业务，不作任何业务检查，只使用 Try 阶段预留的业务资源，Confirm 操作要求具备幂等设计，Confirm 失败后需要进行重试。
  • Cancel 阶段：取消执行，释放 Try 阶段预留的业务资源。Cancel 阶段的异常和 Confirm 阶段异常处理方案基本上一致，要求满足幂等设计。

把上面的转账作为例子，通常会在Try里面冻结金额，但不扣款，Confirm里面扣款，Cancel里面解冻金额

TCC的Confirm/Cancel阶段在业务逻辑上是不允许返回失败的，如果因为网络或者其他临时故障，导致不能返回成功，TM会不断的重试，直到Confirm/Cancel返回成功。

TCC特点如下：

  • 并发度较高，无长期资源锁定。
  • 开发量较大，需要提供Try/Confirm/Cancel接口。
  • 一致性较好，不会发生SAGA已扣款最后又转账失败的情况
  • TCC适用于订单类业务，对中间状态有约束的业务

进一步研究TCC，可参考DTM

  • 分布式事务的解决方案4 - 本地消息表

本地消息表这个方案最初是 ebay 架构师 Dan Pritchett 在 2008 年发表给 ACM 的文章。设计核心是将需要分布式处理的任务通过消息的方式来异步确保执行。

写本地消息和业务操作放在一个事务里，保证了业务和发消息的原子性，要么他们全都成功，要么全都失败。

容错机制：

  • 扣减余额事务 失败时，事务直接回滚，无后续步骤
  • 轮序生产消息失败， 增加余额事务失败都会进行重试

本地消息表的特点：

  • 长事务仅需要分拆成多个任务，使用简单
  • 生产者需要额外的创建消息表
  • 每个本地消息表都需要进行轮询
  • 消费者的逻辑如果无法通过重试成功，那么还需要更多的机制，来回滚操作

适用于可异步执行的业务，且后续操作无需回滚的业务

  • 事务消息

在上述的本地消息表方案中，生产者需要额外创建消息表，还需要对本地消息表进行轮询，业务负担较重。阿里开源的RocketMQ 4.3之后的版本正式支持事务消息，该事务消息本质上是把本地消息表放到RocketMQ上，解决生产端的消息发送与本地事务执行的原子性问题。

事务消息发送及提交：

  • 发送消息（half消息）
  • 服务端存储消息，并响应消息的写入结果
  • 根据发送结果执行本地事务（如果写入失败，此时half消息对业务不可见，本地逻辑不执行）
  • 根据本地事务状态执行Commit或者Rollback（Commit操作发布消息，消息对消费者可见）

补偿流程：

对没有Commit/Rollback的事务消息（pending状态的消息），从服务端发起一次“回查”
Producer收到回查消息，返回消息对应的本地事务的状态，为Commit或者Rollback
事务消息方案与本地消息表机制非常类似，区别主要在于原先相关的本地表操作替换成了一个反查接口

事务消息特点如下：

  • 长事务仅需要分拆成多个任务，并提供一个反查接口，使用简单
  • 消费者的逻辑如果无法通过重试成功，那么还需要更多的机制，来回滚操作

适用于可异步执行的业务，且后续操作无需回滚的业务

进一步研究事务消息，可参考DTM，也可以参考Rocketmq

  • 最大努力通知

发起通知方通过一定的机制最大努力将业务处理结果通知到接收方。具体包括：

有一定的消息重复通知机制。因为接收通知方可能没有接收到通知，此时要有一定的机制对消息重复通知。
消息校对机制。如果尽最大努力也没有通知到接收方，或者接收方消费消息后要再次消费，此时可由接收方主动向通知方查询消息信息来满足需求。
前面介绍的的本地消息表和事务消息都属于可靠消息，与这里介绍的最大努力通知有什么不同？

可靠消息一致性，发起通知方需要保证将消息发出去，并且将消息发到接收通知方，消息的可靠性关键由发起通知方来保证。

最大努力通知，发起通知方尽最大的努力将业务处理结果通知为接收通知方，但是可能消息接收不到，此时需要接收通知方主动调用发起通知方的接口查询业务处理结果，通知的可靠性关键在接收通知方。

解决方案上，最大努力通知需要：

  • 提供接口，让接受通知放能够通过接口查询业务处理结果
  • 消息队列ACK机制，消息队列按照间隔1min、5min、10min、30min、1h、2h、5h、10h的方式，逐步拉大通知间隔 ，直到达到通知要求的时间窗口上限。之后不再通知

最大努力通知适用于业务通知类型，例如微信交易的结果，就是通过最大努力通知方式通知各个商户，既有回调通知，也有交易查询接口

参考

avatar
文章
阅读
粉丝