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