zeromqstorm本地模式是不是本地程序直接可以跑起来？

在云服务器上，如何使用 zeromq 进行广播消息

你好。

建立了 VPS 虚拟服务器(windows server)，然后安装了 python 和 zero mq。

写了一个简单的 pub/sub 程序， pub 端放在 VPS 这里。

你的采纳是我前进的动力，记得好评和采纳，互相帮助， 如果我的回答没能帮助您，请继续追问。

zeromq解决了什么问题

很早就听说了zeromq 这个项目,当时不太在意. 后来同事kasicass 对这个项目做了研究和分享 ,开始重视起这个项目来. 1) libevent封装了对网络I/O,信号,定时器等的处理,可以基于它之上做网络层的开发. 2) ACE封装了不同平台下的系统调用,也提供好几种网络编程的模型. 然而,zeromq不是libevent,也不是ACE,因为它的主要特性是:面向消息进行通信.所以,它提供的是比libevent,ACE处在网络通信中更高一层的组件.使用它,程序员不再需要上面提到的libevent,ACE之类的库需要关心的东西,程序员如果要使用zeromq,只需要做如下的事情: 1) 告知所使用的patten,比如request-reply,pub-sub,push-pull等(下面会详细解释这个pattern). 2) 告知是用于机器之间,还是进程之间,线程之间的通信. 然后,将所需要发送的数据封装到zeromq自带的msg结构体中发送出去,使用者自己关心如何序列化/反序列化这些数据,然后如何处理这些数据就是使用者的事情了.这样看上来,使用者要关注的事情”高”了一层,大部分的精力都可以放在业务逻辑之上了.简而言之,它让使用者的精力放在了通信模式和业务逻辑上,而不是更下面一层的网络层上.下面解释一下zeromq常用的几种网络pattern: 1) request-reply 就是一般的C/S架构中,client与server之间一问一答的通信模式,比如最经典的echo服务.需要注意的是,client发送一个request,server必须有一个回应. server端作为publish端,而任何连接到服务端的client都会成为subscribe端.也就是说,server端会把当前的所有需要publish出去的消息全部发送到当前连接上去的client上.3) push-pull server端作为push端,而client端作为pull端.如果有多个client端同时连接到这个server,则服务器会在内部做一个负载均衡,采用平均分配的算法,将所有的消息均衡发布到client端上.看上去,很稀松平常?接下来亮点真的来了. 考虑如下一种场景.一个server端做为一组服务器集群最上层的一个proxy,起到负载均衡的作用,将请求按照它下面对应服务器集群依次派发到不同的 client端进行处理.某个时刻可能处理的机器只有2台,而随着负载越来越大,可能需要3台机器了,这个时候如果使用zeromq的push-pull 搭建的proxy端,则可以不用对之前搭建的server,client端进行停机,只需要新启动一个client连接上去,proxy层就会自动根据当前的机器分配平均派发任务了.cool.实际上,这些模式并不是什么新东西,只不过zeromq为使用者做了一个封装,而不是像libevent,ACE等还局限在网络层部分的封装,它关注的是通信层,通信模式等.个人感觉,zeromq部分解决 了erlang所要解决的问题:在多台机器中通信,派发任务等,是分布式通信的利器,但是局限于语言的限制,它没有办法做的跟erlang一样的完善(erlang已经可以算的上一个简易微型的OS了),但是许多的时候,似乎只使用这一部分功能也就足够了.zeromq的代码量,截至到我目前阅读的2.0.10-stable版本,也只有不到2W行代码.提供出去的API也极为简单,但是内部的实现比较”绕”,zeromq是我阅读过的项目中少数的非常需要依赖调试工具跟进代码才能看懂代码流程的项目,同时代码中类的继承层次也比较多,阅读起来并不像它提供的API那样简单直白.后续会对其中的一些难点做一些分析.

ZMQ JAVA使用经验之 ZMQ简介怎么解决

ZMQ JAVA使用经验之 ZMQ简介怎么解决： ZMQ被称为史上最快消息队列，它处于会话层之上，应用层之下，使用后台异步线程完成消息的接受和发送，完美的封装了Socket API，大大简化了编程人员的复杂度，被称为史上最强大的消息中间件。

ZMQ是用C语言编写的，30s内完成消息的传输，能够兼容多个平台，多种语言，可以使用多种方式实现N对N的Socket连接。

本文仅以JAVA版本的ZMQ API为例，介绍ZMQ。

ZMQ与传统的TCP Socket相比，具有以下优点: 1） ZMQ发送和接受的是具有固定长度的二进制对象，ZMQ的消息包最大254个字节，前6个字节是协议，然后是数据包。

数据包由3个部分组成，第一个字节是包的长度，第二个字节是包的一些属性，最后是包的内容。

如果超过255个字节（有一个字节表示包属性），则ZMQ会自动分包传输；而对于TCP Socket，是面向字节流的连接，编程人员需要处理数据块与数据块之间的边界问题，而ZMQ能够保证每次用户发送和接受的都是一个完整的数据块； 2) 传统的TCP Socket的连接是1对1的，可以认为“1个Socket=1个连接”，每一个线程独立的维护一个Socket。

但是ZMQ摒弃了这种1对1的模式，ZMQ的Socket可以很轻松的实现1对N，N对1和N对N的连接模式，一个ZMQ的Socket可以自动的维护一组连接，用户无法操作这些连接，用户只能操作套接字，而不是连接本身，所以说ZMQ的世界里，连接是私有的。

这里大家关心的一点是，一个Socket是如何识别来自多个Socket的连接的，这里以请求响应模式为例介绍ZMQ是如何实现一个Socket连接N个Socket的； 3）ZMQ使用异步后台线程处理接受和发送请求，这意味着发送完消息，不可以立即释放资源，消息什么时候发送用户是无法控制的，同时，ZMQ自动重连，这意味着用户可以以任意顺序加入到网络中，服务器也可以随时加入或者退出网络； ZMQ之所以能够在无状态的网络中实现1对N的连接，关键在于信封的机制，信封里保存了应答目标的位置。

ZMQ涉及到请求-响应模式的Socket一共有4种类型： DEALER是一种负载均衡，它会将消息分发给已连接的节点，并使用公平队列的机制处理接受到的消息。

REQ发送消息时会在消息顶部插入一个空帧，接受时会将空帧移去。

其实REQ是建立在DEALER之上的，但REQ只有当消息发送并接受到回应后才能继续运行。

ROUTER在收到消息时会在顶部添加一个信封，标记消息来源。

发送时会通过该信封决定哪个节点可以获取到该条消息。

REP在收到消息时会将第一个空帧之前的所有信息保存起来，将原始信息传送给应用程序。

在发送消息时，REP会用刚才保存的信息包裹应答消息。

REP其实是建立在ROUTER之上的，但和REQ一样，必须完成接受和发送这两个动作后才能继续。

在了解了4种类型的Socket之后，我们就不难理解ZMQ的信封机制了。

ZMQ信封机制的核心是Router Socket，它的工作原理如下： 从ROUTER中读取一条消息时，ZMQ会包上一层信封，上面注明了消息的来源。

向ROUTER写入一条消息时（包含信封），ZMQ会将信封拆开，并将消息递送给相应的对象。

当REQ Socket向ROUTER Socket发送一条请求后，REP会从ROUTER收到一条消息，消息格式如下： 第三帧是REP从应用程序收到的数据，第二帧是空帧，是REQ在发送ROUTER数据之前添加的，用来表示结束，第一帧即信封，是ROUTER添加的，主要用来记录消息来源；整个数据包处理过程如下： 对于REQ Socket，可以在创建Socket的时候，为该Sock指定标示符，此时的Socket称为持久Socket，没有指定标示符的我们称为瞬时Socket，ROUTER会自动为瞬时Socket生成一个标示符； 这样REP返回包含信封的数据给ROUTER，ROUTER就可以根据信封上的标示符将该消息发送到对应的REQ上； ZMQ使用注意事项： ZMQ是在发送端缓存消息的，可以通过阈值控制消息的溢出； ZMQ不可以线程之间共享Socket，否则会.zeromq.ZMQException: Operation cannot be plished in current state错误。

ZMQ一个进程只允许有一个Context，new Context(int arg) arg表示后台线程的数量； ZMQ的Socket类有一个Linger参数，可以通过SetLinger设置，主要用于表示该Socket关闭以后，未发送成功的消息是否还保存，如果设置为-1表示该消息将永久保存（除非宕机，ZMQ是不持久化消息的），如果为0表示所有未发送成功的消息在Socker关闭以后都将立即清除，如果是一个正数，则表示该消息在Socket关闭后多少毫秒内被删除；这个方法非常有用，尤其在控制发送失败时，是否重发消息。

storm本地模式是不是本地程序直接可以跑起来？

1.jpg 支持的,0.9开始支持得好一些在以前的版本里，如果想在Windows平台上运行Storm，你需要安装ZeroMQ，修改Storm的源码，追加一些Windows平台特定的脚本。

而在新的版本里，因为ty替换了ZeroMQ，由ty用纯java实现，因此使得Storm具有更好的跨平台特性，现在要在Windows上运行Storm比以前容易很多。