可靠的Client-Server架构，切换到发布-订阅？
我需要一个可靠的请求-响应模型。我正在使用ZeroMQ。到目前为止，我使用的是REQ/REP模式(另外还有PUB/SUB，但现在已经不重要了)。
如果客户端崩溃，它可以很容易地重启和连接。因此，我使用了ZeroMQ Guide中的"Lazy Pirate Pattern“示例。如果服务器崩溃，事情就没那么简单了。我必须告诉我的客户端，它必须重新启动才能连接。当然，有了像PUB/SUB这样的额外频道，我可以处理这个问题，但我要问自己的是：
为每个方向实现一个模仿REQ/REP模式的发布/订阅模式不是更容易吗？如果服务器崩溃，它可以很容易地连接，而不会让客户端重新启动。
因此，服务器有一个SUB和一个PUB套接字，而客户端有一个SUB和一个PUB套接字。
回答 1
Stack Overflow用户
发布于 2019-08-27 04:19:20
Q：为模仿
REQ/REP模式的每个方向实现模式不是更容易吗？
答案：
这个问题是无法决定的。
原因：
给定零MCVE代码特异性，没有人可以制定出什么是难的，什么是容易的度量标准。
作为根本问题，多方分布式有限状态自动机可能已经以Minimum-Viable-Product方式指定。然后，MVP的必备特性集明确规定了实现范围和任何这种实现必须配备的最低健壮性级别。
REQ/REP-distributed-behavioural-archetype有许多不同的原生属性，PUB/SUB-substitute很难模仿/模仿这些属性。PUB-sender将很难强制在出口流量方向上提供公平队列(轮询)负载平衡，举一些问题的例子，这将出现在试图用一个原型替换另一个原型的情况下。
无论如何，任何希望在多方代理网络上拥有分布式行为模式的新原型，首先需要这种行为的坚如磐石的规范，然后才能决定如何使用一些基本的工具来实现它的任何潜在方法。
在各种糟糕和最糟糕的方法中，使用马斯洛的锤子是毫无疑问的。
结语：
如果对Zen- of -Zero的艺术感兴趣，请随时阅读other posts here或Pieter HINTJENS的精彩书籍"Code Connected，Vol.I“--这是一篇关于这方面的必读文章。
https://stackoverflow.com/questions/57620446
复制相似问题
腾讯云开发者
