MQ
文章平均质量分 56
iteye_14316
这个作者很懒,什么都没留下…
展开
-
zeroMQ初体验-27.可靠性-硬盘模式
在之前的种种模式中,虽然各擅胜场,可是有一个根本性的问题:一旦数据在某个环节丢失了,那么它就真的丢失了(虽然会有种种重试机制)。而"硬盘模式"即是为了应对这种情况而出现的。结构图:[img]https://github.com/imatix/zguide/raw/master/images/fig61.png[/img]是不是非常眼熟?只是对[url=http://iyuan.it...2011-05-23 13:44:38 · 118 阅读 · 0 评论 -
zeroMQ初体验-12.安全与稳定
可能绝大多数接触zeromq的人都会对其去中心的自由感到满意,同时却又对数据传输的可靠性产生怀疑甚至沮丧(如果恰巧你也知道"兔子"的话)。在这里,或许可以为此作出一些弥补,增强诸位使用它的信心。zeromq之所以传输的速度无以伦比,它的"zero copy"功不可没,在这种机制下,减少了数据的二次缓存和挪动,并且减少了通讯间的应答式回应。不过在快速的同时,也降低了数据传递的可靠性。...2011-03-31 12:12:52 · 447 阅读 · 0 评论 -
zeroMQ初体验-13.发布/订阅模式 进阶
前面章节有介绍过当传输大数据时,建议分拆成多个小数据逐个发送,以防单条数据过大引发内存溢出等问题。同样的,这也适用于 发布订阅模式,这里用到了一个新名词:信封。这种封装的数据结构看起来是这样的:[img]http://github.com/imatix/zguide/raw/master/images/fig27.png[/img]由于key的关系,不用担心出现 被分拆为多份的...2011-03-31 13:53:54 · 116 阅读 · 0 评论 -
zeroMQ初体验-14.命名机制 进阶
[url=http://iyuan.iteye.com/blog/981677]前文[/url]曾提到过命名机制,事实上它是一把双刃剑。在能够持有数据等待重新连接的时候,也增加了持有数据方的负担(危险),特别是在"发布/订阅"模式下,可谓牵一发而动全身。这里先给出一组示例,在代码的运行过程中,通过重启消费者来观察发布者的进程状态。发布端:[code="python"]imp...2011-03-31 14:39:19 · 143 阅读 · 0 评论 -
zeroMQ初体验-15.应答模式进阶(一)-数据的封装
整整一大章全部讲的应答模式的进阶,应该很重要吧(简直是一定的)。上一节讲到了发布/订阅模式 关于封装的话题,在应答模式中也是如此,不过这个动作已经被底层(zeromq)接管,对应用透明。而其中普通模式与X模式又有区别,例如:req连接Xrep:[img]http://github.com/imatix/zguide/raw/master/images/fig29.png[/img]...2011-03-31 18:09:17 · 218 阅读 · 0 评论 -
zeroMQ初体验-16.应答模式进阶(二)-定制路由1
在上一节中已经提到XREP主要工作是包装数据,打上标记以便方便的传递数据。那么,换个角度来看,这不就是路由么!其实在[url=http://iyuan.iteye.com/blog/975612]优雅的扩展[/url]中有介绍过。在这里针对XREP模式做深入的探索。首先,得要理一下其中几种类型的差别(相似的名字真是坑爹啊):REQ,官网称之为"老妈类型",因为它负责主动提出请求,并且要...2011-04-01 18:48:48 · 185 阅读 · 0 评论 -
zeroMQ初体验-17.应答模式进阶(三)-定制路由2
XREP-REQ模式:典型的"老妈模式",只有当她真的要听你说时,她才能听的进去。所以首先,得要REQ告诉你“她准备好了,你可以讲了”,然后,你才能倾吐...一般来说与XREQ一样,一个REQ只能连接一个XREP(除非你想做容错,不过,不建议那样)。实例模型:[img]http://github.com/imatix/zguide/raw/master/images/fig...2011-04-02 13:54:35 · 190 阅读 · 0 评论 -
zeroMQ初体验-18.应答模式进阶(四)-定制路由3
从经典到超越经典。首先,先回顾下经典:[img]http://github.com/imatix/zguide/raw/master/images/fig39.png[/img]然后,扩展:[img]http://github.com/imatix/zguide/raw/master/images/fig40.png[/img]然后,变异:[img]http://g...2011-04-02 15:39:20 · 211 阅读 · 0 评论 -
zeroMQ初体验-19.应答模式进阶(五)-异步式应答
恩,这应该算是比较实用的部分了。模式图:[img]https://github.com/imatix/zguide/raw/master/images/fig46.png[/img][code="python"]import zmqimport threadingimport timefrom random import choiceclass Clie...2011-04-15 15:23:26 · 165 阅读 · 0 评论 -
zeroMQ初体验-20.应答模式进阶(六)-多对多路由模式
某些时候,为了冗余的需要,可能会有这样的需求:[img]https://github.com/imatix/zguide/raw/master/images/fig48.png[/img][code="python"]import zmqimport timeimport zhelperscontext = zmq.Context()worker = conte...2011-04-18 17:22:32 · 549 阅读 · 0 评论 -
zeroMQ初体验-21.应答模式进阶(七)-云计算
这里给出了一个最近很火的"云计算"案例。定义:在各种各样的硬件设备上运行着N多的worker,而任意一个worker都能够独立解决一个问题。每一个集群有这样的设备成千上百个,而同时又有一打这样的集群互相连接交互,于是,这么一个总的集合称为“云”,而其提供的服务称为“云计算”。在“云中”的任一设备或集群都可以做到"进出自由"、任何崩溃的worker都能被检测和重启,那么,基本上就可以...2011-04-18 19:14:27 · 91 阅读 · 0 评论 -
rabbitmq 队列长度预设的曲线方案
zeromq中倒是直接支持这个功能的。类似于设定队列长度或大小,超过多少条数据(或多大数据size)即不接纳新的数据或者是丢弃最旧的数据。rabbitmq中没有这个设置,单从应用的角度出发,新的机制中出现了一个曲线式的方案,通过设定 x-expires 参数实现伪auto-delete功能:在设定时间内没有消费者,则队列自动删除。如此也算间接解决了:队列过于堆积导致服务崩溃的问...2011-04-21 14:36:41 · 262 阅读 · 0 评论 -
zeroMQ初体验-22.可靠性-总览
在[url=http://iyuan.iteye.com/blog/972949]开篇[/url]就从曾对zeromq的可靠性做过质疑,不过,作为一个雄心勃勃的项目,这自然不能成为它的软肋,于是乎,就有了这一完整的章节来介绍和提供“提升可靠性”的解决方案。这一章节总共会介绍如下一些具备通用性的模式:[list][*]懒惰的海盗模式:由客户端来保证请求、链路的可靠性。[*]海盗的...2011-04-26 19:25:42 · 171 阅读 · 0 评论 -
zeroMQ初体验-23.可靠性-懒惰的海盗模式
相较于通常的阻塞模式,这里只是做了一点简单的动作来加强系统的可靠性(不再是通常性质的阻塞了)。这种模式增加/变更了以下几点:[list][*]轮询已经发出的请求直到得到响应[*]在一定时间内未得到相应则重新发出请求[*]在一定次数的重试不成功之后,停止请求[/list]相较于传统的阻塞模式,好处显而易见:在未得到答复时可以继续发出请求而不是碰到预料之外的报错之类...2011-05-05 16:15:43 · 299 阅读 · 0 评论 -
zeroMQ初体验-24.可靠性-简单的海盗模式
相较于“懒惰的”做了些许扩展,适当的挽救那个“死等”的败笔~[img]https://github.com/imatix/zguide/raw/master/images/fig58.png[/img]恰如图所示,在消费者与服务者中加了一个中间件,做了一个请求的分发工作(尽管不是那么智能),避免了每次总是在等待不靠谱的worker服务。中间的均衡队列:[code="ja...2011-05-05 16:41:04 · 156 阅读 · 0 评论 -
zeroMQ初体验-25.可靠性-偏执的海盗模式
虽然说“简单的海盗模式”已经非常靠谱了,不过瑕疵还是有不少的。比如说,中间件队列并不监控后端的worker死活,至少会有一次丢包来确定那个worker已经不在了(虽然问题不大,但终究不爽)。而在“偏执的”模式中,有对“简单”模式做了一些扩展:[img]https://github.com/imatix/zguide/raw/master/images/fig59.png[/img]Qu...2011-05-05 19:05:04 · 243 阅读 · 0 评论 -
zeroMQ初体验-26.可靠性-管家模式
上一节末尾有说到协议,zeromq自然做了充沛的封装,"管家模式"便由此而来。[img]https://github.com/imatix/zguide/raw/master/images/fig60.png[/img]是不是有点像简化版的"偏执模式"?这里的“broker”需要做到"承上启下"。因为这是"协议"的具体实现,自然,这里以api形式给出各个角色的相应实现。为客户端...2011-05-12 19:05:25 · 292 阅读 · 0 评论 -
zeroMQ初体验-11.节点间的协作
上一篇讲到了线程间的协作,通过zeroMQ的pair模式可以很优雅的实现。而在各节点间(进程级),则适用度不高(虽然也能用)。这里给出了两个理由:1.节点间是可以调节的,而线程间不是(线程是稳定的),pair模式是非自动连接的.2.线程数是固定的,可预估的。而节点则是变动、不可预估的。由此得出结论:pair适用于稳定、可控的环境。所以,有了本章节。不知诸位还记得前面所讲的[ur...2011-03-30 16:30:19 · 135 阅读 · 0 评论 -
zeroMQ初体验-10.优雅的使用多线程
"或许,ZeroMQ是最好的多线程运行环境!"官网如是说。其实它想要支持的是那种类似erlang信号模式。传统多线程总会伴随各种"锁"出现各种稀奇古怪的问题。而zeroMQ的多线程致力于"去锁化",简单来说,一条数据在同一时刻只允许被一个线程持有(而传统的是:只允许被一个线程操作)。而锁,是因为可能会出现的多线程同时操作一条数据才出现的副产品。从这里就可以很清晰的看出zeromq的切入点了...2011-03-25 21:31:57 · 795 阅读 · 0 评论 -
zeroMQ初体验-9.优雅的扩展(代理模式)
前面所谈到的网络拓扑结构都是这样的:[img]http://github.com/imatix/zguide/raw/master/images/fig15.png[/img]而在实际的应用中,绝大多数会出现这样的结构要求:[img]http://github.com/imatix/zguide/raw/master/images/fig16.png[/img]zeroMQ...2011-03-25 19:20:19 · 168 阅读 · 0 评论 -
zeroMQ初体验-28.可靠性-主从模式
虽然[url=http://iyuan.iteye.com/blog/1055228]"硬盘模式"[/url]看起来已经非常靠谱了,不过,还记得前段时间"亚马逊云拓机"么,异地灾备似乎才能真正当的上'高可用',暂且抛开物理、成本上的问题,zeromq也为此提供了靠谱的支持~官方声明:1.这是一个直接的高可用的方案2.足够简单,让人易于理解和使用3.在需要时可以提供可靠的转移...2011-05-23 14:47:51 · 253 阅读 · 0 评论 -
zeroMQ初体验-29.可靠性-自由模式
好吧,本以为这可能是一个更靠谱的模式,谁知(其实是我一厢情愿了)。所谓自由模式,自然是--爱咋咋地 呃。。作为还算靠谱的官方,终是给出了一些经过验证的"自由模式"的模型。下面就来一一拆解吧。[b]简单重试和故障转移[/b]好像有点眼熟,其实有用到"[url=http://iyuan.iteye.com/blog/1030370]懒人模式[/url]"的简单重试,并且对服务...2011-05-24 17:02:16 · 204 阅读 · 0 评论 -
zeroMQ初体验-30.发布/订阅模式进阶-自裁的蜗牛订阅者
在初次介绍[url=http://iyuan.iteye.com/blog/973013]发布/订阅[/url]模式的时候,就已经抖出了这个包袱:如果订阅者的消费速度慢,则会造成发布者端队列堆积,怎么办?本篇即是针对可能出现的"蜗牛"般的订阅者而生。通常的做法:在发布端用靠谱的队列承接来不及被消费的信息,这样会增大发布端的压力。在订阅端用靠谱的队列承接来不及消费的信息,压力转嫁给各...2011-05-25 16:24:29 · 133 阅读 · 0 评论 -
zeroMQ初体验-31.发布/订阅模式进阶-黑盒的高速订阅者
作为发布/订阅模式的一个常用场景,大数据量的组播是有必要的。虽然100k/s的数度对于zeromq实在稀松平常,不过,谁会介意更快呢。模型图:[img]https://github.com/imatix/zguide/raw/master/images/fig66.png[/img]提高效率的核心在于充分利用硬件资源,比如多核的cpu,多线程即为此而生(可惜python没有)。...2011-05-25 16:55:05 · 126 阅读 · 0 评论 -
zeroMQ初体验-32.发布/订阅模式进阶-克隆模式-上
在发布/订阅模式中,特别是现实应用中,总会因为这样那样的问题导致订阅者丢失了所需的数据,如此,便有了重新获得的需求。通常来说,这个会由订阅者来完成,不过"千百个哈姆雷特"从工程的角度来看,实在不忍睹,完全违背了"复用"的概念。于是乎,"克隆模式"便呼之待出了。在发布端存储下这些消息,为了避免队列的堆积这样的杯具,也为了更好的订阅体验,kev-value似乎是不错的选择。注意:这里的kev-...2011-05-26 15:04:13 · 189 阅读 · 0 评论 -
zeroMQ初体验-33.发布/订阅模式进阶-克隆模式-中
[b]临时缓存[/b]现实中,比如DNS服务器,可以算是一个典型案例。临时存储一个节点,如果节点小时,那么该存储也会随之灰飞,所以,"过期"也是一个靠谱的需求。由于有新的需求提出,我们的key-value库也得做些相应的改动:[code="c"]/* =================================================================...2011-05-26 15:37:05 · 188 阅读 · 0 评论 -
zeroMQ初体验-34.发布/订阅模式进阶-克隆模式-下,结言
服务器:[code="c"]//// Clone server Model Six//// Lets us build this source without creating a library#include "bstar.c"#include "kvmsg.c"// Bstar reactor handlersstatic int s_sna...2011-05-26 16:09:11 · 271 阅读 · 0 评论 -
关于python和rabbitmq的那点事儿
rabbitmq是一个消息中间件,在之前的zmq介绍中有略带提过。由于zmq的硬伤(无法方便存储、监控中间过程),故而工作中一直都是使用的"兔子"。从1.7.0到现在的2.6.1版本(个人尝试过的),rabbitmq有着许多令人欣喜、惊叹的变化(或者说是进步)。 先来简单介绍下当前版本"兔子"的闪光点:1.内置了ha,如果组建cluster,负载均衡之类的问题就无需担忧了。2....2011-10-19 14:15:40 · 177 阅读 · 0 评论 -
zeroMQ初体验-1.简介及C/S模式
本来是想做个翻译的,奈何英文太差,还是逐个的对zeroMQ各用法进行简析,文中代码主要来自pyzmq中的example,详细原文请自行参看[url=http://zguide.zeromq.org/page:all]这里[/url],也不清楚有没有兄台做过类似工作,这里主要供自个儿学习备忘,如有谬误,欢迎指出~简介: ØMQ (ZeroMQ, 0MQ, zmq),这一堆表达方式看哪个顺...2011-03-23 17:53:04 · 479 阅读 · 0 评论 -
zeroMQ初体验-2.发布订阅模式(pub/sub)
pub/sub模式:[img]http://github.com/imatix/zguide/raw/master/images/fig4.png[/img]发布端(pub)[code="python"]import itertoolsimport sys import time import zmq ...2011-03-23 19:43:58 · 476 阅读 · 0 评论 -
zeroMQ初体验-3.分而治之模式(push/pull)
push/pull模式:[img]http://github.com/imatix/zguide/raw/master/images/fig5.png[/img]模型描述:1.上游(任务发布)2.工人(中间,具体工作)3.下游(信号采集或者工作结果收集)上游代码:[code="python"]import zmqimport randomimpo...2011-03-24 14:52:27 · 421 阅读 · 0 评论 -
zeroMQ初体验-4.传教(为什么要用ZeroMQ?)
既然是读书笔记,按照顺序,原作者在这里"唠嗑"了一大堆Why,看的着实有些热血沸腾,幸而也是他的对头"兔子"的簇拥,略带客观的说说:zeroMQ从某种层面上甚至都不能称为软件(或许连工具都称不上)。它只是一套组件,封装了复杂的网络、进程等连接环境,向上提供API,由各个语言编写对应类库,正式运用环境是通过调用对应的类库来实现的。从自由的角度来说,它是去中心化的,自由度极高;而从安全...2011-03-24 16:33:21 · 126 阅读 · 0 评论 -
zeroMQ初体验-5.高级教程初涉
诸位在前面的例子中,已经可以发现所有的关系都是成对匹配出现的。之前已经使用的几种模式:req/rep(请求答复模式):主要用于远程调用及任务分配等。pub/sub(订阅模式):主要用于数据分发。push/pull(管道模式):主要用于多任务并行。除此之外,还有一种模式,是因为大多数人还么有从"TCP"传统模式思想转变过来,习惯性尝试的独立成对模式(1to1).这个在后面会有...2011-03-24 19:03:47 · 154 阅读 · 0 评论 -
zeroMQ初体验-6.多模式数据来源处理方案(multi sockets)
之前已经讲过,zeroMQ是可以多对多的,但需要成对匹配才行,即多个发布端都是同一种模式,而这里要涉及到的是,多个发布端模式不统一的情况。文中先给出了一个比较"脏"的处理方式:[code="python"]import zmqimport timecontext = zmq.Context()receiver = context.socket(zmq.PULL)...2011-03-24 20:30:26 · 238 阅读 · 0 评论 -
zeroMQ初体验-7.优雅的卸载工作进程
关掉一个进程有很多种方式,而在ZeroMQ中则推崇通过使用信号通知,可控的卸载、关闭进程。在这里,要援引之前的"分而治之"例子(具体可以见[url=http://iyuan.iteye.com/blog/974040]这里[/url])。例图:[img]http://github.com/imatix/zguide/raw/master/images/fig14.png[/img]...2011-03-25 14:19:49 · 214 阅读 · 0 评论 -
zeroMQ初体验-8.内存泄漏了?
写过"永不停歇"的代码的兄弟应该都或多或少遇到或考虑到内存溢出之类的问题,那么,在ZeroMQ的应用中,又如何处理如是情况?文中给出了类C这种需要自行管理内存的解决方案(虽然python的GC很强大,不过,关注下总没有坏处):这里运用到了这个工具:valgrind为了避免zeromq中的一些warning的干扰,首先需要重新build下zermq[list][*]$ c...2011-03-25 15:00:27 · 623 阅读 · 0 评论 -
IM选型(初)
主要参考文章: [url]https://ruby-china.org/topics/22530[/url]因为文章本身的时效性,目前在协议端个人还是更加看好MQTT:[url]https://github.com/mqtt/mqtt.github.io/wiki/servers[/url]服务器选型的话,如果是考虑到现有后台coder, 建议选java 框架的;否则建议选择Erl...原创 2016-08-23 19:12:33 · 335 阅读 · 0 评论