異步（排隊）消息傳遞和關聯的會話數據

Question

我試圖爲排隊的消息傳遞系統實現會話上下文數據。

會話處理過程如下： 前端應用程序對自身進行身份驗證並接收會話標識。 之後，會話標識被包括在消息標題中，所以消息處理程序被提供有用於例如安全檢查和審計日誌記錄。如果客戶崩潰並繼續工作，客戶可能會選擇一個會話。

所以現在我們要將鍵/值對與會話ID關聯起來。但是，如果會話數據發生變化，會產生許多併發問題，因爲消息處理程序使用的會話數據應該是發送消息時的數據。

我看到了兩個可能的解決方案：

1. 將相關的會話數據，每一個消息頭
2. 商店版本數據庫的會話數據，並在郵件標題中使用的版本號。

第一個使消息更大，第二個使會話數據庫更大並創建大量的基礎結構代碼。我必須將最新的值保存到數據庫中，所以如果客戶端崩潰或連接丟失，客戶端可能會繼續工作。

還有其他解決方案嗎？我傾向於使用第一種解決方案，但希望首先獲得一些反饋。

其他人如何處理這個問題（例如JMS/NServiceBus/Masstransit）？

根據答案更新： 我選擇了說服我的團隊成員僅在前端使用會話數據並將其放入消息中（如果消息處理程序需要）。

Answer 1

您沒有真正詳細說明爲什麼要將鍵/值對與會話概念相關聯。

來自NServiceBus和Udi Dahan關於SOA和服務邊界的建議，這種類型的會話概念往往會讓我誤以爲是錯誤的。我的感覺是，消息處理程序在很大程度上應該在時間方面相當確定。也就是說，它現在應該運行得很好，或者排隊等待一段時間，並在將來的某個時刻以完全相同的方式執行。

所以，我的建議是，出於安全考慮，如果有必要，請繼續使用消息標題。在NServiceBus中，您可以引入來自IT/Ops Service的消息處理程序，這些消息處理程序被配置爲首先在處理程序鏈中執行，驗證安全性以及與實際業務邏輯無關的東西。在這種情況下，標題信息僅影響消息是被處理還是被拒絕。

當你得到會話類型信息時，我想仔細分析這些需求並將相關的部分放入消息模式本身。

同樣，首先了解會話數據背後的動機會有所幫助。如果你編輯你的問題，也許我們可以找出你可以重新組織這些需求的方法。