ZeroMQ中有Request-Reply，并且有一个泰坦尼克号模式，即将消息保存到磁盘。根据我的理解Clients是可靠的，但不是保存到磁盘的方式。客户端总是会崩溃并丢失一些数据。
我有一个想法是将保存到磁盘，从泰坦尼克号模式的broker移动到客户端。客户的可靠性将得到延长，因此在经纪人方面不需要。
问题是这种设计可能出现的问题？
答案 0 :(得分：1)
过去的高科技项目之一进入这一领域是因为需要避免在有限的本地主机设备上出现阻塞DiskIO操作，并且该解决方案导致了分布式操作模式使用控制平面和Consolidation Plane服务构建在分布式日志记录单元云的顶部。
虽然动机不同，但经验可以帮助你完成这项任务。
如果我可以为您提供一些技巧，这两个将是最重要的。完成这一对后，其余部分更易于管理，更直接地完成工作：
没有已知目标，任何道路引导“那里”。
说明必须拥有的和必须拥有的。
对于每个项目，限定所需的通过/失败绩效指标
实施例
允许执行任何DiskIO操作，自aRemoteEventMessageArrivalTIME以来时间延迟/偏差小于200毫秒。
实施例
每当aNumberOfAliveLoggingAGENTs小于aProfileSpecifiedREDUNDANCY时，触发aRedundancyALARM
毫不犹豫地花费“很多”时间完成这项工作。迟到的附加（s）可能完全破坏您的时间计划，并使您以前的工作无用和/或有害，无法在ad-hoc“扩展”中重复使用（理解为“a-too-”最近添加的功能原始设计/架构决策绝对不知道“）版本。
好消息是，理论控制论证实，人们可以设计和运行基于不可靠组件的可靠系统。
坏消息是，您必须从头开始，自下而上地设计复杂的故障恢复能力，以实现这一目标。
所以，要小心，真正必须拥有的东西以及可以省略的东西，以便在合理的时间和时间内实现您的项目目标。预算。
Nota Bene ：记得Pieter HINTJENS在他的伟大着作中对可靠性的评论