ZeroMQ 研究与应用分析

husnp

贡献于2014-07-11

字数:0 关键词: 消息中间件

ZeroMQ 研究与应用分析 2013-03-31 19:36:42 1 ZeroMQ 概述 ZeroMQ 是一种基于消息队列的多线程网络库,其对套接字类型、连接处理、 帧、甚至路由的底层细节进行抽象,提供跨越多种传输协议的套接字。ZeroMQ 是网络通信中新的一层,介于应用层和传输层之间(按照 TCP/IP 划分),其是一 个可伸缩层,可并行运行,分散在分布式系统间。 2 系统架构 2.1 总体架构 ZeroMQ 几乎所有的 I/O 操作都是异步的,主线程不会被阻塞。ZeroMQ 会根 据用户调用 zmq_init 函数时传入的接口参数,创建对应数量的 I/O Thread。每 个 I/O Thread 都有与之绑定的 Poller,Poller 采用经典的 Reactor 模式实现, Poller 根据不同操作系统平台使用不同的网络 I/O 模型(select、poll、epoll、 devpoll、kequeue 等)。主线程与 I/O 线程通过 Mail Box 传递消息来进行通信。 Server 开始监听或者 Client 发起连接时,在主线程中创建 zmq_connecter 或 zmq_listener,通过 Mail Box 发消息的形式将其绑定到 I/O 线程,I/O 线程会 把 zmq_connecter 或 zmq_listener 添加到 Poller 中用以侦听读/写事件。Server 与 Client 在第一次通信时,会创建 zmq_init 来发送 identity,用以进行认证。 认证结束后,双方会为此次连接创建 Session,以后双方就通过 Session 进行通 信。每个 Session 都会关联到相应的读/写管道, 主线程收发消息只是分别从管 道中读/写数据。Session 并不实际跟 kernel 交换 I/O 数据,而是通过 plugin 到 Session 中的 Engine 来与 kernel 交换 I/O 数据。 图1 总体架构 2.2 所处层次 ZeroMQ 不是单独的服务或者程序,仅仅是一套组件,其封装了网络通 信、消息队列、线程调度等功能,向上层提供简洁的 API,应用程序通过加载库 文件,调用 API 函数来实现高性能网络通信。 图2 所处层次 2.3 消息模型 ZeroMQ 将消息通信分成4种模型,分别是一对一结对模型(Exclusive-Pair)、 请求回应模型(Request-Reply)、发布订阅模型(Publish-Subscribe)、推拉模 型(Push-Pull)。这4种模型总结出了通用的网络通信模型,在实际中可以根据 应用需要,组合其中的2种或多种模型来形成自己的解决方案。 2.3.1 一对一结对模型 最简单的1:1消息通信模型,可以认为是一个 TCP Connection,但是 TCP Server 只能接受一个连接。数据可以双向流动,这点不同于后面的请求回 应模型。 2.3.2 请求回应模型 由请求端发起请求,然后等待回应端应答。一个请求必须对应一个回应,从 请求端的角度来看是发-收配对,从回应端的角度是收-发对。跟一对一结对模型 的区别在于请求端可以是1~N 个。该模型主要用于远程调用及任务分配等。Echo 服务就是这种经典模型的应用。 图3 请求回应模型 2.3.3 发布订阅模型 发布端单向分发数据,且不关心是否把全部信息发送给订阅端。如果 发布端开始发布信息时,订阅端尚未连接上来,则这些信息会被直接丢弃。订阅 端未连接导致信息丢失的问题,可以通过与请求回应模型组合来解决。订阅端只 负责接收,而不能反馈,且在订阅端消费速度慢于发布端的情况下,会在订阅端 堆积数据。该模型主要用于数据分发。天气预报、微博明星粉丝可以应用这种经 典模型。 图4 发布订阅模型 2.3.4 推拉模型 Server 端作为 Push 端,而 Client 端作为 Pull 端,如果有多个 Client 端同 时连接到 Server 端,则 Server 端会在内部做一个负载均衡,采用平均分配的算 法,将所有消息均衡发布到 Client 端上。与发布订阅模型相比,推拉模型在没 有消费者的情况下,发布的消息不会被消耗掉;在消费者能力不够的情况下,能 够提供多消费者并行消费解决方案。该模型主要用于多任务并行。 图5 推拉模型 2.4 通信协议 提供进程内、进程间、机器间、广播等四种通信协议。通信协议配置简单, 用类似于 URL 形式的字符串指定即可,格式分别为 inproc://、ipc://、tcp://、 pgm://。ZeroMQ 会自动根据指定的字符串解析出协议、地址、端口号等信息。 3 工作流程 图6 基本流程 4 性能分析 目前,市面上类似的产品不少,主要有4种:MSMQ(微软产品)、ActiveMQ (Java)、RabbitMQ(Erlang)、ZeroMQ(C++)。除 ZeroMQ 外,其它3款产品都是 一个单独服务或者进程,需要单独安装和运行,且对环境有一定依赖。其中,MSMQ 在非 Windows 平台下安装非常复杂,ActiveMQ 需要目标机器上已经安装了 Java, RabbitMQ 需要 Erlang 环境。而 ZeroMQ 是以库的形式存在,由应用程序加载、 运行即可。但是 ZeroMQ 仅提供非持久性的消息队列。 图7是来自于 Internet 的性能测试数据。显示的是每秒钟发送和接受的消息 数。整个过程共产生1百万条1K 的消息,测试环境为 Windows Vista。从测试数 据可以看出,ZeroMQ 的性能远远高于其它3个 MQ。 但是测试数据仅供参考,因为缺少必须的环境参数和性能指标,比如:CPU 参数、内存参数、消息模型、通信协议、极限时消耗 CPU 百分比、极限时消耗内 存百分比等。 图7 性能测试 5 应用场景 应用 ZeroMQ 的 Push-Pull 模型实现联众游戏服务器的“热插拔”、负载均 衡和消息派发。按照如图8部署服务器,Push 端充当 Gateway,作为一组游戏服 务器集群最上层的一个 Proxy,起负载均衡的作用,所有 Gameserver 作为 Pull 端。当一个请求到达 Push 端(Gateway)时,Push 端根据一定的分配策略将任 务派发到 Pull 端(Gameserver)。以联众某款游戏 A 为例,游戏 A 刚上线时,预 计最大同时在线人数是10W,单台 Gameserver 并发处理能力为1W,需要10台 Gameserver,由于游戏 A 可玩性非常好,半个月后最大同时在线人数暴增到50W, 那么不需要在某天的凌晨将 Gateway 和 Gameserver 停机,只需要随时在机房新 添加40台 Gameserver,启动并连接到 Gateway 即可。 ZeroMQ 中对 Client 和 Server 的启动顺序没有要求,Gameserver 之间如果 需要通信的话,Gameserver 的应用层不需要管理这些细节,ZeroMQ 已经做了重 连处理。 图8 应用场景 6 总结 6.1 简单 1、仅仅提供24个 API 接口,风格类似于 BSD Socket。 2、处理了网络异常,包括连接异常中断、重连等。 3、改变 TCP 基于字节流收发数据的方式,处理了粘包、半包等问题,以 msg 为 单位收发数据,结合 Protocol Buffers,可以对应用层彻底屏蔽网络通信层。 4、对大数据通过 SENDMORE/RECVMORE 提供分包收发机制。 5、通过线程间数据流动来保证同一时刻任何数据都只会被一个线程持有,以此 实现多线程的“去锁化”。 6、通过高水位 HWM 来控制流量,用交换 SWAP 来转储内存数据,弥补 HWM 丢失数 据的缺陷。 7、服务器端和客户端的启动没有先后顺序。 6.2 灵活 1、支持多种通信协议,可以灵活地适应多种通信环境,包括进程内、进程间、 机器间、广播。 2、支持多种消息模型,消息模型之间可以相互组合,形成特定的解决方案。 6.3 跨平台 支持 Linux、Windows、OS X 等。 6.4 多语言 可以绑定 C、C++、Java、.NET、Python 等30多种开发语言。 6.5 高性能 相对同类产品,性能卓越。

下载文档,方便阅读与编辑

文档的实际排版效果,会与网站的显示效果略有不同!!

需要 10 金币 [ 分享文档获得金币 ] 1 人已下载

下载文档

相关文档