Transactional Outbox
交易式寄件匣
交易式寄件匣會在同一個本機資料庫交易中,保存資料變更和訊息紀錄。交易提交後,再由中繼程式送出已保存的訊息。
local transaction(business row + outbox row) -> relay/CDC -> broker -> idempotent consumerorders✓order_2048outbox✓evt_784local transaction(business row + outbox row) -> relay/CDC -> broker -> idempotent consumerJOB另一個例子
結帳會在同一個交易中保存訂單 `984` 和寄件匣事件 `OrderCreated:984`,再由中繼程式稍後發布。中繼程式若在送出後、標記紀錄前停止,可能會再次傳送。消費者要用事件 ID 去除重複。
主要部分
- 01業務資料變更
- 02寄件匣事件紀錄
- 03同一個本機交易
- 04中繼程式或變更串流
- 05訊息代理發布
- 06可安全處理重複的消費者
什麼時候用
資料庫變更提交後,必須可靠地產生訊息或事件時,可以使用交易式寄件匣。寄件匣紀錄要和資料放在同一個交易,中繼程式也要獨立可靠地運作。
什麼時候不要用
不要把它說成只會送一次,也不要說成跨服務的一次交易。仍要處理重複事件、事件順序、中繼延遲、紀錄清理和安全防重複。
程式裡的名稱
local transaction(business row + outbox row) -> relay/CDC -> broker -> idempotent consumer 上線前要檢查
檢查介面約定、任何情況都不能破壞的規則、授權與輸入限制。測試重試、重複執行只生效一次、逾時與部分失敗。驗證資料完整性、相容性、監控、復原與回復上一版。
預期成果:為這套系統設計或檢查 交易式寄件匣 (Transactional Outbox),並讓資料保持正確、安全且容易維護。 使用者情境:結帳會在同一個交易中保存訂單 `984` 和寄件匣事件 `OrderCreated:984`,再由中繼程式稍後發布。中繼程式若在送出後、標記紀錄前停止,可能會再次傳送。消費者要用事件 ID 去除重複。 技術概念或控制措施:交易式寄件匣 (Transactional Outbox)。 適用理由:資料庫變更提交後,必須可靠地產生訊息或事件時,可以使用交易式寄件匣。寄件匣紀錄要和資料放在同一個交易,中繼程式也要獨立可靠地運作。 不應使用的情況:不要把它說成只會送一次,也不要說成跨服務的一次交易。仍要處理重複事件、事件順序、中繼延遲、紀錄清理和安全防重複。 工程要求:定義輸入、輸出、介面約定,以及任何情況都不能破壞的規則。說明授權與輸入檢查範圍。定義失敗、逾時、重試和重複執行只生效一次的規則。也要定義資料搬移與相容限制。 營運要求:加入監控訊號與隱藏敏感資料的記錄。設定容量上限並寫好操作手冊。測試復原與回復上一版的流程。 驗收條件:介面約定與失敗路徑測試通過。重試或部分失敗時,資料與授權規則仍正確。效能上限、監控、復原與回復上一版的方法都已驗證。 證據與限制(證據邊界):沒有一份官方標準能管到全部內容。不同團隊、平台或框架的用法可能不同。 待確認:程式執行環境、資料位置、流量形態、資料一致需求和安全邊界。也要確認相容期間、服務目標(SLO)與回復上一版的限制。
檢查這份需求
請 AI 程式助手檢查目前如何使用 交易式寄件匣 (Transactional Outbox)。 定義:交易式寄件匣會在同一個本機資料庫交易中,保存資料變更和訊息紀錄。交易提交後,再由中繼程式送出已保存的訊息。 正式環境檢查:檢查介面約定、任何情況都不能破壞的規則、授權與輸入限制。測試重試、重複執行只生效一次、逾時與部分失敗。驗證資料完整性、相容性、監控、復原與回復上一版。 修改程式前,先列出看到的證據、缺口、嚴重程度,以及最小且安全的修正。