如果不提供估计吞吐量的真实数字，您就无法真正提出有关性能的问题。我们在谈论每秒10个请求，100、1,000、10K吗？

You can't really ask a question about performance without providing real figures for your estimated throughput. Are we talking about 10 requests per second, 100, 1,000, 10K?

如果HTTP服务器确实为每个请求创建和销毁线程，那么反复创建0MQ套接字将强调操作系统，并取决于请求的数量和您的流程限制，它会起作用，或者会用完所有句柄。您可以对此进行简单的测试，这就是第一步。

If the HTTP server is really creating and destroying threads for each request, then creating 0MQ sockets repeatedly will stress the OS and depending on the volume of requests and your process limits, it'll work, or it'll run out of handles. You can test this trivially and thats a first step.

然后，共享一个套接字池（您指的是 ZMQ发布者）很讨厌。人们这样做，但是套接字不是 线程安全的，因此在将套接字切换到另一个线程时，要非常小心。

Then, sharing a pool of sockets (what you mean by "ZMQ publisher") is nasty. People do this but sockets are not threadsafe so it means being very careful when you switch a socket to another thread.

如果有办法为了保持线程的持久性，那么每个人都可以根据需要创建其PUB套接字，并在存在时一直保持下去。如果没有，那么我的第一个设计无论如何都会创建/销毁套接字，但是使用inproc：//将消息发送到单个永久转发器线程（SUB-PUB代理）。我会测试一下，然后如果它崩溃了，那就去做更多奇特的设计。

If there is a way to keep the threads persistent then each one can create its PUB socket if it needs to, and hold onto it as long as it exists. If not, then my first design would create/destroy sockets anyhow, but use inproc:// to send messages to a single permanent forwarder thread (a SUB-PUB proxy). I'd test this and then if it breaks, go for more exotic designs.

总的来说，***是制作最简单的设计并打破它，而不是过度考虑设计过程（尤其是刚开始时）。

In general it's better to make the simplest design and break it, than to over-think the design process (especially when starting out).