【发布时间】：2015-04-03 18:31:41
【问题描述】：
ZeroMQ 中有 Request-Reply 和 Titanic 模式，将消息保存到磁盘。据我了解Clients 是可靠的，但不能保存到磁盘。客户端总是会崩溃并丢失一些数据。
我有一个想法将保存到磁盘，从泰坦尼克号模式中的broker 移动到客户端。客户端的可靠性将得到扩展，因此在代理端将不需要。
问题是这样的设计可能会出现什么问题？
【问题讨论】：
标签： zeromq
【发布时间】：2015-04-03 18:31:41
【问题描述】：
过去的一个高科技项目进入了这个领域，因为需要避免在有限的 localhost 设备上出现任何阻塞 DiskIO 操作的问题，并且该解决方案导致了分布式操作模式控制平面和整合平面服务构建在分布式日志单元云之上。
虽然动机不同，但经验可能会帮助您完成这项给定的任务。
如果我可以为您带来一些提示，这两个将是最重要的。完成这一对后，其余部分更易于管理，也更容易快速完成工作：
首先，定义一个需求列表
没有已知目标，任何路都会通向“那里”。
说明必备品和必备品。
为每个项目限定所需的通过/失败绩效指标
示例
任何DiskIO 操作都允许执行自aRemoteEventMessageArrivalTIME 以来的时间延迟/偏差小于200 毫秒。
示例
每当aNumberOfAliveLoggingAGENTs小于aProfileSpecifiedREDUNDANCY时，触发aRedundancyALARM
不要犹豫，花“很多”时间彻底做好这件事。后期附加组件可能会彻底破坏您的时间计划，并使您以前的工作无用和/或危险地在临时“扩展”中重复使用（理解为“a-too-后期添加的功能是原始设计/架构决策绝对不知道的”）版本。
其次，区分“可靠”对您的项目意味着什么
好消息是，理论控制论证实，人们可以设计和运行基于不可靠组件的可靠系统。
坏消息是，您必须从头开始设计复杂的故障恢复能力，自下而上，才能实现。
因此，请注意，什么是必须具备的，什么是可以忽略的，以便在合理的时间和预算内实现您的项目目标。
Nota Bene：记住 Pieter HINTJENS 在其伟大著作中关于可靠性的评论
【讨论】：