消息队列选型

消息队列选型

 

消息队列（Message Queue），简称MQ，本质是一个队列，用于存放数据（message），先入先出（FIFO）。主要用于系统解耦、消息缓存。

  目前市面上消息队列的实现有很多种，下面调研了kafka/rabbitMQ/rocketMQ，这三种应用都非常广泛，期望从中选出最合适我们的。

简介

• Kafka是LinkedIn开源的分布式发布-订阅消息系统，目前归属于Apache定级项目。Kafka主要特点是基于Pull的模式来处理消息消费，追求高吞吐量，一开始的目的就是用于日志收集和传输。0.8版本开始支持复制，不支持事务，对消息的重复、丢失、错误没有严格要求，适合产生大量数据的互联网服务的数据收集业务。
• RabbitMQ是使用Erlang语言开发的开源消息队列系统，基于AMQP协议来实现。AMQP的主要特征是面向消息、队列、路由（包括点对点和发布/订阅）、可靠性、安全。AMQP协议更多用在企业系统内，对数据一致性、稳定性和可靠性要求很高的场景，对性能和吞吐量的要求还在其次。
• RocketMQ是阿里开源的消息中间件，它是纯Java开发，具有高吞吐量、高可用性、适合大规模分布式系统应用的特点。RocketMQ思路起源于Kafka，但并不是Kafka的一个Copy，它对消息的可靠传输及事务性做了优化，目前在阿里集团被广泛应用于交易、充值、流计算、消息推送、日志流式处理、binglog分发等场景。
  
  

原理

• kafka：每台服务器为一个broker，每种消息为一个topic，每个topic分为1或多个partition。每个partition为一个物理文件存储，且是排序存储的。消息存储时，会复制到其他broker上，一台broker挂了后保证消息不丢失。
• rocketMQ：与kafka类似，每台服务器为一个broker，每种消息为一个topic，每个topic分为1或多个queue。每个broker可以配置主从，来实现高可用。主从间可采用同步或异步策略来复制消息。
• rabbitMQ：每台服务器为一个broker，发送方发送消息时每类消息有一个RoutingKey，接受方监听一个消息存储的queue，中间有个exchange将RoutingKey按照路由规则放到指定的queue中。

 

特性对比

特性	kafka	rabbitMQ	rocketMQ
可用性	很高	高	高
持久化	支持	支持	支持
顺序消费	支持	支持	支持
事务	不支持	支持	支持
单机吞吐量	十万级	万级	十万级
文档完备性	高	高	高
多语言支持	支持	支持	支持
消息通知方式	pull	pull & push	pull

高可用性

kafka：分布式部署，数据会被负复制到其他节点，一个节点挂了后，会自动切换到其他节点。

rocketMQ:主从结构，数据会负责到从节点，主节点挂了会从从节点选举一个主节点出来

rabbitMQ：有普通模式和镜像模式，镜像模式支持高可用，此模式下，队列的数据复制一份到所有节点上。主节点失效时，mirror queue内部有一套选举算法，会选出一个master，和若干个slaver。

顺序消费消息

kafka:支持。但一个节点失效后，顺序会被打乱，但不是丢失。

rocketMQ：支持。一个节点失效后，发送消息会失败，此节点恢复后，能发送成功且顺序不变。

rabbitMQ：支持。

分布式事务

kafka:不支持

rocketMQ：支持。用两段提交来实现，第一阶段发送消息时，拿到消息offset，第二阶段通过 offset来修改消息状态。

rabbitMQ：支持。可用两段提交或者confirm机制来实现。confirm机制：发送方发送消息，broker立即返回ok，broker异步处理消息，将处理结果通知发送方。

结论

没有哪种有明显的优势，kafka在于分布式架构，rabbitMQ基于AMQP协议来实现，rocketMQ思路来源于kafka，改成了主从结构，在事务性可靠性方面做了优化。宽泛来说，电商、金融等对事务性要求很高的，可以考虑rabbitMQ和rocketMQ，对性能要求高的可考虑kafka。

个人比较倾向于kafka，它的加分项：分布式架构的高可用性，便捷的扩展性。