01.14 Day 30 - 性能设计篇之“异步处理”

大家好，我是 Snow Hide，作为《左耳听风》这个专栏的学员之一，这是我打卡的第 30 天，也是我第 30 次进行打卡这种操作。

今天我温习了该专栏里一篇叫《性能设计篇之“异步处理”》的文章。

关键词总结：异步处理设计（异步任务处理、前台系统、任务处理系统、Push 推模型、Pull 拉模型、Pull 的好处、推拉结合）、事件溯源（解决的问题、事件回放、事件重播、事件可变性、事件记录、结合异步处理）、异步处理分布式事务（一致性、交易凭证、注意点）、异步处理设计要点（故障导致的问题、幂等性支持、整体业务事务问题、是否适合异步处理、任务积压情况、异步处理本质）。

 

所学总结：

 

异步处理设计

异步任务处理

异步任务的处理方式。

前台系统

用于记录用户的请求，收到请求后给客户端让其知道，并让其等待至处理完毕。而我们在数据库或存储的操作上是以追加的形式，所以性能会比较的高。

任务处理系统

我们需要将任务解耦，可以借助两个模型：Push 推模型和 Pull 拉模型。

Push 推模型

将任务分发给相应的服务去处理。可以起到调用的作用，但是需要知道下游服务的工作情况。

Pull 拉模型

由处理的服务来拉取要处理的任务。

Pull 的好处

上游服务无需关心下游服务的工作状态。

推拉结合

Push 做任务调度，类似于物流将相同商品的订单合并起来打包交给下游服务让其一次处理完毕；获奖同一个用户的订单的不同商品拆成多个订单。而 Pull 则是去订阅 Push 发出的异步消息，处理相关的任务。
 

事件溯源

解决的问题

让我们看到某个数据的状态。

事件回放

在我们有流水账的时候，我们只需要回放一下相关的事件就能得到最终的数据状态。只需要追加不可修改的数据操作事件而不保存最终状态。这保留了可以启动补偿操作的完整记录和历史记录。

事件重播

当我们修改了某些逻辑之后需要做数据的修正时只需要将所有相关事件重播一边即可。

事件可变性

事件使用只追加的方式进行存储等操作。

事件记录

事件只描述以发生的操作以及其代表的操作所需的相关数据，其不会直接更新数据存储。

结合异步处理

让整个系统进行任务的统筹安排、批量处理。
 

异步处理分布式事务

一致性

现实生活中需要用到强一致性的场景并不多。

交易凭证

一个事务做 A 和 B 两件事，首先做 A 并记录下 A 操作的凭证，再通过 A 的凭证去进行 B 的操作。

注意点

• 需要保存好凭证，不然事务没办法进行；
• 凭证处理幂等性，确保在进行重试时只有一次真正的处理；
• 事务失败的时候，做补偿事务处理。

 

异步处理设计要点

事件驱动和事件溯源是两个比较关键的技术。

故障导致的问题

消息丢失，没收到通知，或通知收到了没处理。办法是任务处理完成后给发起方回传状态，确保没有遗漏。

幂等性支持

在发起方重做超时没有回传状态的任务时，需要处理的一方支持幂等性。发起方的行为类似于对账。

整体业务事务问题

在处理任务失败时，需要回滚，并进行补偿事务的流程。

是否适合异步处理

不是所有的业务都适合异步处理，特别是需要强一致性的地方。

任务积压情况

在任务积压的情况下要能快速或自动的进行扩容操作，否则可能会处理不过来并导致系统奔溃。

异步处理本质

将被动的任务处理变成主动的任务处理。

 

末了

重新总结了一下文中提到的内容：异步通讯、提高系统稳定性及容错能力、统筹任务、提高系统吞吐量、异步通讯设计、推拉结合模型‘配合事件溯源、存储事务一致性、异步处理事务一致性、最终一致性、异步处理设计要点。