zeroMQ初体验-可靠性-总览

在 开篇就从曾对zeromq的可靠性做过质疑，不过，作为一个雄心勃勃的项目，这自然不能成为它的软肋，于是乎，就有了这一完整的章节来介绍和提供“提升可靠性”的解决方案。

这一章节总共会介绍如下一些具备通用性的模式：

• 懒惰的海盗模式：由客户端来保证请求、链路的可靠性。
• 海盗的简单模式：通过LRU队列来保证请求/应答的可靠性。
• 偏执的海盗模式：通过心跳机制来确保链路的通畅。
• 管家模式：由服务器端来保证请求、链路的可靠性。
• 硬盘模式：通过磁盘的同步来确保在不稳定的链路下提供稳定的数据服务。
• 主从模式：通过主从备份来保证服务的可靠性。
• 自由模式：通过冗余的中间件来实现服务的可靠性。

（这边由于没有弄明白原作者的一些比喻，所以，就当是索引吧，主要可从解释中窥得一斑）

关于可靠性：
为了搞清楚什么是可靠性，不妨从他的反面--"故障"来看看。如果可以处理一种可被预测的"故障"，那么就可以认为，系统对于这种"故障"是具有 可靠性的。当然，仅仅是对于这个故障。那么，只要能预测足够的故障，并能做到对这些故障进行相应处理。自然整个系统的可靠性将大大增强。下面将列出一些常 见的故障(按出现频率从高到低排列)：
1，应用程序：无论如何，似乎这都无法被避免，这些架在zeromq之上的应用程序总是会出现“接口撞车”、“消费能力不足导致内存溢出”、“停止响应请求”等待问题。
2，当然，作为整个框架的基础，zeromq本身的代码也会出现“死亡”、“内存溢出”等麻烦。不过，相对而言，我们应该相信他是可靠的（不然用他做什么）。
3，队列溢出：这个溢出可以是可预料的（因为消费能力不足而丢弃一些数据）。
4，物理层面上的链路问题：这是一个隐藏的故障，通常来说，zeromq会进行连接重试，不过，不可避免的会出现间歇性的丢包问题。
5，硬件问题：没有办法，至少基于该硬件的软体都可以理解为“故障”了。
6，链路上的丢包：数据死在路上了...
7，所有的数据中心/云端 地震、火山爆发、杯具了(e..好吧)

想要完整的解决方案来覆盖上面的一系列问题，对于本教程而言着实有些苛求了。所以，之后的方案相对会简单不少。

关于可靠性的设计：
可靠性工程可能是个杯具性的活计，不过，简单的来看(何必那么复杂)，其实只要能尽量缩短 服务的杯具性崩溃时间，使服务看起来一直在运作，似乎也就马马虎虎了，不过纠错还是必不可少的！
例如：
应答模式：如果客户觉得慢，完全可以重试(或许他就能连上不那么忙的服务器了呢)。
发布/订阅模式：如果订阅者错过了一些东西，或许额外加一组应答来请求会比较靠谱。
管道模式：如果服务器后的某个数据加工出了问题，或许可以在统计结果的地方给出提示。

传统的应答模式（基于tcp/ip）当遇到链路断裂或服务器停摆时，很有可能客户端还傻傻的挂着（直到永远）。就这一点而言，zeromq似乎要友好的多，至少，他会帮你重新连接试试～
好吧，这还远远不够，不过，如果再配合着一些额外的操作，其实是可以得到一个可靠的、分布式的应答网络！

简单来说，就有以下三种解决方案：
1.所有客户端连接单一、可确定的服务器。那么一旦哪里崩溃或链路断裂，简单的自检机制加上zeromq的自动重连就可以了。
2.所有客户端连接单一、可确定的队列服务器。数据都放在了队列里，应用崩溃的话，重试应该很简单。
3.多对多的连接。算是1的加强版吧，这里不行，可以连其他的试试。