訂單狀態一致性維護的高魯棒性實踐——以接單系統爲例

訂單系統最難的就是一致性維護，關於狀態機，同事有很好的總結，參見：https://www.jianshu.com/c/fcf...

接單系統做爲訂單系統的後路，對一致性要求更高

接單系統特色與要求

1. TPS高，要求高併發，存在峯值流量
2. 穩定性要求高，不能漏接單，須要有較高的容錯性，接單系統依賴的任何服務短時掛掉都不該該影響接單，尤爲是在電商系統中，到接單這一步，用戶以前其實已經支付了，因此對穩定性有着異常嚴格的要求。

技術實現

1.對於高TPS要求，實現的套路是固定的。

消息中間件在工程實現中主要用來削峯，異步和解耦。接單接口的入口首先要用消息隊列來削峯，以解決峯值高流量問題。

削峯以後收到要保證消息不堆積並支持高併發，還須要作分流，接單系統須要落日誌並增刪改查業務表數據，數據庫性能就會成爲瓶頸，數據庫的分庫分表就是必須的，

消息加數據庫分庫分表基本就能知足。

2.對於穩定性要求

須要考慮到各類異常狀況。出現異常狀況要有自恢復能力，狀態機加延遲隊列再加腳本可解決問題。

爲何要有狀態機呢，接單系統的業務邏輯通常都很複雜，在接單的過程當中可能因爲各類緣由致使異常，這時候狀態機的做用就凸顯，

剛接到單，就須要數據落庫，這是狀態機的初始態。以後的業務邏輯流轉過程當中的各類可能異常狀況都須要被記錄下來，這些是狀態機的中間態，屬於異常狀況，

須要某種機制將中間態轉化爲最終態。技術要須要利用延遲隊列，若是某個訂單出現了異常，或者說出現了中間態，須要將這個異常訂單扔到延遲隊列中，待會重試，

絕大多數狀況是依賴的某個微服務短期存在不可用或者不穩定，待它穩定後須要進行重試。重試若是還有問題就再重試。

可是重試也須要有次數限制，若是有問題，不可能一直在堆在q中，這時候補償腳本的做用就顯現了 ，腳本是最後的兜底，跟常規邏輯相比，腳本須要對業務稍微有損，是次優的，

在兜底腳本中可將部分接單過程當中不重要的接口或者功能降級掉，優先保證接單的穩定。這是跟以前的延遲隊列的業務邏輯相比不一樣的地方。