消息队列及中转软件总结汇编.doc

消息队列及中转软件总结摘要ZeroMQ ActiveMQ Redis MongoDB Memcached 都是开源产品，都可以实现消息中转的功能，但各有不同。ZeroMQ ActiveMQ 消息中转实现形式为队列形式，分布式、集群服务助手。 Redis MongoDB 较成熟的非结构性数据库产品， key-value 数据库，结构松散 的文本型数据库。Memcached高性能的分布式内存对象缓存系统，数据读写速度内存级别。MQ消息队列消息队列（MQ）是一种 应用程序对应用程序的通信方法 。应用程序通过写和 检索出入列队的数据（消息）来通信，而无需专用连接来链接它们。消息传递指 的是程序之间通过在消息中发送数据进行通信，而不是通过直接调用彼此来通 信，直接调用通常是用于诸如远程过程调用的技术。 排队指的是应用程序通过队 列来通信。 队列的使用除去了接收和发送应用程序同时执行的要求， 一般情况下 都需要有一个队列维护服务。 消息服务器在分布式系统各应用间消息通信起到了 至关重要的作用。ZeroMQZeroMQ是一种基于消息队列的多线程网络库， 其对套接字类型、 连接处理、 帧、 甚至路由的底层细节进行抽象，提供跨越多种传输协议的套接字。 ZeroMQ 是非 典型的消息中间件，而且更像是一个网络通信框架ZeroMQ 是网络通信中新的一层，介于应用层和传输层之间（按照TCP/IP划分），其是一个可伸缩层，可并行运行，分散在分布式系统间。ZeroMQ 号称是最快的消息队列系统，尤其针对大吞吐量的需求场景。 ZMQ 能够实现 RabbitMQ 不擅长的高级 / 复杂的队列，但是开发人员需要自己组合多 种技术框架，技术上的复杂度是对 ZMQ能够应用成功的挑战。 ZeroMQ 具有一个 独特的非中间件的模式， 甚至不需要安装和运行一个消息服务器或中间件， 因为 应用程序将扮演这个服务角色。只需要简单的引用 ZeroMQ 程序库，然后就可以 愉快的在应用程序之间发送消息了。但是 ZeroMQ 仅提供非持久性的队列，也就是说如果 down 机，数据将会丢失。其中， Twitter 的 Storm 中使用 ZeroMQ 作 为数据流的传输。ZMQ是个类似于 Socket 的一系列接口，他跟 Socket 的区别是普通的 Socket 是端到端的 (1:1 的关系)，而 ZMQ却是可以 N：M 的关系 ，人们对 BSD 套接字的了解较多的是点对点的连接， 点对点连接需要显式地建立连接、 销毁连 接、选择协议( TCP/UDP)和处理错误等，而 ZMQ屏蔽了这些细节，让你的网络 编程更为简单 。ZMQ用于 node 与 node 间的通信，node 可以是主机或者是进程。ZeroMQ 不是单独的服务或者程序， 仅仅是一套组件， 其封装了网络通信、 消 息队列、线程调度等功能，向上层提供简洁的 API ，应用程序通过加载库文件， 调用 API 函数来实现高性能网络通信。ZeroMQ消息模型ZeroMQ将消息通信分成 4 种模型，分别是一对一结对模型 (Exclusive-Pair )、 请求回应模型( Request-Reply )、发布订阅模型( Publish-Subscribe )、 推拉模型( Push-Pull )。这 4 种模型总结出了通用的网络通信模型，在实际中 可以根据应用需要，组合其中的 2 种或多种模型来形成自己的解决方案。1. 一对一： TCP Connection ，TCP Sever 只能接受一个连接，数据双向流动2. 请求回应： 一个服务端对应多个客户端， 每个请求服务端都会给一个回应， 相 当于 1 对 N的方式。3. 发布订阅模型：发布端单向分发数据， 且不关心是否把全部信息发送给订阅端， 天气预报、微博明星粉丝可以应用这种经典模型。4. 推拉模型： Server 端为 push 端，Client 端为 pull 端，如果有多个 Client 端同时连接到 Server 端，则 Server 端会在内部做一个负载均衡，采用平均分 配的算法，均衡推送，改模型主要用于多任务并行。ZeroMQ通信协议： 提供进程内、进程间、机器间、广播等四种通信协议，支持 的具体协议类型有： inproc 、 ipc 、tcp 、 pgm。用类似于 URL形式的字符串指定即可，格式分别为 inproc:/ 、 ipc:/ 、 tcp:/ 、pgm:/ 。 ZeroMQ会自动根据指定的字符串解析出协议、地址、端口 号等信息。支持常用的多种语言客户端 C+ 、Java 、.Net 、 Python 、 Php 、 Ruby 等。 ZeroMQ性能目前，市面上类似的产品不少， 主要有 4 种：MSM（Q 微软产品） 、ActiveMQ （Java ）、RabbitMQ（Erlang） 、ZeroMQ（C+）。除 ZeroMQ外，其它 3 款产 品都是一个单独服务或者进程， 需要单独安装和运行， 且对环境有一定依赖。 其 中， MSMQ在非 Windows 平台下安装非常复杂， ActiveMQ 需要目标机器上已经 安装了 Java ，RabbitMQ 需要 Erlang 环境。而 ZeroMQ 是以库的形式存在，由 应用程序加载、运行即可。但是 ZeroMQ 仅提供非持久性的消息队列。下图是来自 Internet 的性能测试数据。显示的是每秒钟发送和接受的消息 数。整个过程共产生 1 百万条 1K 的消息，测试环境为 Windows Vista 。从测试 数据可以看出， ZeroMQ的性能远远高于其它 3 个 MQ。ZeroMQ优点：简单1、仅仅提供 24 个 API 接口，风格类似于 BSD Socket 。2、处理了网络异常，包括连接异常中断、重连等。3、改变 TCP基于字节流收发数据的方式，处理了粘包、半包等问题，以msg 为单位收发数据，结合 Protocol Buffers ，可以对应用层彻底屏蔽网络通信层。4、对大数据通过 SENDMORE/RECVMO提RE供分包收发机制。5、通过线程间数据流动来保证同一时刻任何数据都只会被一个线程持有，以此 实现多线程的“去锁化”。6、通过高水位 HWM来控制流量，用交换 SWAP来转储内存数据，弥补 HWM丢失 数据的缺陷。7、服务器端和客户端的启动没有先后顺序。灵活1、支持多种通信协议，可以灵活地适应多种通信环境，包括进程内、进程间、 机器间、广播。2、支持多种消息模型，消息模型之间可以相互组合，形成特定的解决方案。 跨平台支持 Linux 、Windows、OS X 等。多语言可以绑定 C、C+、Java、.NET、Python 等30 多种开发语言。高性能 相对同类产品，性能卓越。ActiveMQActiveMQ 是 Apache 下的一个子项目。 类似于 ZeroMQ，它能够以代理人 和点对点的技术实现队列。 它用少量代码就可以高效地实现高级应用场景。 是流 行的，能力强劲的开源消息总线。语言和协议语言：支持常用的多种语言客户端 C+ 、Java 、.Net 、 Python 、Php、 Ruby 等，其中 Java 环境资料比较多。应用协议： OpenWire,Stomp REST,WS Notification,XMPP,AMQP 。 传送协议： in-VM,TCP,SSL,NIO,UDP,JGroups,JXTA 。其他ActiveMQ 可以很容易内嵌到使用 Spring 的系统里面去 支持通过 JDBC和 journal 提供高速的消息持久化 从设计上保证了高性能的集群，客户端 - 服务器，点对点 可以很容易得调用内嵌 JMS provider 服务端与 Java 客户端通信实例已完成RabbitMQ是使用 Erlang 编写的一个开源的消息队列， 支持很多的协议 AMQP，XMPP, SMTP, STOMP，也正是如此，使的它变的非常重量级，更适合于企业级的开发。 同时实现了一个经纪人 (Broker) 构架，这意味着消息在发送给客户端时先在中心队列排队。对路由 (Routing) ，负载均衡 (Load balance) 或者数据持久化都 有很好的支持，适合于在分布式集群系统中做消息中转服务。Redis 、 MongoDB、Memcache是一个 Key-Value 的 NoSQL数据库，开发维护很活跃，虽然它是一个 Key-Value 数据库存储系统，但它本身支持 MQ功能，所以完全可以当做一个轻 量级的队列服务来使用。对于 RabbitMQ 和 Redis 的入队和出队操作， 各执行 100 万次， 每 10 万次 记录一次执行时间。测试数据分为 128Bytes 、512Bytes 、1K和 10K四个不同 大小的数据。实验表明入队时，当数据比较小时 Redis 的性能要高于 RabbitMQ ， 而如果数据大小超过了 10K， Redis 则慢的无法忍受；出队时，无论数据大小， Redis 都表现出非常好的性能，而 RabbitMQ 的出队性能则远低于 Redis 。项目入队出队数据量128B512B1K10K128B512B1K10KRedis160881596117094251595520449180989355RabbitMQ106279916937023663219317429821588MongoDB和 Redis 都是 NoSQL数据库。二者在使用场景中，存在一定的区 别，这也主要由于二者在内存映射的处理过程， 持久化的处理方法不同。 MongoDB 建议集群部署， 更多的考虑到集群方案， Redis 更偏重于进程顺序写入， 虽然支持集群，也仅限于主 - 从模式hashmap。其守护进程( daemon)是用 C 写的，但是客户端可以用任何语言来 编写，并通过 memcached 协议与守护进程通信。MongoDB与 Redis 对比说明指标MongoDBRedis比较说明实现语言C+C/C+协议BSON、自定义二进制类 Telnet性能依赖内存依赖内存， TPS 高Redis 优于 MongoDB可操作性丰富的数据表达、索引；最 类似于关系数据库， 支持丰 富的查询语言数据丰富，较少的 IOMongoDB 优于 Redis内存及存储适合大数据量存储， 依赖系 统虚拟内存管理， 采用镜像 文件存储； 内存占有率比较 高，官方建议部署在 64 位 操作系统上Redis2.0 后增加虚拟 内存特性，突破物理内 存限制；数据可以设置 时效性，类似于 Memcache不用应用角度，各有优势可用性支 持 master-slave 、 replicaset（ 内 部 采 用 poxos 选举算法， 自动故障 恢复 ） ， auto sharding 机 制，对客户端屏蔽了故障转 移和切分机制依赖客户端来实现分布 式读写；主从复制时， 每次从节点重新连接主 节点都要依赖整个快 照，无增量复制；不支 持自动 sharding ，需要 依赖程序设定一致 hash 机制MongoDB 优于 Redis ， 单点问题上， MongoDB 应用简单，相对用户透 明， Redis 比较复制， 需要客户 主动 解决 。 MongoDB 一 般会使 用 replicasets 和 sharding 功能结合， replica sets侧重高可用性及高可靠性，而 sharding 侧 重 于 性 能、易扩展可靠性从 1.8 版本后，采用 binLog 方式（ MySQL同样 采用该方式）支持持久化， 增加可靠性依赖快照进行持久化；AOF增强可靠性； 增强可 靠性的同时，影响访问 性能MongoDB 优于 Redis一致性不支持事物， 靠客户端自身 保证支持事物，比较弱，仅 能保证事物中的操作按 顺序执行Redis 优于 MongoDB数据分析内置数据分析功能不支持MongoDB 优于 Redis应用场景海量数据的访问效率提升较小数据量的性能及运算MongoDB 优于 Redis