Table of Contents generated with DocToc (opens new window)

• 消息队列基础
  • 应用场景
    • 异步
      • 为什么要异步？
      • 异步可以用线程池实现为什么要用消息队列？
    • 削峰
    • 解耦
      • 消息驱动的系统
    • 顺序收发
    • 分布式事务一致性
    • 分布式缓存同步
  • 消息队列的技术选型
    • RabbitMQ
      • 简介
      • 主要特性：
      • 使用RabbitMQ需要：
      • 优点：
      • 缺点：
    • ActiveMQ
      • 简介
      • 主要特性：
      • 使用ActiveMQ需要：
      • 优点：
      • 缺点：
    • RocketMQ
      • 简介
      • 主要特性：
      • 使用RocketMQ需要：
      • 优点：
      • 缺点：
    • Kafka
      • 简介
      • 主要特性：
      • 使用Kafka需要：
      • 优点：
      • 缺点：
    • Pulsar
    • 对比
    • 综合选型

---

消息队列基础

应用场景

提示

主要是三种作用，异步、削峰、**解耦，**其他还有顺序收发、分布式事务一致性、大数据分析、分布式缓存同步

异步

为什么要异步？

比如一个下单服务，下单的时候还要对其他服务诸如：优惠券、积分、短信等等服务进行交互操作，单独的下单支付操作可能耗时100ms，优惠券100ms，积分200ms，短信再来100ms，整个下单流程的耗时就被延长到了500ms，并且多个操作一起执行会增加服务的耦合性。

就像这个下单流程，我们在下单服务里面同时要对优惠券、积分、短信等多个服务进行操作，服务之间就又耦合在了一起，当然这不是最主要的问题，上面的耗时倍增才是，在真实场景下涉及的服务可能是大于10个的。

如果用户进行一个操作要执行几秒钟乃至十几秒才能成功，那么对用户的体验是极差的。

但其实上面的流程是可以同时执行的，因为彼此之间没有强关联性和顺序性，支付成功后，去校验优惠券的同时可以去增减积分，还可以同时发个短信。

那正常的流程我们是没办法实现的，所以就需要使用消息队列的异步功能。

异步可以用线程池实现为什么要用消息队列？

削峰

平时流量很低，但是要做秒杀活动，00 ：00的时候流量疯狂怼进来，服务器，Redis，MySQL各自的承受能力都不一样，直接全部流量照单全收肯定有问题，直接就打挂了。

所以我们把请求放到队列里面，然后至于每秒消费多少请求，就看自己的服务器处理能力，能处理5000QPS就消费这么多，可能会比正常的慢一点，但是不至于打挂服务器，等流量高峰下去了，服务也就没压力了。

解耦

这里正好解释为什么不用线程池去实现消息的异步

因为用线程去做，是不是要写代码？

一个订单流程，扣积分，扣优惠券，发短信，扣库存等等这么多业务要调用这么多的接口，每次加一个都要调用一个接口然后还要重新发布系统

而且真的全部都写在一起的话，不单单是耦合这一个问题，出问题排查也麻烦，流程里面随便一个地方出问题搞不好会影响到其他的点，但是用了消息队列，耦合这个问题就迎刃而解了。

提示

下单了，就把支付成功的消息告诉别的系统，他们收到了去处理就好了，下单这里只用走完自己的流程，把自己的消息发出去，那后面要接入什么系统简单，直接订阅你发送的支付成功消息，支付成功了这个接入系统监听就好了。

消息驱动的系统

具体场景：用户新上传了一批照片， 人脸识别系统需要对这个用户的所有照片进行聚类，聚类完成后由对账系统重新生成用户的人脸索引(加快查询)。这三个子系统间由消息队列连接起来，前一个阶段的处理结果放入队列中，后一个阶段从队列中获取消息继续处理

该方式有如下优点：

• 避免了直接调用下一个系统导致当前系统失败；
• 每个子系统对于消息的处理方式可以更为灵活，可以选择收到消息时就处理，可以选择定时处理，也可以划分时间段按不同处理速度处理；

顺序收发

提示

细数日常中需要保证顺序的应用场景非常多，例如证券交易过程时间优先原则，交易系统中的订单创建、支付、退款等流程，航班中的旅客登机消息处理等等。与先进先出FIFO（First In First Out）原理类似，消息队列RocketMQ版提供的顺序消息即保证消息FIFO。

分布式事务一致性

提示

交易系统、支付红包等场景需要确保数据的最终一致性，大量引入消息队列RocketMQ版的分布式事务，既可以实现系统之间的解耦，又可以保证最终的数据一致性。

分布式缓存同步

提示

天猫双11大促，各个分会场琳琅满目的商品需要实时感知价格变化，大量并发访问数据库导致会场页面响应时间长，集中式缓存因带宽瓶颈，限制了商品变更的访问流量，通过消息队列RocketMQ版构建分布式缓存，实时通知商品数据的变化。

消息队列的技术选型

RabbitMQ

简介

RabbitMQ (opens new window) 2007年发布，是一个在AMQP (opens new window)(高级消息队列协议)基础上完成的，可复用的企业消息系统，是当前最主流的消息中间件之一。

主要特性：

1. 可靠性: 提供了多种技术可以让你在性能和可靠性之间进行权衡。这些技术包括持久性机制、投递确认、发布者证实和高可用性机制；
2. 灵活的路由： 消息在到达队列前是通过交换机进行路由的。RabbitMQ为典型的路由逻辑提供了多种内置交换机类型。如果你有更复杂的路由需求，可以将这些交换机组合起来使用，你甚至可以实现自己的交换机类型，并且当做RabbitMQ的插件来使用；
3. 消息集群：在相同局域网中的多个RabbitMQ服务器可以聚合在一起，作为一个独立的逻辑代理来使用；
4. 队列高可用：队列可以在集群中的机器上进行镜像，以确保在硬件问题下还保证消息安全；
5. 多种协议的支持：支持多种消息队列协议；
6. 服务器端用Erlang语言编写，支持只要是你能想到的所有编程语言；
7. 管理界面: RabbitMQ有一个易用的用户界面，使得用户可以监控和管理消息Broker的许多方面；
8. 跟踪机制：如果消息异常，RabbitMQ提供消息跟踪机制，使用者可以找出发生了什么；
9. 插件机制：提供了许多插件，来从多方面进行扩展，也可以编写自己的插件；

使用RabbitMQ需要：

• ErLang语言包
• RabbitMQ安装包

RabbitMQ可以运行在Erlang语言所支持的平台之上：

Solaris、BSD、Linux、MacOSX、TRU64、

Windows NT/2000/XP/Vista/Windows 7/Windows 8、

Windows Server 2003/2008/2012、Windows 95, 98、VxWorks

优点：

1. 由于erlang语言的特性，RabbitMQ性能较好，高并发；
2. 健壮、稳定、易用、跨平台、支持多种语言、文档齐全；
3. 有消息确认机制和持久化机制，可靠性高；
4. 高度可定制的路由；
5. 管理界面较丰富，在互联网公司也有较大规模的应用；
6. 社区活跃度高；

缺点：

1. 尽管结合erlang语言本身的并发优势，性能较好，但是不利于做二次开发和维护；
2. 实现了代理架构，意味着消息在发送到客户端之前可以在中央节点上排队。此特性使得RabbitMQ易于使用和部署，但是使得其运行速度较慢，因为中央节点增加了延迟，消息封装后也比较大；
3. 需要学习比较复杂的接口和协议，学习和维护成本较高；

ActiveMQ

简介

ActiveMQ (opens new window)是由Apache出品，ActiveMQ 是一个完全支持JMS1.1和J2EE 1.4规范的 JMS Provider实现。它非常快速，支持多种语言的客户端和协议，而且可以非常容易的嵌入到企业的应用环境中，并有许多高级功能。

主要特性：

1. 服从 JMS 规范：JMS 规范提供了良好的标准和保证，包括：同步或异步的消息分发，一次和仅一次的消息分发，消息接收和订阅等等。遵从 JMS 规范的好处在于，不论使用什么 JMS 实现提供者，这些基础特性都是可用的；
2. 连接性：ActiveMQ 提供了广泛的连接选项，支持的协议有：HTTP/S，IP 多播，SSL，STOMP，TCP，UDP，XMPP等等。对众多协议的支持让 ActiveMQ 拥有了很好的灵活性。
3. 支持的协议种类多：OpenWire、STOMP、REST、XMPP、AMQP ；
4. 持久化插件和安全插件：ActiveMQ 提供了多种持久化选择。而且，ActiveMQ 的安全性也可以完全依据用户需求进行自定义鉴权和授权；
5. 支持的客户端语言种类多：除了 Java 之外，还有：C/C++，.NET，Perl，PHP，Python，Ruby；
6. 代理集群：多个 ActiveMQ 代理可以组成一个集群来提供服务；
7. 异常简单的管理：ActiveMQ 是以开发者思维被设计的。所以，它并不需要专门的管理员，因为它提供了简单又使用的管理特性。有很多中方法可以监控 ActiveMQ 不同层面的数据，包括使用在 JConsole 或者 ActiveMQ 的Web Console 中使用 JMX，通过处理 JMX 的告警消息，通过使用命令行脚本，甚至可以通过监控各种类型的日志。

使用ActiveMQ需要：

• Java JDK
• ActiveMQ安装包

ActiveMQ可以运行在Java语言所支持的平台之上。

优点：

1. 跨平台(JAVA编写与平台无关有，ActiveMQ几乎可以运行在任何的JVM上)
2. 可以用JDBC：可以将数据持久化到数据库。虽然使用JDBC会降低ActiveMQ的性能，但是数据库一直都是开发人员最熟悉的存储介质。将消息存到数据库，看得见摸得着。而且公司有专门的DBA去对数据库进行调优，主从分离；
3. 支持JMS ：支持JMS的统一接口;
4. 支持自动重连；
5. 有安全机制：支持基于shiro，jaas等多种安全配置机制，可以对Queue/Topic进行认证和授权。
6. 监控完善：拥有完善的监控，包括Web Console，JMX，Shell命令行，Jolokia的REST API；
7. 界面友善：提供的Web Console可以满足大部分情况，还有很多第三方的组件可以使用，如hawtio；

缺点：

1. 社区活跃度不及RabbitMQ高；
2. 根据其他用户反馈，会出莫名其妙的问题，会丢失消息；
3. 目前重心放到ActiveMQ6.0产品-apollo，对5.x的维护较少；
4. 不适合用于上千个队列的应用场景；

RocketMQ

简介

RocketMQ (opens new window)出自 阿里公司的开源产品，用 Java 语言实现，在设计时参考了 Kafka，并做出了自己的一些改进，消息可靠性上比 Kafka 更好。RocketMQ在阿里集团被广泛应用在订单，交易，充值，流计算，消息推送，日志流式处理，binglog分发等场景。

主要特性：

1. 是一个队列模型的消息中间件，具有高性能、高可靠、高实时、分布式特点；
2. Producer、Consumer、队列都可以分布式；
3. Producer向一些队列轮流发送消息，队列集合称为Topic，Consumer如果做广播消费，则一个consumer实例消费这个Topic对应的所有队列，如果做集群消费，则多个Consumer实例平均消费这个topic对应的队列集合；
4. 能够保证严格的消息顺序；
5. 提供丰富的消息拉取模式；
6. 高效的订阅者水平扩展能力；
7. 实时的消息订阅机制；
8. 亿级消息堆积能力；
9. 较少的依赖；

使用RocketMQ需要：

• Java JDK
• 安装git、Maven
• RocketMQ安装包

RocketMQ可以运行在Java语言所支持的平台之上。

优点：

1. 单机支持 1 万以上持久化队列
2. RocketMQ 的所有消息都是持久化的，先写入系统 PAGECACHE，然后刷盘，可以保证内存与磁盘都有一份数据，访问时，直接从内存读取。
3. 模型简单，接口易用（JMS 的接口很多场合并不太实用）；
4. 性能非常好，可以大量堆积消息在broker中；
5. 支持多种消费，包括集群消费、广播消费等。
6. 各个环节分布式扩展设计，主从HA；
7. 开发度较活跃，版本更新很快。

缺点：

• 支持的客户端语言不多，目前是java及c++，其中c++不成熟；
• RocketMQ社区关注度及成熟度也不及前两者；
• 没有web管理界面，提供了一个CLI(命令行界面)管理工具带来查询、管理和诊断各种问题；
• 没有在 mq 核心中去实现JMS等接口；

Kafka

简介

Apache Kafka (opens new window)是一个分布式消息发布订阅系统。它最初由LinkedIn公司基于独特的设计实现为一个分布式的提交日志系统( a distributed commit log)，，之后成为Apache项目的一部分。Kafka系统快速、可扩展并且可持久化。它的分区特性，可复制和可容错都是其不错的特性。

主要特性：

1. 快速持久化，可以在O(1)的系统开销下进行消息持久化；
2. 高吞吐，在一台普通的服务器上既可以达到10W/s的吞吐速率；
3. .完全的分布式系统，Broker、Producer、Consumer都原生自动支持分布式，自动实现负载均衡；
4. 支持同步和异步复制两种HA；
5. 支持数据批量发送和拉取；
6. zero-copy：减少IO操作步骤；
7. 数据迁移、扩容对用户透明；
8. 无需停机即可扩展机器；
9. 其他特性：严格的消息顺序、丰富的消息拉取模型、高效订阅者水平扩展、实时的消息订阅、亿级的消息堆积能力、定期删除机制；

使用Kafka需要：

• Java JDK
• Kafka安装包

优点：

1. 客户端语言丰富，支持java、.net、php、ruby、python、go等多种语言；
2. 性能卓越，单机写入TPS约在百万条/秒，消息大小10个字节；
3. 提供完全分布式架构, 并有replica机制, 拥有较高的可用性和可靠性, 理论上支持消息无限堆积；
4. 支持批量操作；
5. 消费者采用Pull方式获取消息, 消息有序, 通过控制能够保证所有消息被消费且仅被消费一次;
6. 有优秀的第三方Kafka Web管理界面Kafka-Manager；
7. 在日志领域比较成熟，被多家公司和多个开源项目使用；

缺点：

1. Kafka单机超过64个队列/分区，Load会发生明显的飙高现象，队列越多，load越高，发送消息响应时间变长
2. 使用短轮询方式，实时性取决于轮询间隔时间；
3. 消费失败不支持重试；
4. 支持消息顺序，但是一台代理宕机后，就会产生消息乱序；
5. 社区更新较慢；

Pulsar

对比

特性	ActiveMQ	RabbitMQ	RocketMQ	Kafka	Pulsar
PRODUCER-COMSUMER	支持	支持	支持	支持	支持
PUBLISH-SUBSCRIBE	支持	支持	支持	支持	支持
REQUEST-REPLY	支持	支持	支持	-	-
API完备性	高	高	低（静态配置）	高	高
多语言支持	支持，JAVA优先	语言无关	支持	支持，JAVA优先	支持
单机呑吐量	1w+/s，比RocketMQ、Kafka低一个量级	同ActiveMQ	10w+/s，高吞吐，支持强一致，强一致下吞吐量稍低	10w+/s，高吞吐，一般配合大数据类的系统进行实时数据计算、日志采集等场景	14w+/s，高吞吐，支持强一致
topic数量对吞吐量的影响			topic可以达到几百/几千的级别，吞吐量会有较小幅度的下降，这是RocketMQ的一大优势，在同等机器下，可以支撑大量的topic	topic从几十到几百个的时候，吞吐量会大幅度下降，在同等机器下，kafka要尽量保证topic数量不要过多，如果要支撑大规模的topic，需要增加更多的机器资源	Pulsar采用存算分离的架构，数据采用bookKeeper存储。上层broker是无状态代理，两层可以独立扩容，因此topic个数对吞吐量不会产生显著的影响
消息延迟	毫秒级	微秒级，这是RabbitMQ的一大特点，延迟最低	毫秒级	毫秒级以内	毫秒级
可用性	高（主从）	高（主从）	非常高，分布式架构（分为4.5版本后的Dledger架构和普通的master-slave架构两种，但普通主从架构不支持故障自动切换，运维不太友好）	非常高，分布式，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用	非常高，broker层是无状态代理，动态扩容，数据存储层bookKeeper采用segment-oriented存储机制，无写入不可用风险
消息丢失(可靠性)	较低的概率丢失	基本不会丢失	经过参数优化可以做到0丢失	经过参数优化可以做到0丢失	经过参数配置后可以做到0丢失
消息重复	-	可控制	-	理论上会有重复
功能支持	MQ领域的功能极其完善	基于erlang开发，并发能力很强，性能极好，延时很低	MQ功能较为完善，是分布式的，扩展性好，社区和kafka相比，不是太活跃	功能较为简单易用，生态完善，绝大部分场景都可使用，在大数据领域的实时计算以及日志采集被大规模使用	云原生时代的新一代消息中间件，社区活跃，支持多租户、强一致、跨域部署等诸多特性
文档的完备性	高	高	中	高	-
提供快速入门	有	有	无	有	-
首次部署难度	-	低	高	中	-

综合选型

• ActiveMQ：官方社区现在对 ActiveMQ 5.x 维护越来越少，较少在大规模吞吐的场景中使用。
• RabbitMQ：结合 erlang 语言本身的并发优势，性能较好，社区活跃度也比较高，但是不利于做二次开发和维护，不过 RabbitMQ 的社区十分活跃，可以解决开发过程中遇到的 bug。如果你的数据量没有那么大，小公司优先选择功能比较完备的 RabbitMQ。
• RocketMQ：天生为金融互联网领域而生，对于可靠性要求很高的场景，尤其是电商里面的订单扣款，以及业务削峰，在大量交易涌入时，后端可能无法及时处理的情况。RocketMQ 在稳定性上可能更值得信赖，这些业务场景在阿里双 11 已经经历了多次考验，如果你的业务有上述并发场景，建议可以选择 RocketMQ。
• Kafka：追求高吞吐量，一开始的目的就是用于日志收集和传输，适合产生大量数据的互联网服务的数据收集业务，大型公司建议可以选用，如果有日志采集、大数据处理，肯定是首选 kafka，Kafka都有比较成熟的解决方案。
• Pulsar：支持的功能比Kafka更丰富，而且跨地域容灾，多租户等功能，支持消息强一致性，若对消息可靠性、容灾要求更好，或者有高分区、延迟队列等需求的场景，可以选用Pulsar。