我正在尝试为排队的邮件系统实现会话上下文数据。
会话处理如下： 前端应用程序对自身进行身份验证并接收会话ID。 之后，会话id被包括在消息头中，因此为消息处理程序提供了例如上下文的上下文。安全检查和审计日志记录。如果客户崩溃并继续工作，客户可以选择一个会话。
所以现在我们想要将键/值对与会话ID相关联。但是，如果会话数据发生更改，则会产生许多并发问题，因为消息处理程序使用的会话数据应该是发送消息时的会话数据。
我看到两种可能的解决方案：
第一个使消息更大，第二个使会话数据库更大，并创建了大量的基础结构代码。我必须在两者中将最新值保存到数据库中，因此如果客户端崩溃或丢失连接，客户端可能会继续工作。
还有其他解决方案吗？我倾向于使用第一种解决方案，但希望先得到一些反馈。
其他人如何处理此问题（例如JMS / NServiceBus / Masstransit）？
根据答案更新： 我选择采取说服我的团队成员仅在前端使用会话数据并将其放入消息的路线，如果消息处理程序需要它。
答案 0 :(得分：1)
您没有真正详细说明为什么要将键/值对与会话概念相关联。
来自NServiceBus和Udi Dahan关于SOA和服务边界的建议，这种类型的会话概念往往会让我误解。我的感觉是，消息处理程序在大多数情况下应该在时间方面具有相当的确定性。也就是说，它现在应该运行得很好，或者在队列中停留一段时间，并在将来的某个时刻执行完全相同的方式。
所以，我的建议是，出于安全考虑，请继续使用邮件标头（如有必要）。在NServiceBus中，您可以从IT / Ops服务中引入消息处理程序，这些消息处理程序配置为首先在处理程序链中执行，验证安全性以及与实际业务逻辑无关的内容。在这种情况下，标题信息只会影响邮件是被处理还是被拒绝。
当您获得会话类型信息时，我想仔细分析这些要求并将相关部分放在消息模式本身中。
同样，首先要了解会话数据背后的动机是有帮助的。如果您编辑问题，也许我们可以确定一种可以重新组织这些要求的方法。