几种消息服务产品比较.docx

几种消息服务产品比较IMB MQActiveMqRabbitMqKafkaproducer容错，是否会丢数据有ack模型，也有事务模型.采用存储转发机制，实现可靠的数据传输。采用成熟的数据库技术，实现两阶段事务提交机制，保证消息不被丢失或者重新复制。有ack模型，也有事务模型，保证至少不会丢数据。ack模型可能会有重复消息，事务模型则保证完全一致批量形式下，可能会丢数据。 非批量形式下， 1. 使用同步模式，可能会有重复数据。 2. 异步模式，则可能会丢数据。(当Producer向Leader发送数据时,可以通过acks参数设置数据可靠性的级别1.0: 不论写入是否成功,server不需要给Producer发送Response,如果发生异常,server会终止连接,触发Producer更新meta数据;2.1: Leader写入成功后即发送Response,此种情况如果Leader fail,会丢失数据3.-1: 等待所有ISR接收到消息后再给Producer发送Response,这是最强保证 ,仅设置acks=-1也不能保证数据不丢失,当Isr列表中只有Leader时,同样有可能造成数据丢失。要保证数据不丢除了设置acks=-1, 还要保 证ISR的大小大于等于2,具体参数设置:1.request.required.acks:设置为-1 等待所有ISR列表中的Replica接收到消息后采算写成功;2.min.insync.replicas: 设置为大于等于2,保证ISR中至少有两个Replica Producer要在吞吐率和数据可靠性之间做一个权衡)consumer容错，是否会丢数据有ack模型，也有事务模型.采用存储转发机制，实现可靠的数据传输。采用成熟的数据库技术，实现两阶段事务提交机制，保证消息不被丢失或者重新复制有ack模型，数据不会丢，但可能会重复处理数据。批量形式下，可能会丢数据。非批量形式下，可能会重复处理数据。（ZK写offset是异步的）(一致性定义:若某条消息对Consumer可见,那么即使Leader宕机了,在新Leader上数据依然可以被读到1.HighWaterMark简称HW: Partition的高水位，取一个partition对应的ISR中最小的LEO作为HW，消费者最多只能消费到HW所在的位置，另外每个replica都有highWatermark，leader和follower各自负责更新自己的highWatermark状态，highWatermark = leader. LogEndOffset2.对于Leader新写入的msg，Consumer不能立刻消费，Leader会等待该消息被所有ISR中的replica同步后,更新HW,此时该消息才能被Consumer消费，即Consumer最多只能消费到HW位置,这样就保证了如果Leader Broker失效,该消息仍然可以从新选举的Leader中获取。对于来自内部Broker的读取请求,没有HW的限制。同时,Follower也会维护一份自己的HW,Folloer.HW = min(Leader.HW, Follower.offset)架构模型队列管理器（QueueManager）、队列（Queue）和通道（Channel）基于JMS协议基于AMQP模型，比较成熟，但更新超慢。RabbitMQ的broker由Exchange,Binding,queue组成，其中exchange和binding组成了消息的路由键；客户端Producer通过连接channel和server进行通信，Consumer从queue获取消息进行消费（长连接，queue有消息会推送到consumer端，consumer循环从输入流读取数据）。rabbitMQ以broker为中心；有消息的确认机制producer，broker，consumer，以consumer为中心，消息的消费信息保存的客户端consumer上，consumer根据消费的点，从broker上批量pull数据；无消息确认机制。吞吐量rabbitMQ在吞吐量方面稍逊于kafka，他们的出发点不一样，rabbitMQ支持对消息的可靠的传递，支持事务，不支持批量的操作；基于存储的可靠性的要求存储可以采用内存或者硬盘。kafka具有高的吞吐量，内部采用消息的批量处理，zero-copy机制，数据的存储和获取是本地磁盘顺序批量操作，具有O(1)的复杂度，消息处理的效率很高可用性具备高可用性rabbitMQ支持miror的queue，主queue失效，miror queue接管kafka的broker支持主备模式集群负载均衡负载均衡功能强rabbitMQ的负载均衡需要单独的loadbalancer进行支持kafka采用zookeeper对集群中的broker、consumer进行管理，可以注册topic到zookeeper上；通过zookeeper的协调机制，producer保存对应topic的broker信息，可以随机或者轮询发送到broker上；并且producer可以基于语义指定分片，消息发送到broker的某分片上消息队列的选择：kafka、rabbitmq、zeromq7,877 views2015年2月5日技术学习kafka、rabbitmq、zeromq、消息队列最近在做一个数据分析相关的工作，需求是将全国各地idc内的流量信息进行汇总和分析最后吐出一些安全策略，由于对时效性的要求比较高，大概每隔几秒就会有一次几十M的的数据需要传递到汇总服务器上去，而且随着业务的发展数据量还会越来越大，所以使用什么手段来做数据的传输就成为了一个关键的问题。首先是可扩展性，如果使用标准socket进行传递的话随着数据量的扩大单点肯定会成为瓶颈，而且如果可用性要高的话，异步、缓存、重传等等都是需要考虑的要素，为了开速上线功能就要去几个开源的消息队列里挑选一下合适这个项目的了。由于团队内的一些推荐和自己以前的经验，初步定下了kafka、rabbitmq、zeromq三个软件，这里主要介绍一下这三个软件各自的特点和功能，详细的使用说明和学习资料后面在补。一、rabbitmq首先是百科里的一段话，Rabbitmq是流行的开源消息队列系统，使用erlang语言进行开发。RabbitMQ是AMQP(高级消息队列协议)的标准实现。可以说从功能上rabbitmq基本上是符号这次项目要求的工具。它的优点有：1、完整的消息队列系统，支持多种消息队列模式，包括竞争消费；2、基于AMQP3、支持集群模式，扩展集群容量和性能比较方便，同时集成了集群的监控和管理；4、支持消息的持久化；缺点是：1、需要学习比较复杂的接口和协议，比较耗费时间；2、性能不是特别理想大概在1wqps左右；3、使用Erlang语言，以前没听说过，出了问题不会排查；二、zeromq以前经常在内网中使用，号称是最快的消息队列，由于它支持的模式非常多：tcp、ipc、inproc、multicas，基本已经达到了替代标准socket的地步了，听说linux内核已经准备将zeromq纳入标准内核中了。zeromq是一个智能传输层，它并不是对socket的封装，而是在其之上有一套自己的协议，可以使用非常丰富的开发模式像扇出(fanout)、发布订阅(pub-sub)、任务分发(task distribution)、请求响应(request-reply)等。优点：1、缺省为异步I/O交互，封装了连接的维护操作，消息处理并行化；2、性能非常不错；3、编程简单，上手很快；缺点：1、消息无法持久化，除非自己在实现一个中间件，否则消息传递完成就删除了；2、扩展性不是很好，其实是一个消息库，并不算是MQ；三、kafka日志团队正在使用的工具，是一个消息发布订阅系统。生产者向某个队列发送一个数据，消费者订阅一个队列，一旦这个队列内产生新的数据了，中间人就会将数据发送给所有订阅队列的消费者。用术语来说生产者就是producer、消费者就是consumer、中间人就是broker，kafka主要就是这三者之间进行联系的。优点：1、高吞吐量率，每秒能