本文为您介绍 SOFAStack 消息队列的适用场景，以便您更好地判断如何在业务中使用消息队列。
在互联网金融场景里，其业务涉及广泛，如支付交易、收费计息、商户结算、业务营销、会员积分、风险核查等；同时，也会涉及许多业务峰值时刻，如双 11、秒杀、周年庆等。这些活动都对分布性系统中的各项微服务应用的处理性能带来很大的挑战。
消息队列作为分布式系统中的重要组件，可以很好的应对这些场景。
下文以支付转账为场景说明消息队列如何实现以下功能：
异步解耦
分布式事务的数据一致性
削峰填谷
异步解耦
传统处理方式
最常见的一个场景是支付转账成功后，需要生成交易双方的账单，并更新用户权益，发送用户通知。传统的做法有以下两种：
串行方式
流程说明如下：
用户在支付中心，填写金额等相关信息，完成转账操作。
转账成功后，再发送请求至账单中心，生成交易双方账单。
账单生成成功后，再发送请求至权益中心，更新用户积分。
积分更新成功后，再发送请求至用户中心，发送用户通知。
并行方式
流程说明如下：
用户在支付中心，填写金额等相关信息，完成转账操作。
转账成功后，同时发送请求至账单中心、用户中心、权益中心完成相应操作。
异步解耦方式
对于用户来说，转账操作成功后，后续的账单、权益、积分等不是即时需要关注的步骤，由系统保证即可。
流程说明如下：
用户在转账页面，填写金额等相关信息，完成转账操作。
转账成功后，发送一条支付消息至消息队列。消息队列会马上返回响应给支付中心，转账完成。
下游的账单中心、权益中心、用户中心等系统订阅消息队列的支付消息，完成后续的业务流程。
异步解耦是消息队列的主要特点，其目的是减少请求响应时间和解耦。主要的适用场景是将比较耗时而且不需要即时（同步）返回结果的操作作为消息放入消息队列。同时，由于使用了消息队列，只要保证消息格式不变，消息的发送方和接收方并不需要彼此联系，也不需要受对方的影响，即解耦合。
分布式事务的数据一致性
支付的流程中，用户入口在支付中心完成，账单、权益、通知系统在其他系统完成，多个系统之间的数据需要保持最终一致。
在这样的情况下，虽然实现了系统间的解耦，上游系统不需要关心下游系统的业务处理结果；但是数据一致性不好处理，如何保证下游系统状态与支付系统状态的最终一致。此时，需要利用消息队列所提供的事务消息来实现系统间的状态数据一致性。
流程说明如下：
支付中心向消息队列发送半事务消息。
半事务消息发送成功，进入 2。
半事务消息发送失败，支付中心不进行转账，流程结束。（最终支付中心与下游系统数据一致）
支付中心开始转账流程。
转账成功，进入 3.1。
转账失败，进行 3.2。
支付中心向消息队列发送半消息状态。
3.1 提交半事务消息，产生支付成功消息，进入 4。
3.2 回滚半事务消息，未产生支付成功消息，流程结束。（最终支付中心与下游系统数据一致）
下游系统接收消息队列的支付成功的消息。
下游系统处理相关业务逻辑。（最终支付中心与下游系统数据一致）
分布式事务消息的更多详细内容请参见 消息类型。
削峰填谷
流量削峰也是消息队列的常用场景，一般在秒杀或团队抢购活动中使用广泛。
以支付场景举例，在秒杀或团队抢购活动中，由于用户请求量较大，导致流量暴增，支付中心在处理如此大量的访问流量后，下游的应用用户中心可能无法承载海量的调用量，甚至会导致系统崩溃等问题而发生漏通知的情况。
引入消息队列后，用户中心作为消费方可以根据自身应用的能力进行消息的消费，不受大流量的影响。
