經過簡單溝通和思考後，出了第一版設計：
1：訂單的處理模塊和後續業務處理分離，採用異步調用（簡單的話就是線程處理，也可以採用mq）。防止處理時間過長，導致第三方支付的多次回調。也要設計冪等性功能，防止重複回調。
測試人員做了一次併發測試，出現了一個問題。如下圖所示，訂單A和訂單B同時進入系統，消息推送兩條，兩條消息中當天訂單數均顯示單數是2單。正常應該是第一個消息是1單，第二個消息顯示2單。
原因分析：
訂單A進入訂單表後，接著異步調用後續業務處理模塊，最後到信息推送模塊之前，這時訂單B進來了，插入了訂單表。第一條消息推送按此時數據庫中的訂單A和訂單B進行了合計，當天成單數結果顯示成了2單。這時輪到第二個訂單的消息推送時，也是數據庫中的訂單A和訂單B，結果也顯示2單。
解決方案：
方案1：每個訂單設計業務序號（自增字段），訂單生成模塊調用後續處理時傳入當前訂單的業務序號。推送消息當天訂單數按照小於當前訂單的業務序號進行單數合計。（集群的情況下，要考慮業務序列號的生成算法，就不能是單一的自增了，比如可以用redis，方案很多）
方案2：鑑於本系統的高併發的壓力不大，可以採用時間戳的方式。直接利用訂單表的生成時間的字段。(精確到秒，當然鑑於不同的系統的併發性可以精確到毫秒級別)。下圖是方案2的示例
方案2：利用MQ。先將消息插入MQ，之後MQ的消費者進行消息接口的調用，調用成功則消費成功，如果消費失敗，按照不同的頻率重複調用，每次的調用的間隔時間逐漸延長，總共調用十次。（一個小時之內）。
目前系統運行了半年時間，還沒出現什麼問題。當然設計方案有很多，歡迎大家多提寶貴意見。
分享到:
閱讀更多 程序員的日常那些事 的文章
