背景

公司由于業(yè)務爆發(fā)式增長，新上了許多業(yè)務系統，例如：本地生活、社區(qū)團購、旅投B2B、旅投B2C等系統；同時，由于業(yè)務系統越來越多，為了運營方便，把分銷、營銷、訂單、會員等多個業(yè)務系統公共業(yè)務，抽離出一個獨立平臺來操作，例如：統一會員、統一訂單、統一分銷等系統。

需求

基于上述的背景，我負責的電商項目要與這些中臺系統進行對接。在對接的過程中其中有一個需求是：

商城推送所有的商品到統一分銷系統，分銷系統設置相應的商品，分銷系統把設置傭金的分銷商品推送給商城，商城售賣該商品。

設計思路

• 定時任務：定時推送商城有狀態(tài)變更的商品到統一分銷中心，推送商品后，需要把推送信息記錄到推送記錄表中。

• 消息重試：如果出現推送失敗，根據相應的商品id調用重試接口進行重試，或者等待下一次定時任務推送數據。

• 確保冪等性：為了保證每一個批次的商品數據不重復，推送數據的時候都會對商品id進行去重。

• 性能：要計算出每一分鐘傳送商品的極限數量，然后根據商品總數量除以每分鐘的數量，算出第一次歷史遷移商品的時間，并合理規(guī)劃每次定時任務推送的商品數量。

可靠消息最終一致性

可靠消息最終一致性是一種分布式系統中常用的設計模式，用于在異步通信的場景下保障消息傳遞的可靠性和系統的最終一致性。以下是一種常見的可靠消息最終一致性方案的概述：

• 發(fā)送方將消息發(fā)送到消息隊列：發(fā)送方將要發(fā)送的消息寫入消息隊列，例如 Apache Kafka、RabbitMQ 等。

• 接收方從消息隊列中消費消息：接收方從消息隊列中消費消息，處理消息并更新本地狀態(tài)。

• 確認消息處理完成：接收方在處理消息后，向消息隊列發(fā)送確認消息，通知消息隊列消息已經處理完成。

• 消息隊列持久化消息：消息隊列將消息進行持久化，確保消息在存儲中不會丟失。

• 異步處理消息：接收方可能會異步處理消息，例如將消息寫入數據庫、調用其他服務等，以完成消息的實際處理邏輯。

• 處理失敗時進行重試：如果消息處理失敗，接收方可以進行重試操作，例如重新發(fā)送消息到消息隊列等。

• 使用定時任務進行消息回溯：如果消息處理失敗或者發(fā)生異常情況，可以使用定時任務或者其他方式對消息進行回溯，重新處理失敗的消息。

• 確保冪等性：在消息處理的過程中，需要確保處理邏輯是冪等的，即多次處理相同的消息產生的結果是一致的，以防止重復處理消息導致的副作用。

• 最終一致性：由于消息的處理是異步的，不同接收方可能在不同時間點處理消息，因此系統可能在瞬時出現不一致的狀態(tài)，但通過消息的重試和回溯機制，最終可以保證系統的一致性。

需要注意的是，可靠消息最終一致性方案并不是適用于所有的場景，需要根據具體的業(yè)務需求和系統架構來選擇合適的消息傳遞方式和一致性保障策略。同時，實現可靠消息最終一致性方案時，還需要考慮消息隊列的選型、消息序列化、異常處理、重試策略、消息回溯機制等細節(jié)問題，以保障系統的穩(wěn)定性和可靠性。

END

勇氣是一個人處于逆境中的光明，贈友人。

好兄弟可以點贊并關注我的公眾號“javaAnswer”，全部都是干貨。