什么叫异步处理？异步处理系统的好处是什么？异步处理的设计要点有哪些？
打卡Day30：今天学习了《59｜性能设计篇之“异步处理”》，我的收获如下：
典型的异步处理
- 邮递业务。会把大量的去往同一个方向的订单合并处理，并统一地调配物流交通工具。
- 程序读写文件。操作系统并不会真正同步地去操作硬盘，而是把硬盘读写请求先在内存中 hold 上一小会儿（几十毫秒），然后对这些读写请求做merge和sort。
- TCP协议向网络发包。会把数据在缓冲区累计到一定尺寸MTU。
异步系统的好处
让我们的系统可以统一调度。增加整个系统的吞吐量，从而可以面对更高的并发。
异步处理的设计
前台系统把用户发来的请求一一记录下来，在数据库或是存储上只会有追加的操作，性能会很高。
收到请求后给客户端返回“收到请求，正在处理中”。
任务处理系统来真正地处理收到的请求，任务派发器可以使用推拉结合的模型。
事件溯源 Event Sourcing
事件不可变，并且可使用只追加操作进行存储，处理事件的任务可在后台异步运行。
事件是描述已发生操作的简单对象以及描述事件代表的操作所需的相关数据。
事件不会直接更新数据存储，只会对事件进行记录，以便在合适的时间进行处理。
Event Sourcing一般会和CQRS一起提。
异步处理的分布式事务
对于分布式事务，在强一致性下，在业务层上只能做两阶段提交，而在数据层面上需要使用 Raft/Paxos 的算法。
大部分场景达到最终一致性就可以了，通过“交易凭证+异步”的方式实现。
- 凭证需要非常好地保存起来，不然会导致事务做不下去。
- 凭证处理的幂等性问题，不然在重试时就会出现多次交易的情况。
- 如果事务完成不了，需要做补偿事务处理。
异步处理的设计要点
事件驱动和事件溯源是两个比较关键的技术。
任务处理方处理完成后，给任务发起方回传状态，异步通知确保不会有漏掉的。
发起方需要有个定时任务，把超时没有回传状态的任务再重新做一遍，需要处理方支撑幂等。
异步处理的整体业务事务，如果到最后一步不能成功，那么就需要回滚走补偿事务流程。
在需要性能的时候，需要牺牲强一致性，变为最终一致性。
监控任务队列里的任务积压情况，压力大时能快速扩容避免整个系统挂掉，不能扩容就要对前端限流。
异步处理系统的本质
- 把被动的任务处理变成主动的任务处理。
- 对任务进行调度和统筹管理。