设计可伸缩的消息队列体系结构

我最近开始学习可伸缩和企业计算机体系结构的细微差别，其中的核心组件之一是消息传递队列。为了从任何编程范例中学到最多的知识，我试图实现自己的消息传递队列服务版本。

到目前为止，我的最初设计是在线程套接字侦听器上运行的，但是为了防止同一消息被两个单独的处理节点下载两次，消息队列索引寄存器在启动读取时被锁定，并在该寄存器被锁定后解锁。更新。这样，就不需要对其进行线程化，并且意味着基于正在运行消息传递队列服务的服务器的处理速度，可伸缩系统的大小存在上限。

解决此问题的方法是在多个服务器上运行消息队列服务，但这将增加两次下载同一条消息的可能性。防止发生此类问题的唯一方法是包括一个撤消回调（该撤消回调（在服务器甚至单个服务器上的线程已同步其信息并检测到此类重新发布之后）将命令处理节点停止其运行。当前作业，然后重新查询消息队列以获取下一条消息，但是同样，还会有一个上限，在该上限中，大多数正在发送的流量将是同步和吊销回调，从而导致瓶颈并减慢了信息处理的速度，因此许多处理节点将执行空操作并浪费时间。

我能想到的解决此问题的最后一种方法是，使每个消息队列服务器（以及每个服务器上的每个线程）在队列中查找的位置具有特定的偏移量，但这可能会基于类型的应用程序，特别是如果要求以特定顺序进行处理时。

因此，话虽这么说，是否有任何消息队列体系结构设计可以向我展示现有的企业级消息队列服务如何避免这些问题？

简而言之：

这是一个难题。不要重新发明轮子。

有很多技术可以解决消息队列层。它们包括

• 零MQ
• 兔子MQ
• 阿帕奇·卡夫卡
• Redis，带有BLPOP或PUBSUB（我已经在这里问过如何做到这一点）。
• 除RabbitMQ外的其他AMQP实现

我认为讨论每种方法的弊端对我来说是超出范围的，这尤其重要，因为我并没有真正声称能够很好地治好这种咳嗽的专业知识，所以请不要使用Rabbit 咳嗽。

即使您不想使用任何这些技术，也请阅读其文档。

这将使您了解一种系统上可能的设计模式。阅读ZeroMQ的文档将使您了解它们已经优雅地实现的许多经典消息队列体系结构。即使您不使用ZeroMQ，了解这些模式也可以通过询问您是否可以在其中实现该模式来帮助您评估其他排队技术。

了解RabbitMQ / AMQP的交换队列模型。路由可能适合您-Redis PUBSUB支持此功能，但我不记得ZeroMQ支持-扇出是我的商店一直在使用的东西，尽管在Memcached民意测验中实现得很差（很糟糕！）！ 。

如何选择一个？

我在一家初创公司工作，该公司的SLA对于Web应用程序来说很典型-只要我们可以在不造成数据丢失的情况下快速恢复服务，某些中断就可以了。我们不必像Twitter或Tumblr那样考虑扩展问题，因此我们实际上不必考虑吞吐量。话虽如此，如果您正在实施与我的SLA类似的SLA，这些注意事项将会浮现：

• 客户端库实际起作用吗？在它们之间保持连接容易吗？（ZeroMQ，Redis：是。RabbitMQ：否）。
• 通过服务器控制台进行监视和管理是否容易？（Redis：是的，RabbitMQ：是的，ZeroMQ：不是我记得，但是我们使用了这么长时间没有）
• 客户端是否支持内部队列，以便在短时间中断时几乎不会发生数据丢失？（ZeroMQ，Redis：是。RabbitMQ：否。）

当然，如果您正在为一家高频交易商店工作，这些将是您的后顾之忧。您将更愿意将开发时间放在客户端库中，以换取最终更高的吞吐量。但是我在写这篇文章的目的更多是为了警告您，这些技术往往会根据其性能而不是其即用型功能来推向市场。如果你是一个网络的启动，你是远远比前者更热衷于后者，因此，像Redis的，这样更便于在除了强大的性能易上手性能良好的使用进行了优化，可能是一个比RabbitMQ更好的选择。（我真的不喜欢RabbitMQ）。