您描述的用例非常狭窄。这不仅仅是“套接字或队列”的情况,但其他考虑因素必须考虑到业务案例中:
- 事物将如何被监控和管理?是否有必要编写所有向 NOC 报告系统健康状况并提供消息统计信息的部分,或者我可以使用 MQ 提供的内容吗?
- 我需要排队还是这真的是一个同步应用程序?
- 这真的是点对点的还是所涉及的应用程序参与了服务生态系统和上游/下游连接?它还需要与什么集成?
- 是否需要消息丰富、路由、扇入、扇出、发布/订阅或其他功能?写代码还是使用 WMQ/WMQ Broker 原生特性?
- 连接是否需要身份验证?加密?写代码还是使用 WMQ 原生特性?
- 是否涉及监管合规因素,如果有,审计自定义代码与 COTS 传输的成本是多少?
- 商店是否具有深厚的 C++ 技能并准备在代码的整个生命周期内保持这种深度?
- 连接配置如何管理,是否无缝支持 HA 和 DR?写代码还是使用 WMQ 原生特性?
- 如何管理异常逻辑和自动重新连接?写代码还是使用 WMQ 原生特性?
商业案例必须考虑的不仅仅是原始速度。当两种备选方案都能够满足吞吐量要求时尤其如此。一旦功能需求得到满足,商业案例中必须考虑所有这些其他方面(以及更多我没有想到的)。
至于具体问题...
以您希望的方式管理对队列的访问。多个线程竞争相同的消息,但传递给一个线程的消息不会传递给另一个线程。例外情况是消息回滚并再次可用,或者应用程序正在使用 pub/sub 并有意接收多个消息副本。
在应用程序端,调用在会话中是线程安全的。所以所有线程一起使用同一个会话COMMIT
。通常一对使用请求/回复的线程协同操作。否则,每个线程一个会话可以为您提供所需的内容。
至于性能,这是一个苹果与橘子的比较。问题是提供异步消息传输的所有服务、诊断、弹性和其他功能的 C++ 套接字程序是否与该传输一样执行。答案通常是否定的。WMQ 已经优化了 20 年,只做一件事,而且做得非常好。一个新的自定义 C++ 套接字程序将更快地移动数据,但不提供相同的功能。因此,归结为应用程序是否需要如此少的 WMQ 功能,从长远来看,自定义代码所需的少数功能会更便宜,然后在应用程序的生命周期内维护这些功能。同样,答案通常是否定的。
有关消息吞吐率的详细信息,请转到SupportPacs页面并查找名称以 MP__ 开头的那些,以获取所需的平台和版本。即使在普通的硬件上也可以实现 10k MPS 的小消息。