关于消息队列的技术选型
t/developer/article/1006035
导语：消息队列是分布式系统中重要的组件，在很多⽣产环境如商品抢购等需要控制并发量的场景下都需要⽤到。最近组内需要做流⽔server的选型升级，这⾥对消息队列及常见的消息队列进⾏了⼀次调研，整理了相关资料，分享给⼤家。
⼀、消息队列(MQ)概述
消息队列（Message Queue），是分布式系统中重要的组件，其通⽤的使⽤场景可以简单地描述为：
当不需要⽴即获得结果，但是并发量⼜需要进⾏控制的时候，差不多就是需要使⽤消息队列的时候。
消息队列主要解决了应⽤耦合、异步处理、流量削锋等问题。
当前使⽤较多的消息队列有RabbitMQ、RocketMQ、ActiveMQ、Kafka、ZeroMQ、MetaMq等，⽽部分数据库如、Mysql以及phxsql也可实现消息队列的功能。
⼆、消息队列使⽤场景
消息队列在实际应⽤中包括如下四个场景：
应⽤耦合：多应⽤间通过消息队列对同⼀消息进⾏处理，避免调⽤接⼝失败导致整个过程失败；
异步处理：多应⽤对消息队列中同⼀消息进⾏处理，应⽤间并发处理消息，相⽐串⾏处理，减少处理时间；
限流削峰：⼴泛应⽤于秒杀或抢购活动中，避免流量过⼤导致应⽤系统挂掉的情况；
消息驱动的系统：系统分为消息队列、消息⽣产者、消息消费者，⽣产者负责产⽣消息，消费者(可能有多个)负责对消息进⾏处理；
下⾯详细介绍上述四个场景以及消息队列如何在上述四个场景中使⽤：
2.1 异步处理
具体场景：⽤户为了使⽤某个应⽤，进⾏注册，系统需要发送注册邮件并验证短信。对这两个操作的处理⽅式有两种：串⾏及并⾏。
（1）串⾏⽅式：新注册信息⽣成后，先发送注册邮件，再发送验证短信；
在这种⽅式下，需要最终发送验证短信后再返回给客户端。
（2）并⾏处理：新注册信息写⼊后，由发短信和发邮件并⾏处理；
在这种⽅式下，发短信和发邮件需处理完成后再返回给客户端。
假设以上三个⼦系统处理的时间均为50ms，且不考虑⽹络延迟，则总的处理时间：
串⾏：50+50+50=150ms 并⾏：50+50 = 100ms
若使⽤消息队列：
并在写⼊消息队列后⽴即返回成功给客户端，则总的响应时间依赖于写⼊消息队列的时间，⽽写⼊消息队列的时间本⾝是可以很快的，基本可以忽略不计，因此总的处理时间相⽐串⾏提⾼了2倍，相⽐并⾏提⾼了⼀倍；
2.2 应⽤耦合
具体场景：⽤户使⽤QQ相册上传⼀张图⽚，系统会对该图⽚进⾏⼈脸识别，⼀般的做法是，服务器接收到图⽚后，图⽚上传系统⽴即调⽤⼈脸识别系统，调⽤完成后再返回成功，如下图所⽰：
该⽅法有如下缺点：
⼈脸识别系统被调失败，导致图⽚上传失败；
延迟⾼，需要⼈脸识别系统处理完成后，再返回给客户端，即使⽤户并不需要⽴即知道结果；
图⽚上传系统与⼈脸识别系统之间互相调⽤，需要做耦合；
若使⽤消息队列：
客户端上传图⽚后，图⽚上传系统将图⽚信息如uin、批次写⼊消息队列，直接返回成功；⽽⼈脸识别系统则定时从消息队列中取数据，完成对新增图⽚的识别。
此时图⽚上传系统并不需要关⼼⼈脸识别系统是否对这些图⽚信息的处理、以及何时对这些图⽚信息进⾏处理。事实上，由于⽤户并不需要⽴即知道⼈脸识别结果，⼈脸识别系统可以选择不同的调度策略，按照闲时、忙时、正常时间，对队列中的图⽚信息进⾏处理。
2.3 限流削峰
具体场景：购物⽹站开展秒杀活动，⼀般由于瞬时访问量过⼤，服务器接收过⼤，会导致流量暴增，相关系统⽆法处理请求甚⾄崩溃。⽽加⼊消息队列后，系统可以从消息队列中取数据，相当于消息队列做了⼀次缓冲。
该⽅法有如下优点：
1. 请求先⼊消息队列，⽽不是由业务处理系统直接处理，做了⼀次缓冲，极⼤地减少了业务处理系统的压⼒；
2. 队列长度可以做限制，事实上，秒杀时，后⼊队列的⽤户⽆法秒杀到商品，这些请求可以直接被抛弃，返回活动已结束或商品已售完信息；
2.4 消息驱动的系统
具体场景：⽤户新上传了⼀批照⽚，⼈脸识别系统需要对这个⽤户的所有照⽚进⾏聚类，聚类完成后由
对账系统重新⽣成⽤户的⼈脸索引(加快查询)。这三个⼦系统间由消息队列连接起来，前⼀个阶段的处理结果放⼊队列中，后⼀个阶段从队列中获取消息继续处理。
该⽅法有如下优点：
避免了直接调⽤下⼀个系统导致当前系统失败；
每个⼦系统对于消息的处理⽅式可以更为灵活，可以选择收到消息时就处理，可以选择定时处理，也可以划分时间段按不同处理速度处理；
三、消息队列的两种模式
消息队列包括两种模式，点对点模式（point to point， queue）和发布/订阅模式（publish/subscribe，topic）。
3.1 点对点模式
点对点模式下包括三个⾓⾊：
消息队列
发送者 (⽣产者)
接收者（消费者）
消息发送者⽣产消息发送到queue中，然后消息接收者从queue中取出并且消费消息。消息被消费以后，queue中不再有存储，所以消息接收者不可能消费到已经被消费的消息。
点对点模式特点：
每个消息只有⼀个接收者（Consumer）(即⼀旦被消费，消息就不再在消息队列中)；
发送者和接收者间没有依赖性，发送者发送消息之后，不管有没有接收者在运⾏，都不会影响到发送者下次发送消息；
接收者在成功接收消息之后需向队列应答成功，以便消息队列删除当前接收的消息；
3.2 发布/订阅模式
发布/订阅模式下包括三个⾓⾊：
⾓⾊主题（Topic）
发布者(Publisher)
订阅者(Subscriber)
发布者将消息发送到Topic，系统将这些消息传递给多个订阅者。
发布/订阅模式特点：
每个消息可以有多个订阅者；
发布者和订阅者之间有时间上的依赖性。针对某个主题（Topic）的订阅者，它必须创建⼀个订阅者之后，才能消费发布者的消息。
为了消费消息，订阅者需要提前订阅该⾓⾊主题，并保持在线运⾏；
四、常⽤消息队列介绍
本部分主要介绍四种常⽤的消息队列（RabbitMQ/ActiveMQ/RocketMQ/Kafka）的主要特性、优点、缺点。
4.1 RabbitMQ
2007年发布，是⼀个在(⾼级消息队列协议)基础上完成的，可复⽤的企业消息系统，是当前最主流的消息中间件之⼀。
主要特性：
1. 可靠性: 提供了多种技术可以让你在性能和可靠性之间进⾏权衡。这些技术包括持久性机制、投递确认、发布者证实和⾼可⽤性机制；
2. 灵活的路由：消息在到达队列前是通过交换机进⾏路由的。RabbitMQ为典型的路由逻辑提供了多种内置交换机类型。如果你有更复杂的路由需求，可以
将这些交换机组合起来使⽤，你甚⾄可以实现⾃⼰的交换机类型，并且当做RabbitMQ的插件来使⽤；
3. 消息集：在相同局域⽹中的多个RabbitMQ服务器可以聚合在⼀起，作为⼀个独⽴的逻辑代理来使⽤；
4. 队列⾼可⽤：队列可以在集中的机器上进⾏镜像，以确保在硬件问题下还保证消息安全；
5. 多种协议的⽀持：⽀持多种消息队列协议；
6. 服务器端⽤Erlang语⾔编写，⽀持只要是你能想到的所有编程语⾔；
7. 管理界⾯: RabbitMQ有⼀个易⽤的⽤户界⾯，使得⽤户可以监控和管理消息Broker的许多⽅⾯；
activemq集环境搭建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语⾔的特性，mq 性能较好，⾼并发；
2. 健壮、稳定、易⽤、跨平台、⽀持多种语⾔、⽂档齐全；
3. 有消息确认机制和持久化机制，可靠性⾼；
4. ⾼度可定制的路由；
5. 管理界⾯较丰富，在互联⽹公司也有较⼤规模的应⽤；
6. 社区活跃度⾼；
缺点：
1. 尽管结合erlang语⾔本⾝的并发优势，性能较好，但是不利于做⼆次开发和维护；
2. 实现了代理架构，意味着消息在发送到客户端之前可以在中央节点上排队。此特性使得RabbitMQ易于使⽤和部署，但是使得其运⾏速度较慢，因为中央节
点增加了延迟，消息封装后也⽐较⼤；
3. 需要学习⽐较复杂的接⼝和协议，学习和维护成本较⾼；
4.2 ActiveMQ
是由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；