應用場景
本文為您介紹 SOFAStack 消息隊列的適用場景，以便您更好地判斷如何在業(yè)務中使用消息隊列。
在互聯(lián)網(wǎng)金融場景里，其業(yè)務涉及廣泛，如支付交易、收費計息、商戶結(jié)算、業(yè)務營銷、會員積分、風險核查等；同時，也會涉及許多業(yè)務峰值時刻，如雙 11、秒殺、周年慶等。這些活動都對分布性系統(tǒng)中的各項微服務應用的處理性能帶來很大的挑戰(zhàn)。
消息隊列作為分布式系統(tǒng)中的重要組件，可以很好的應對這些場景。
下文以支付轉(zhuǎn)賬為場景說明消息隊列如何實現(xiàn)以下功能：
異步解耦
分布式事務的數(shù)據(jù)一致性
削峰填谷
異步解耦
傳統(tǒng)處理方式
最常見的一個場景是支付轉(zhuǎn)賬成功后，需要生成交易雙方的賬單，并更新用戶權(quán)益，發(fā)送用戶通知。傳統(tǒng)的做法有以下兩種：
串行方式
流程說明如下：
用戶在支付中心，填寫金額等相關(guān)信息，完成轉(zhuǎn)賬操作。
轉(zhuǎn)賬成功后，再發(fā)送請求至賬單中心，生成交易雙方賬單。
賬單生成成功后，再發(fā)送請求至權(quán)益中心，更新用戶積分。
積分更新成功后，再發(fā)送請求至用戶中心，發(fā)送用戶通知。
并行方式
流程說明如下：
用戶在支付中心，填寫金額等相關(guān)信息，完成轉(zhuǎn)賬操作。
轉(zhuǎn)賬成功后，同時發(fā)送請求至賬單中心、用戶中心、權(quán)益中心完成相應操作。
異步解耦方式
對于用戶來說，轉(zhuǎn)賬操作成功后，后續(xù)的賬單、權(quán)益、積分等不是即時需要關(guān)注的步驟，由系統(tǒng)保證即可。
流程說明如下：
用戶在轉(zhuǎn)賬頁面，填寫金額等相關(guān)信息，完成轉(zhuǎn)賬操作。
轉(zhuǎn)賬成功后，發(fā)送一條支付消息至消息隊列。消息隊列會馬上返回響應給支付中心，轉(zhuǎn)賬完成。
下游的賬單中心、權(quán)益中心、用戶中心等系統(tǒng)訂閱消息隊列的支付消息，完成后續(xù)的業(yè)務流程。
異步解耦是消息隊列的主要特點，其目的是減少請求響應時間和解耦。主要的適用場景是將比較耗時而且不需要即時（同步）返回結(jié)果的操作作為消息放入消息隊列。同時，由于使用了消息隊列，只要保證消息格式不變，消息的發(fā)送方和接收方并不需要彼此聯(lián)系，也不需要受對方的影響，即解耦合。
分布式事務的數(shù)據(jù)一致性
支付的流程中，用戶入口在支付中心完成，賬單、權(quán)益、通知系統(tǒng)在其他系統(tǒng)完成，多個系統(tǒng)之間的數(shù)據(jù)需要保持最終一致。
在這樣的情況下，雖然實現(xiàn)了系統(tǒng)間的解耦，上游系統(tǒng)不需要關(guān)心下游系統(tǒng)的業(yè)務處理結(jié)果；但是數(shù)據(jù)一致性不好處理，如何保證下游系統(tǒng)狀態(tài)與支付系統(tǒng)狀態(tài)的最終一致。此時，需要利用消息隊列所提供的事務消息來實現(xiàn)系統(tǒng)間的狀態(tài)數(shù)據(jù)一致性。
流程說明如下：
支付中心向消息隊列發(fā)送半事務消息。
半事務消息發(fā)送成功，進入 2。
半事務消息發(fā)送失敗，支付中心不進行轉(zhuǎn)賬，流程結(jié)束。（最終支付中心與下游系統(tǒng)數(shù)據(jù)一致）
支付中心開始轉(zhuǎn)賬流程。
轉(zhuǎn)賬成功，進入 3.1。
轉(zhuǎn)賬失敗，進行 3.2。
支付中心向消息隊列發(fā)送半消息狀態(tài)。
3.1 提交半事務消息，產(chǎn)生支付成功消息，進入 4。
3.2 回滾半事務消息，未產(chǎn)生支付成功消息，流程結(jié)束。（最終支付中心與下游系統(tǒng)數(shù)據(jù)一致）
下游系統(tǒng)接收消息隊列的支付成功的消息。
下游系統(tǒng)處理相關(guān)業(yè)務邏輯。（最終支付中心與下游系統(tǒng)數(shù)據(jù)一致）
分布式事務消息的更多詳細內(nèi)容請參見 消息類型。
削峰填谷
流量削峰也是消息隊列的常用場景，一般在秒殺或團隊搶購活動中使用廣泛。
以支付場景舉例，在秒殺或團隊搶購活動中，由于用戶請求量較大，導致流量暴增，支付中心在處理如此大量的訪問流量后，下游的應用用戶中心可能無法承載海量的調(diào)用量，甚至會導致系統(tǒng)崩潰等問題而發(fā)生漏通知的情況。
引入消息隊列后，用戶中心作為消費方可以根據(jù)自身應用的能力進行消息的消費，不受大流量的影響。
