如何確保照順序消費訊息
訊息亂序消費，一般指我們消費者應用程式不依照上游系統業務發生的順序，進行了業務訊息的顛倒處理，最終導致業務出錯。
固定分區
一般建議同一個業務屬性數據，都往一個分區上發送；而 kafka 的一個分區只能被一個消費者實例消費，不能被多個消費者實例消費。
| 優點 | 缺點 |
|---|---|
| 生產端實作簡單：例如 kafka 生產端，提供了按指定 key，發送到固定分區的策略 | 上游難保證嚴格順序生產：生產端對同一類業務資料需要依照順序放入同一個分區；這個在應用層還是比較的難保證，畢竟上游應用都是無狀態多實例，多機器部署，存在並發情況下執行的先後順序不可控 |
| 消費端實作也簡單：kafka 消費者預設就是單執行緒執行；不需要為了順序消費而進行程式碼改造 | 消費者處理效能會有潛在的瓶頸：消費者端單執行緒消費，只能擴展消費者應用實例來進行消費者處理能力的提升；在訊息較多的時候，會是個處理瓶頸，畢竟幹活的進程上限是 topic 的分區數。 |
| 無其它中間件依賴 | 使用場景有限制：業務資料只能指定到同一個 topic，針對某些業務屬性是一類數據，但傳送到不同 topic 場景下，則不適用了。例如訂單支付訊息，和訂單退款訊息是兩個 topic，但是對於下游算傭業務來說都是同一個訂單業務數據 |
樂觀鎖
flowchart TD
A[開始消費] --> B[查詢已有的訂單]
B --> C{訊息時間是否比已有訂單的更新時間還要新}
C -- No --> D[結束]
C -- Yes --> E[計算佣金]
E --> F[根據訂單ID和時間更新訂單]
F --> G{是否更新成功}
G -- Yes --> D
G -- No --> A