我是否需要为少数几个 ZeroMQ 客户端启动多个服务器端工作程序？

Question

我在 erlang 中使用 Chumak，打开一个 ROUTER 套接字。

我有少数（4 个左右）客户端使用 Python zmq 库向此服务器发送 REQ 请求。

大多数情况下一切正常，但有时客户端会出现断开连接问题（自动重新连接在客户端代码中，并且可以正常工作）。我发现当一个客户端连接发生错误时，它似乎也会转移到其他客户端，并且我得到了很多
** {{noproc,{gen_server,call,[<0.31596.16>,incomming_queue_out]}},
在服务器上。

在服务器端，我只是打开一个 chumak 套接字并循环：

{ok, Sock} = chumak:socket( router ),
{ok, _}    = chumak:bind( Sock, tcp, "0.0.0.0", ?PORT ),
spawn_link( fun() -> loop( Sock ) end ),
...

loop( CmdSock ) ->
    {ok, [Identity, <<>>, Data]} = chumak:recv_multipart( Sock ),
    ...   

ZeroMQ 文档似乎暗示一个监听套接字就足够了，除非我有很多客户端。
我误解他们了吗？

Answer 1

不，不需要增加Socket 实例的数量

抽象对于减少了解典型用户底层所有细节的需求非常有用。每当此类用户必须进行性能调整或调试事件时，这种轻松的生活就会停止。

让我们这样走：
- 除非要移动一些乳齿象大小的数据有效负载，否则足以将单个 ROUTER-AccessPoint 转换为 Socket-实例，例如数十、数百、数千个REQ-客户端上的访问点。
- 然而，这样的数字将增加ROUTER-side Context-实例的性能包络要求，以便保持能够处理所有可扩展的正式通信原型（规定）处理，以便一切都在适当的时候公平地发生。

这意味着，在我提倡使用 zmq.AFFINITY 映射的所有高性能设置中，人们很快就会意识到产生 Context-instances 的好处不仅仅是其初始默认单线程 + ，以便在最高优先级的Socket-instances 上确实获得最大性能，同时让非关键资源共享Context-instance 的 IO-thread-pool 的公共子集。

---

接下来是 RAM
是的，玩具占据了记忆。
检查所有.{RCV|SND}BUF、.MAXMSGSIZE、.{SND|RCV}HWM、.BACKLOG、.CONFLATE

---

接下来是链接管理

不要犹豫，优化.IMMEDIATE，.{RCV|SND}BUF，.RECONNECT_IVL，.RECONNECT_IVL_MAX，.TCP_KEEPALIVE，.TCP_KEEPALIVE_CNT，.TCP_KEEPALIVE_INTVL，.TCP_KEEPALIVE_IDLE

始终在实例化时设置.LINGER，因为退出不再是致命的。

---

接下来可能会出现一些防御和性能辅助工具：

.PROBE_ROUTER、.TCP_ACCEPT_FILTER、.TOS、.HANDSHAKE_IVL

---

下一步？

如果游戏中没有与内存相关的问题，并且一旦提到重新连接，我的怀疑是宁愿去设置.IMMEDIATE + 可能让ROUTER 从明确的PROBE_ROUTER 信号中受益。