我使用Websphere MQ，它默认带有“基于文件的队列”。因此，每个队列通常在磁盘上有一个物理文件。
因此，对于这个Websphere MQ队列，我们有多个读取器和写入器....我假设读取和写入之间会有一些“毫秒锁定”开销，但我保证它仍然比使用完整数据库更快像DB2等。
现在我已经使用SQLite实现了一个队列，它可以在WAL模式下愉快地工作。
我的问题是你真的认为在WebSphere MQ等产品或基于SQLite的队列使用的基于文件的队列之间存在巨大的差异吗？毕竟两者都是基于文件的，并且SQLIte是纯ANSI C的事实对速度来说非常好。
SQLIte确实提供了一些额外的功能，比如“更新钩子”等......以及其他许多功能。
我想我想知道的是，如果您要在C中实现高速持久性队列，您是否会以类似于WebSphere MQ的方式执行此操作，并在单个文件中将消息放入不同的偏移量等，或者你在WAL模式下使用SQLIte吗？
感谢您的帮助; - ）
答案 0 :(得分：0)
使用一个消息生成器，具有默认日志记录参数（双循环或三循环日志记录）的WMQ 7将使用mqjms api在我的笔记本电脑7200高清驱动器上每秒存储大约300-400个持久性消息，同时使用尽可能快的jms代码期望（一个会话，一个消息生成器，在信道上缓冲）和小消息大小（有效载荷大小<1k的字节消息）。在这种情况下，HDD是瓶颈。
通过在QM端使用较少的登录，您将获得更快的速度。这非常线性地扩展。使用不存在的消息也有帮助。
其他常见问题是网络层。消息传递通常是发送大小不超过几kb的小消息。使用来自一个用户的常见网络代码（打开连接/打开会话/打开生成器/返回），您将在硬盘启动之前达到TCP限制。为避免此问题，WMQ允许在通道上进行消息批处理。
我怀疑使用默认登录在WMQ中存储持久性消息比在DB2中插入blob要快。底层机制大致相同（事务日志，rec / ack，...）。
我从未尝试将其与SQLLite进行比较。
WMQ并不是速度快的消息传递解决方案。它也不是最容易管理的解决方案。如上所述，它有光明的一面，我认为它是一个更好的产品。
答案 1 :(得分：0)
您对示例的约束越多，您可能就越能使数字看起来像您想要的任何内容。一个应用程序的单个队列？如果这是您唯一的要求，那么您有很多选择。
但是看一看WAL模式的一些限制。检查点等待读者完成。因此，对于更多的读者来说，检查点越难，检查点就越具有破坏性。如果WAL文件变大，那么读取性能会降低，因此您无法在繁忙的系统上进行延迟检查点并保持高性能。
所以问题“如果要在C中实现高速持久化队列，你会以类似于Websphere MQ的方式实现它，并在单个文件中使用不同的偏移量等消息，或者你会使用吗？ WAL模式下的SQLIte？“没有捕获所有要求或注意事项。随着并发用户数量的增加，流程架构开始掩盖了您所询问的存储方法的差异。 WMQ可以处理数千个并发读取器和写入器，其中非常大的日志文件具有相当平坦的性能曲线，而WAL文档声明性能与WAL文件的大小成比例，即性能曲线随着WAL变大而趋于下降。
如果我要在C中实现高速队列？如果你的意思是我选择哪种现有产品，我会选择经过二十年调整和优化的产品，每年投入数百万美元的R＆amp; D投资，并专注于排队。如果通过“实现”你的意思是我如何从头开始编写一个新的排队引擎，那么我会受到那些专注于排队很长时间的产品的影响，并试图重用他们的解决方案对于非平凡的问题。数据库和排队引擎没有偶然到达各自的存储架构。一个针对队列进行了优化，一个针对数据库语义进行了优化，如果扩展范围以包括除WMQ和SQLite之外的数据库和排队引擎，则这些类别通常都适用。
完全披露：我在WMQ工作了20年的大部分时间，最近加入了IBM的产品管理团队。我可能有点偏颇，但我试图专注于这里的技术，而不是一个下意识的“我的产品比你的产品更好”的反应。随意表示同意投票，不同意投票。如果得票太多，我会撤回答案。