我正在运行一个Apache服务器，它接收HTTP请求并通过ZeroMQ连接到守护程序脚本。该脚本实现了多线程服务器模式（http://zguide.zeromq.org/page:all#header-73），它成功接收请求并将其分派给其一个工作线程，执行操作，响应服务器，服务器响应客户端。一切都是同步完成的，因为客户需要收到对其请求的成功或失败响应。
随着用户数量增长到数千，我正在研究可能会改善这一点。我看到的第一件事是ZeroMQ的不同模式，以及我使用的是否适用于我的场景。我已阅读该指南，但我发现它难以理解所有细节和模式之间的差异。我在Load Balancing Message Broker模式（http://zguide.zeromq.org/page:all#header-73）上寻找示例。实施起来似乎比我目前使用的要复杂得多，如果我理解正确，它的优点是：
实际负载均衡与我目前拥有的循环任务分配
异步请求/回复
这就是一切吗？我错过了什么吗？鉴于我的问题的描述，以及它的同步要求，你会说最好的模式是什么？最后，如果我想让我的设置分布式（即让Apache服务器负载平衡不同机器上的请求），答案将如何改变。我想通过简单地创建另一个基于多线程服务器模式的层来实现这一点，并让该层桥接Web服务器和我的工作者之间的通信。
答案 0 :(得分：2)
关于这个问题的一些想法......
我会尽量保持简单和“简单”ZeroMQ。为了提高性能，我只需更改后端脚本以从经销商套接字发送请求并将请求处理代码移动到自己的程序。然后，您可以在不同的计算机上运行多个工作服务器以处理更多请求。
我认为这是你采取的方法：
我想通过简单地创建另一个基于多线程服务器模式的层来实现这一点，并让该层桥接Web服务器和我的工作者之间的通信。
这里唯一的问题是后端没有请求重试。如果工人无法处理给定的任务，它将永远丢失。但是，可以编写工作服务器，以便它们在关闭之前处理它们获得的所有请求。通过这种设置，可以更新后端工作人员，而无需客户注意任何短缺。如果服务器崩溃，这将无法保存丢失的请求。
我觉得在一般情况下这种方法绰绰有余。
Mongrel2似乎处理了很多你已经实现过的东西。检查它可能是值得的。它可能无法完全解决您的问题，但它提供了经过测试的基础架构来分配工作负载。这可用于将要处理的请求传递给在不同计算机上运行的多线程服务器。
提高设置稳健性的一个解决方案是经纪人。在这种情况下，代理主要的作用是通过为请求实现队列来提供健壮性。我理解工人处理的所有请求基本上都是相同的类型。如果请求具有不同的类型，则代理也可以执行查找以查找请求的正确服务器。
使用队列提供了一种方法来确保即使工作服务器崩溃，某些代理也会处理每个请求。这不是没有价格的。经纪人本身就是一个单一的失败点。如果崩溃或重新启动，则所有消息都可能丢失。
可以避免这些问题，但这需要做很多工作：请求可以持久保存到磁盘，服务器可以集群化。需要对收益进行加权。是否有人想用时间编写消息代理或实际系统？
如果消息代理似乎是一个好主意，那么通过使用已经实现的产品（如RabbitMQ）可以减少实现消息代理所需的时间。负面影响是可能存在许多不需要的功能，并且添加新内容并不像自制代理那么直接。
编写自己的经纪人可能会再次发明轮子。许多代理提供类似的东西：安全性，日志记录，管理界面等。似乎这些最终也需要在自制解决方案中使用。但是，如果没有那么单一的自制经纪人做单一的事情并做得好可以是一个很好的选择。即使选择了经纪人产品，我认为隐藏ZeroMQ代理后面的代理是一个好主意，ZeroMQ代理是一个从代理发送/接收消息的专用代码。然后，系统的其他任何部分都不得知道有关代理的任何信息，并且可以轻松替换它。
使用代理有点像开发人员。您需要时间来实现代理或时间来使用某些产品。在明确需要之前我会避开这条路线。
一些链接