消息队列及中转软件总结

消息队列及中转软件总结摘要ZeroMQActiveMQRedisMongoDBMemcached都是开源产品，都可以实现消息中转的功能，但各有不同。ZeroMQActiveMQ消息中转实现形式为队列形式，分布式、集群服务助手。RedisMongoDB较成熟的非结构性数据库产品，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函数来实现高性能网络通信。OSAPIZeroMQ应用层ZeroMQ消息模型ZeroMQ将消息通信分成4种模型，分别是一对一结对模型（Exclusive-Pair）、请求回应模型（Request-Reply）、发布订阅模型（Publish-Subscribe）、推拉模型（Push-Pull）。这4种模型总结出了通用的网络通信模型，在实际中可以根据应用需要，组合其中的2种或多种模型来形成自己的解决方案。1.一对一：TCPConnection，TCPSever只能接受一个连接，数据双向流动2.请求回应：一个服务端对应多个客户端，每个请求服务端都会给一个回应，相当于1对N的方式。Client1REQClient2REQClient3REQServerREP请求2回复2请求3回复3请求1回复13.发布订阅模型：发布端单向分发数据，且不关心是否把全部信息发送给订阅端，天气预报、微博明星粉丝可以应用这种经典模型。PublisherPUBSubscriber1SUBbindupdateupdateconnectupdateconnectupdateconnectSUBSubscriber2SUBSubscriber34.推拉模型：Server端为push端，Client端为pull端，如果有多个Client端同时连接到Server端，则Server端会在内部做一个负载均衡，采用平均分配的算法，均衡推送，改模型主要用于多任务并行。VentilatorPUSHWorkerPUSHPULLWorkerPUSHPULLWorkerPUSHPULLSinkPULLtaskstasktasktaskresultresultresultresultsZeroMQ通信协议：提供进程内、进程间、机器间、广播等四种通信协议，支持的具体协议类型有：inproc、ipc、tcp、pgm。用类似于URL形式的字符串指定即可，格式分别为inproc://、ipc://、tcp://、pgm://。ZeroMQ会自动根据指定的字符串解析出协议、地址、端口号等信息。支持常用的多种语言客户端C++、Java、.Net、Python、Php、Ruby等。ZeroMQ性能目前，市面上类似的产品不少，主要有4种：MSMQ（微软产品）、ActiveMQ（Java）、RabbitMQ(Erlang)、ZeroMQ（C++）。除ZeroMQ外，其它3款产品都是一个单独服务或者进程，需要单独安装和运行，且对环境有一定依赖。其中，MSMQ在非Windows平台下安装非常复杂，ActiveMQ需要目标机器上已经安装了Java，RabbitMQ需要Erlang环境。而ZeroMQ是以库的形式存在，由应用程序加载、运行即可。但是ZeroMQ仅提供非持久性的消息队列。下图是来自Internet的性能测试数据。显示的是每秒钟发送和接受的消息数。整个过程共产生1百万条1K的消息，测试环境为WindowsVista。从测试数据可以看出，ZeroMQ的性能远远高于其它3个MQ。ZeroMQ优点：简单1、仅仅提供24个API接口，风格类似于BSDSocket。2、处理了网络异常，包括连接异常中断、重连等。3、改变TCP基于字节流收发数据的方式，处理了粘包、半包等问题，以msg为单位收发数据，结合ProtocolBuffers，可以对应用层彻底屏蔽网络通信层。4、对大数据通过SENDMORE/RECVMORE提供分包收发机制。5、通过线程间数据流动来保证同一时刻任何数据都只会被一个线程持有，以此实现多线程的“去锁化”。6、通过高水位HWM来控制流量，用交换SWAP来转储内存数据，弥补HWM丢失数据的缺陷。7、服务器端和客户端的启动没有先后顺序。灵活1、支持多种通信协议，可以灵活地适应多种通信环境，包括进程内、进程间、机器间、广播。2、支持多种消息模型，消息模型之间可以相互组合，形成特定的解决方案。跨平台支持Linux、Windows、OSX等。多语言可以绑定C、C++、Java、.NET、Python等30多种开发语言。高性能相对同类产品，性能卓越。ActiveMQActiveMQ是Apache下的一个子项目。类似于ZeroMQ，它能够以代理人和点对点的技术实现队列。它用少量代码就可以高效地实现高级应用场景。是流行的，能力强劲的开源消息总线。语言和协议语言：支持常用的多种语言客户端C++、Java、.Net、Python、Php、Ruby等，其中Java环境资料比较多。应用协议：OpenWire,StompREST,WSNotification,XMPP,AMQP。传送协议：in-VM,TCP,SSL,NIO,UDP,JGroups,JXTA。其他ActiveMQ可以很容易内嵌到使用Spring的系统里面去支持通过JDBC和journal提供高速的消息持久化从设计上保证了高性能的集群，客户端-服务器，点对点可以很容易得调用内嵌JMSprovider服务端与Java客户端通信实例已完成RabbitMQ是使用Erlang编写的一个开源的消息队列，支持很多的协议AMQP，XMPP,SMTP,STOMP，也正是如此，使的它变的非常重量级，更适合于企业级的开发。同时实现了一个经纪人(Broker)构架，这意味着消息在发送给客户端时先在中心队列排队。对路由(Routing)，负载均衡(Loadbalance)或者数据持久化都有很好的支持，适合于在分布式集群系统中做消息中转服务。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更偏重于进程顺序写入，虽然支持集群，也仅限于主-从模式。Memcached是一个高性能的分布式内存对象缓存系统，用于动态Web应用以减轻数据库负载。它通过在内存中缓存数据和对象来减少读取数据库的次数，从而提高动态、数据库驱动网站的速度。Memcached基于一个存储键/值对的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选举算法，自动故障恢复)，autosharding机制，对客户端屏蔽了故障转移和切分机制依赖客户端来实现分布式读写；主从复制时，每次从节点重新连接主节点都要依赖整个快照，无增量复制；不支持自动sharding，需要依赖程序设定一致hash机制MongoDB优于Redis，单点问题上，MongoDB应用简单，相对用户透明，Redis比较复制，需要客户主动解决。MongoDB一般会使用replicasets和sharding功能结合，replicasets侧重高可用性及高可靠性，而sharding侧重于性能、易扩展可靠性从1.8版本后，采用binLog方式（MySQL同样采用该方式）支持持久化，增加可靠性依赖快照进行持久化；AOF增强可靠性；增强可靠性的同时，影响访问性能MongoDB优于Redis一致性不支持事物，靠客户端自身保证支持事物，比较弱，仅能保证事物中的操作按顺序执行Redis优于MongoDB数据分析内置数据分析功能不支持MongoDB优于Redis应用场景海量数据的访问效率提升较小数据量的性能及运算MongoDB优于Redis