ZeroMQ 多线程：按需创建套接字还是使用套接字对象池？

Question

我正在构建一个利用 ZeroMQ N 到 N 发布/订阅模型的 POC。从我们的应用服务器，当一个 http 请求被服务时，如果线程从数据库中提取数据，它会用该数据更新本地 memcache 实例。要应用服务器集群中同步其他内存缓存的情况下，请求线程发送与使用ZMQ发行该数据的消息......这样的问题是：战略是什么最有效的关于减少套接字创建/ destory开销当应用程序有许多线程依赖套接字发送消息？我们是否共享套接字池，我们是否为每个线程创建/销毁套接字等？

策略 1 - 线程管理的发布者套接字
在这种方法中，每个线程 , T1,T2和T3管理套接字对象（发布者）的生命周期，方法是创建它、建立连接、发送消息，最后关闭套接字。基于此，这当然是最安全的方法，但是我们担心重复创建、连接和销毁套接字时的开销；如果开销对性能产生负面影响，我们希望避免它。

策略 2 - 发布者套接字对象池
在这种方法中，父进程（应用服务器）在启动时初始化一个 ZMQ 发布者池。当一个线程需要一个发布者时，它从对象池中获取一个发布者，发送它的消息，然后将发布者返回给对象池；对于使用发布者的线程，消除了创建、连接和销毁套接字的过程，但对池的访问是同步的，以避免任何两个线程同时使用相同的发布者对象，这就是死锁和并发问题的地方可能会出现。

我们没有对任何一种方法进行分析，因为想先对 SO 测试做一个试金石。关于数量，我们的应用程序不会发布“大量”消息，但可能有 100-150 个线程（每个应用服务器）同时需要发布消息。

因此，重申一下：当应用程序有许多依赖于发布者发送消息的线程时，在最小化开销同时强调性能方面，哪种策略最有效？

Answer 1

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

如果 HTTP 服务器确实为每个请求创建和销毁线程，那么重复创建 0MQ 套接字会给操作系统带来压力，并且根据请求量和进程限制，它会工作，或者会耗尽句柄。您可以对此进行简单的测试，这是第一步。

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

如果有一种方法可以保持线程持久化，那么每个线程都可以在需要时创建其 PUB 套接字，并在其存在时保留它。如果没有，那么我的第一个设计无论如何都会创建/销毁套接字，但使用 inproc:// 将消息发送到单个永久转发器线程（SUB-PUB 代理）。我会测试这个，如果它坏了，就去寻找更奇特的设计。

一般来说，最好是做出最简单的设计并打破它，而不是过度思考设计过程（尤其是在开始时）。