北京
“發布可靠只是成功了一半——真正棘手的是處理?！边@句話道破了事件驅動架構中一個常被低估的真相。圍繞事務性發件箱模式的討論，通常聚焦在如何保證事件不丟、如何原子化寫入，這沒錯。但很多人忽略了，即使事件被完美送達，后續的處理環節仍會面臨一個無法回避的對手：重復消息。
絕大部分消息中間件——包括Apache Kafka、RabbitMQ和眾多云消息服務——默認提供的都是至少一次投遞語義。也就是說，消息不會丟，但可能會送來兩次。Kafka雖然推出了精確一次語義，但它的實現依賴冪等生產者和事務API，且只在Kafka生態內部起效；一旦把數據寫出到外部數據庫，交付保障的接力棒就又回到了應用開發者手里。于是，重復消費就成了分布式系統里的默認設定。
設想一個支付消費者：它收到“付款完成”事件后，先后執行數據庫更新、發送確認郵件、提交消費位移。假設數據庫事務已經成功，服務卻在確認位移前崩潰。中間件感知不到消費完成，再次投遞同一事件。消費者毫不知情，又啟動一輪處理，導致郵件重發、庫存多次扣減、流程狀態錯亂。這不是虛構的極端場景，而是生產環境中反復出現的事故原型。
所以有人堅持：只要把發布端做扎實，配合重試和死信隊列，系統就能高枕無憂。但另一派觀點更冷峻：發布可靠只解決了上半場，下半場的消息去重容錯才是真正的深水區。后者不僅要面對消費者崩潰、網絡抖動、位移提交時機不當，還要處理部署中斷、重平衡、外部服務超時等一系列排列組合出的不確定狀態。
收件箱模式正是為了包扎這一側傷口而生。它的核心思路是在消費側維護一個處理過的消息ID列表，通過數據庫約束或冪等鍵來防止重復執行。相比依賴中間件特性，收件箱模式讓應用自己掌握“已處理”的邊界，即便消息被重發無數次，業務操作也只生效一次。這便是事件可靠處理的關鍵。
我的判斷很明確：嚴肅的事件驅動系統，發件箱和收件箱不是二選一，而是缺一不可。前者保障生產端的不丟失，后者保障消費端的冪等；一個管發，一個管收，合起來才是一套完整的可靠性閉環。任何只抱著其中一端、指望另一邊自己“不會出事”的架構，遲早會被重復消息教做人。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
