1、本章学习内容
2、我的个人理解
容易出现的故障的类型如下&＃xff0c;那么可靠性&＃xff0c;就是在很大程度上不希望出现下面的这些情形
我们所希望的结果就是&＃xff0c;即使出现上面的这些情况&＃xff0c;也能够系统正常的运行下去。
本章主要讲解请求-应答模式中的可靠性设计&＃xff0c;其他模式将在后续章节中讲解。
最基本的请求应答模式是REQ客户端发送一个同步的请求至REP服务端&＃xff0c;这种模式的可靠性很低。如果服务端在处理请求时中止&＃xff0c;那客户端会永远处于等待状态。
相比TCP协议&＃xff0c;ZMQ提供了自动重连机制、消息分发的负载均衡等。但是&＃xff0c;在真实环境中这也是不够的。唯一可以完全信任基本请求-应答模式的应用场景是同一进程的两个线程之间进行通信&＃xff0c;没有网络问题或服务器失效的情况。
但是&＃xff0c;只要稍加修饰&＃xff0c;这种基本的请求-应答模式就能很好地在现实环境中工作了。我喜欢将其称为“海盗”模式。
粗略地讲&＃xff0c;客户端连接服务端有三种方式&＃xff0c;每种方式都需要不同的可靠性设计&＃xff1a;
多个客户端直接和单个服务端进行通信。使用场景&＃xff1a;只有一个单点服务器&＃xff0c;所有客户端都需要和它通信。需处理的故障&＃xff1a;服务器崩溃和重启&＃xff1b;网络连接中断。
多个客户端和单个队列装置通信&＃xff0c;该装置将请求分发给多个服务端。使用场景&＃xff1a;任务分发。需处理的故障&＃xff1a;worker崩溃和重启&＃xff0c;死循环&＃xff0c;过载&＃xff1b;队列装置崩溃和重启&＃xff1b;网络中断。
多个客户端直接和多个服务端通信&＃xff0c;无中间件。使用场景&＃xff1a;类似域名解析的分布式服务。需处理的故障&＃xff1a;服务端崩溃和重启&＃xff0c;死循环&＃xff0c;过载&＃xff1b;网络连接中断。
以上每种设计都必须有所取舍&＃xff0c;很多时候会混合使用。下面我们详细说明。
在本章&＃xff0c;实际上有很多代码的情况实现起来相对要麻烦很多&＃xff0c;博主时间有限&＃xff0c;因此&＃xff0c;仅仅提出思想。 博主等到后面实际涉及到关于可靠性设计的时候&＃xff0c;将会针对自己设计的系统进行仔细的可靠性的设计。
在接收应答时&＃xff0c;我们不进行同步等待&＃xff0c;而是做以下操作&＃xff1a;
在所有的海盗模式中&＃xff0c;worker是无状态的&＃xff0c;或者说存在着一个我们所不知道的公共状态&＃xff0c;如共享数据库。队列装置的存在意味着worker可以在client毫不知情的情况下随意进出。一个worker死亡后&＃xff0c;会有另一个worker接替它的工作。这种拓扑结果非常简洁&＃xff0c;但唯一的缺点是队列装置本身会难以维护&＃xff0c;可能造成单点故障。
在第三章中&＃xff0c;队列装置的基本算法是最近最少使用算法。那么&＃xff0c;如果worker死亡或阻塞&＃xff0c;我们需要做些什么&＃xff1f;答案是很少很少。我们已经在client中加入了重试的机制&＃xff0c;所以&＃xff0c;使用基本的LRU队列就可以运作得很好了。这种做法也符合ZMQ的逻辑&＃xff0c;所以我们可以通过在点对点交互中插入一个简单的队列装置来扩展它&＃xff1a;
实际上&＃xff0c;在本来的这种模式的基础上&＃xff0c;就已经有了很好的可靠性了&＃xff0c;我们需要做的实际上很少。
简单海盗队列”模式工作得非常好&＃xff0c;主要是因为它只是两个现有模式的结合体。不过&＃xff0c;它也有一些缺点&＃xff1a;
该模式无法处理队列的崩溃或重启。client会进行重试&＃xff0c;但worker不会重启。虽然ZMQ会自动重连worker的套接字&＃xff0c;但对于新启动的队列装置来说&＃xff0c;由于worker并没有发送“已就绪”的消息&＃xff0c;所以它相当于是不存在的。为了解决这一问题&＃xff0c;我们需要从队列发送心跳给worker&＃xff0c;这样worker就能知道队列是否已经死亡。
队列没有检测worker是否已经死亡&＃xff0c;所以当worker在处于空闲状态时死亡&＃xff0c;队列装置只有在发送了某个请求之后才会将该worker从队列中移除。这时&＃xff0c;client什么都不能做&＃xff0c;只能等待。这不是一个致命的问题&＃xff0c;但是依然是不够好的。所以&＃xff0c;我们需要从worker发送心跳给队列装置&＃xff0c;从而让队列得知worker什么时候消亡。
为了加入心跳管理&＃xff0c;判断我们的worker是不是有可能出现了什么不可预知的问题
之前我们使用REQ套接字作为worker的套接字类型&＃xff0c;但在偏执海盗模式中我们会改用DEALER套接字&＃xff0c;从而使我们能够任意地发送和接受消息&＃xff0c;而不是像REQ套接字那样必须完成发送-接受循环。而DEALER的缺点是我们必须自己管理消息信封。如果你不知道信封是什么&＃xff0c;那请阅读第三章。
在实施管家模式之前&＃xff0c;我们需要为client和worker编写一个框架。如果程序员可以通过简单的API来实现这种模式&＃xff0c;那就没有必要让他们去了解管家模式的协议内容和实现方法了。 所以&＃xff0c;我们第一个协议&＃xff08;即管家模式协议&＃xff09;定义了分布式架构中节点是如何互相交互的&＃xff0c;第二个协议则要定义应用程序应该如何通过框架来使用这一协议。 管家模式有两个端点&＃xff0c;客户端和服务端。因为我们要为client和worker都撰写框架&＃xff0c;所以就需要提供两套API。以下是用简单的面向对象方法设计的client端API雏形&＃xff0c;使用的是C语言的ZFL library。
几点说明&＃xff1a;
API是单线程的&＃xff0c;所以说worker不会再后台发送心跳&＃xff0c;而这也是我们所期望的&＃xff1a;如果worker应用程序停止了&＃xff0c;心跳就会跟着中止&＃xff0c;代理便会停止向该worker发送新的请求。
wroker API没有做回退算法的设置&＃xff0c;因为这里不值得使用这一复杂的机制。
API没有提供任何报错机制&＃xff0c;如果出现问题&＃xff0c;它会直接报断言&＃xff08;或异常&＃xff0c;依语言而定&＃xff09;。这一做法对实验性的编程是有用的&＃xff0c;这样可以立刻看到执行结果。但在真实编程环境中&＃xff0c;API应该足够健壮&＃xff0c;合适地处理非法消息。
也许你会问&＃xff0c;worker API为什么要关闭它的套接字并新开一个呢&＃xff1f;特别是ZMQ是有重连机制的&＃xff0c;能够在节点归来后进行重连。我们可以回顾一下简单海盗模式中的worker&＃xff0c;以及偏执海盗模式中的worker来加以理解。ZMQ确实会进行自动重连&＃xff0c;但如果代理死亡并重连&＃xff0c;worker并不会重新进行注册。这个问题有两种解决方案&＃xff1a;一是我们这里用到的较为简便的方案&＃xff0c;即当worker判断代理已经死亡时&＃xff0c;关闭它的套接字并重头来过&＃xff1b;另一个方案是当代理收到未知worker的心跳时要求该worker对其提供的服务类型进行注册&＃xff0c;这样一来就需要在协议中说明这一规则。
上文那种实现管家模式的方法比较简单&＃xff0c;client还是简单海盗模式中的&＃xff0c;仅仅是用API重写了一下。我在测试机上运行了程序&＃xff0c;处理10万条请求大约需要14秒的时间&＃xff0c;这和代码也有一些关系&＃xff0c;因为复制消息帧的时间浪费了CPU处理时间。但真正的问题在于&＃xff0c;我们总是逐个循环进行处理&＃xff08;round-trip&＃xff09;&＃xff0c;即发送-接收-发送-接收……ZMQ内部禁用了TCP发包优化算法&＃xff08;Nagle&＃39;s algorithm&＃xff09;&＃xff0c;但逐个处理循环还是比较浪费。
理论归理论&＃xff0c;还是需要由实践来检验。我们用一个简单的测试程序来看看逐个处理循环是否真的耗时。这个测试程序会发送一组消息&＃xff0c;第一次它发一条收一条&＃xff0c;第二次则一起发送再一起接收。两次结果应该是一样的&＃xff0c;但速度截然不同。
由于worker获得消息需要通过LRU队列机制&＃xff0c;所以并不能做到完全的异步。但是&＃xff0c;worker越多其效果也会越好。在我的测试机上&＃xff0c;当worker的数量达到8个时&＃xff0c;速度就不再提升了——四核处理器只能做这么多。但是&＃xff0c;我们仍然获得了近四倍的速度提升&＃xff0c;而改造过程只有几分钟而已。此外&＃xff0c;代理其实还没有进行优化&＃xff0c;它仍会复制消息&＃xff0c;而没有实现零拷贝。不过&＃xff0c;我们已经做到每秒处理2.5万次请求-应答&＃xff0c;已经很不错了。
当然&＃xff0c;异步的管家模式也并不完美&＃xff0c;有一个显著的缺点&＃xff1a;它无法从代理的崩溃中恢复。可以看到mdcliapi2的代码中并没有恢复连接的代码&＃xff0c;重新连接需要有以下几点作为前提&＃xff1a;
可以看到&＃xff0c;高可靠性往往和复杂度成正比&＃xff0c;值得在管家模式中应用这一机制吗&＃xff1f;这就要看应用场景了。如果是一个名称查询服务&＃xff0c;每次会话会调用一次&＃xff0c;那不需要应用这一机制&＃xff1b;如果是一个位于前端的网页服务&＃xff0c;有数千个客户端相连&＃xff0c;那可能就需要了。
现在&＃xff0c;我们已经有了一个面向服务的代理了&＃xff0c;但是我们无法得知代理是否提供了某项特定服务。如果请求失败&＃xff0c;那当然就表示该项服务目前不可用&＃xff0c;但具体原因是什么呢&＃xff1f;所以&＃xff0c;如果能够询问代理“echo服务正在运行吗&＃xff1f;”&＃xff0c;那将会很有用处。最明显的方法是在MDP/Client协议中添加一种命令&＃xff0c;客户端可以询问代理某项服务是否可用。但是&＃xff0c;MDP/Client最大的优点在于简单&＃xff0c;如果添加了服务查询的功能就太过复杂了。
另一种方案是学电子邮件的处理方式&＃xff0c;将失败的请求重新返回。但是这同样会增加复杂度&＃xff0c;因为我们需要鉴别收到的消息是一个应答还是被退回的请求。
让我们用之前的方式&＃xff0c;在MDP的基础上建立新的机制&＃xff0c;而不是改变它。服务定位本身也是一项服务&＃xff0c;我们还可以提供类似于“禁用某服务”、“提供服务数据”等其他服务。我们需要的是一个能够扩展协议但又不会影响协议本身的机制。
这样就诞生了一个小巧的RFC - MMI&＃xff08;管家接口&＃xff09;的应用层&＃xff0c;建立在MDP协议之上&＃xff1a;http://rfc.zeromq.org/spec:8 。我们在代理中其实已经加以实现了&＃xff0c;不知你是否已经注意到。下面的代码演示了如何使用这项服务查询功能&＃xff1a;
代理在运行时会检查请求的服务名称&＃xff0c;自行处理那些mmi.开头的服务&＃xff0c;而不转发给worker。你可以在不开启worker的情况下运行以上代码&＃xff0c;可以看到程序是报告200还是404。MMI在示例程序代理中的实现是很简单的&＃xff0c;比如&＃xff0c;当某个worker消亡时&＃xff0c;该服务仍然标记为可用。实践中&＃xff0c;代理应该在一定间隔后清除那些没有worker的服务。
幂等是指能够安全地重复执行某项操作。如&＃xff0c;看钟是幂等的&＃xff0c;但借钱给别人老婆就不是了。有些客户端至服务端的通信是幂等的&＃xff0c;但有些则不是。幂等的通信示例有&＃xff1a;
非幂等的通信示例有&＃xff1a;
如果应用程序提供的服务是非幂等的&＃xff0c;那就需要考虑它究竟是在哪个阶段崩溃的。如果程序在空闲或处理请求的过程中崩溃&＃xff0c;那不会有什么问题。我们可以使用数据库中的事务机制来保证借贷操作是同时发生的。如果应用程序在发送请求的时候崩溃了&＃xff0c;那就会有问题&＃xff0c;因为对于该程序来说&＃xff0c;它已经完成了工作。
如果在返回应答的过程中网络阻塞了&＃xff0c;客户端会认为请求发送失败&＃xff0c;并进行重发&＃xff0c;这样服务端会再一次执行相同的请求。这不是我们想要的结果。
常用的解决方法是在服务端检测并拒绝重复的请求&＃xff0c;这就需要&＃xff1a;
当你意识到管家模式是一种非常可靠的消息代理时&＃xff0c;你可能会想要使用磁盘做一下消息中转&＃xff0c;从而进一步提升可靠性。这种方式虽然在很多企业级消息系统中应用&＃xff0c;但我还是有些反对的&＃xff0c;原因有&＃xff1a;
我们可以看到&＃xff0c;懒惰海盗模式的client可以工作得非常好&＃xff0c;能够在多种架构中运行。唯一的问题是它会假设worker是无状态的&＃xff0c;且提供的服务是幂等的。但这个问题我们可以通过其他方式解决&＃xff0c;而不是添加磁盘。
添加磁盘会带来新的问题&＃xff0c;需要额外的管理和维护费用。海盗模式的最大优点就是简单明了&＃xff0c;不会崩溃。如果你还是担心硬件会出问题&＃xff0c;可以改用点对点的通信模式&＃xff0c;这会在本章最后一节讲到。
虽然有以上原因&＃xff0c;但还是有一个合理的场景可以用到磁盘中转的——异步脱机网络。海盗模式有一个问题&＃xff0c;那就是client发送请求后会一直等待应答。如果client和worker并不是长连接&＃xff08;可以拿电子邮箱做个类比&＃xff09;&＃xff0c;我们就无法在client和worker之间建立一个无状态的网络&＃xff0c;因此需要将这种状态保存起来。
于是我们就有了巨人模式&＃xff0c;该模式下会将消息写到磁盘中&＃xff0c;确保不会丢失。当我们进行服务查询时&＃xff0c;会转向巨人这一层进行。巨人是建立在管家之上的&＃xff0c;而不是改写了MDP协议。这样做的好处是我们可以在一个特定的worker中实现这种可靠性&＃xff0c;而不用去增加代理的逻辑。
唯一的缺点是&＃xff0c;代理和磁盘之间会有一层额外的联系&＃xff0c;不过这也是值得的。
我们有很多方法来实现一种持久化的请求-应答架构&＃xff0c;而目标当然是越简单越好。我能想到的最简单的方式是提供一种成为“巨人”的代理服务&＃xff0c;它不会影响现有worker的工作&＃xff0c;若client想要立即得到应答&＃xff0c;它可以和代理进行通信&＃xff1b;如果它不是那么着急&＃xff0c;那就可以和巨人通信&＃xff1a;“嗨&＃xff0c;巨人&＃xff0c;麻烦帮我处理下这个请求&＃xff0c;我去买些菜。”
这样一来&＃xff0c;巨人就既是worker又是client。client和巨人之间的对话一般是&＃xff1a;
巨人和代理之间的对话一般是&＃xff1a;
你可以想象一些发生故障的情形&＃xff0c;看看上述模式是否能解决&＃xff1f;worker在处理请求的时候崩溃&＃xff0c;巨人会不断地重新发送请求&＃xff1b;应答在传输过程中丢失了&＃xff0c;巨人也会重试&＃xff1b;如果请求已经处理&＃xff0c;但client没有得到应答&＃xff0c;那它会再次询问巨人&＃xff1b;如果巨人在处理请求或进行应答的时候崩溃了&＃xff0c;客户端会进行重试&＃xff1b;只要请求是被保存在磁盘上的&＃xff0c;那它就不会丢失。
这个机制中&＃xff0c;握手的过程是比较漫长的&＃xff0c;但client可以使用异步的管家模式&＃xff0c;一次发送多个请求&＃xff0c;并一起等待应答。
我们需要一种方法&＃xff0c;让client会去请求应答内容。不同的client会访问到相同的服务&＃xff0c;且client是来去自由的&＃xff0c;有着不同的标识。一个简单、合理、安全的解决方案是&＃xff1a;
这样一来client就需要负责将UUID安全地保存起来&＃xff0c;不过这就省去了验证的过程。有其他方案吗&＃xff1f;我们可以使用持久化的套接字&＃xff0c;即显式声明客户端的套接字标识。然而&＃xff0c;这会造成管理上的麻烦&＃xff0c;而且万一两个client的套接字标识相同&＃xff0c;那会引来无穷的麻烦。
在我们开始制定一个新的协议之前&＃xff0c;我们先思考一下client如何和巨人通信。一种方案是提供一种服务&＃xff0c;配合三个不同的命令&＃xff1b;另一种方案则更为简单&＃xff0c;提供三种独立的服务&＃xff1a;
我们需要创建一个多线程的worker&＃xff0c;正如我们之前用ZMQ进行多线程编程一样&＃xff0c;很简单。但是&＃xff0c;在我们开始编写代码之前&＃xff0c;先讲巨人模式的一些定义写下来&＃xff1a;http://rfc.zeromq.org/spec:9 。我们称之为“巨人服务协议”&＃xff0c;或TSP。
几点说明&＃xff1a;
这个示例程序不应关注它的性能&＃xff08;一定会非常糟糕&＃xff0c;虽然我没有测试过&＃xff09;&＃xff0c;而是应该看到它是如何提供一种可靠的通信模式的。你可以测试一下&＃xff0c;打开代理、巨人、worker和client&＃xff0c;使用-v参数显示跟踪信息&＃xff0c;然后随意地开关代理、巨人、或worker&＃xff08;client不能关闭&＃xff09;&＃xff0c;可以看到所有的请求都能获得应答。
如果你想在真实环境中使用巨人模式&＃xff0c;你肯定会问怎样才能让速度快起来。以下是我的做法&＃xff1a;
另外&＃xff0c;我不建议将消息保存在数据库中&＃xff0c;甚至不建议交给那些所谓的高速键值缓存&＃xff0c;它们比起一个磁盘文件要来得昂贵。
如果你想让巨人模式变得更为可靠&＃xff0c;你可以将请求复制到另一台服务器上&＃xff0c;这样就不需要担心主程序遭到核武器袭击了。
如果你想让巨人模式变得更为快速&＃xff0c;但可以牺牲一些可靠性&＃xff0c;那你可以将请求和应答都保存在内存中。这样做可以让该服务作为脱机网络运行&＃xff0c;不过若巨人服务本身崩溃了&＃xff0c;我也无能为力。
双子星模式由Pieter Hintjens和Martin Sustrik设计&＃xff0c;应用在iMatix的OpenAMQ服务器中。它的设计理念是&＃xff1a;
详细要求
双子星模式可以非常简单&＃xff0c;但能工作得很出色。事实上&＃xff0c;这里的实现方法已经历经三个版本了&＃xff0c;之前的版本都过于复杂&＃xff0c;想要做太多的事情&＃xff0c;因而被我们抛弃。我们需要的只是最基本的功能&＃xff0c;能够提供易理解、易开发、高可靠的解决方法就可以了。
以下是该架构的详细需求&＃xff1a;
我们做如下架假设&＃xff1a;
双子星模式不会用到&＃xff1a;
以下是双子星模式中的几个术语&＃xff1a;
配置双子星模式的步骤&＃xff1a;
比较重要的配置是应让两台机器间隔多久检查一次对方的状态&＃xff0c;以及多长时间后采取行动。在我们的示例中&＃xff0c;故障恢复时间设置为2000毫秒&＃xff0c;超过这个时间备机就会代替主机的位置。但若你将主机的服务包裹在一个shell脚本中进行重启&＃xff0c;就需要延长这个时间&＃xff0c;否则备机可能在主机恢复连接的过程中转换成master。
要让客户端应用程序和双子星模式配合&＃xff0c;你需要做的是&＃xff1a;
这不是件容易的事&＃xff0c;所以我们一般会将其封装成一个API&＃xff0c;供程序员使用。
双子星模式的主要限制有&＃xff1a;
精神分裂”症状指的是一个集群中的不同部分同时认为自己是master&＃xff0c;从而停止对对方的检测。双子星模式中的算法会降低这种症状的发生几率&＃xff1a;主备机在决定自己是否为master时会检测自身是否收到了应用程序的请求&＃xff0c;以及对方是否已经从网络中消失。
但在某些情况下&＃xff0c;双子星模式也会发生精神分裂。比如说&＃xff0c;主备机被配置在两幢大楼里&＃xff0c;每幢大楼的局域网中又分布了一些应用程序。这样&＃xff0c;当两幢大楼的网络通信被阻断&＃xff0c;双子星模式的主备机就会分别在两幢大楼里接受和处理请求。
为了防止精神分裂&＃xff0c;我们必须让主备机使用专用的网络进行连接&＃xff0c;最简单的方法当然是用一根双绞线将他们相连。
我们不能将双子星部署在两个不同的岛屿上&＃xff0c;为各自岛屿的应用程序服务。这种情况下&＃xff0c;我们会使用诸如联邦模式的机制进行可靠性设计。
最好但最夸张的做法是&＃xff0c;将两台机器之间的连接和应用程序的连接完全隔离开来&＃xff0c;甚至是使用不同的网卡&＃xff0c;而不仅仅是不同的端口。这样做也是为了日后排查错误时更为明确。
2.6 无中间件的可靠性&＃xff08;自由者模式&＃xff09;
巴拉巴拉&＃xff0c;参考原文&＃xff0c;我到现在实际上&＃xff0c;也没有完全理解作者写后面这个作用&＃xff0c;实际上应当是归咎于自己没有实际的经验以及刚入门&＃xff0c;随后&＃xff0c;等待自己的系统搭建起来后&＃xff0c;再进行详细讨论。
京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有 
