转载

【进阶之路】消息队列——原理及选型（一）

大家好，我是南橘，从接触java到现在也有差不多两年时间了，两年时间，从一名连java有几种数据结构都不懂超级小白，到现在懂了一点点的进阶小白，学到了不少的东西。知识越分享越值钱，我这段时间总结（包括从别的大佬那边学习，引用）了一些平常学习和面试中的重点（自我认为），希望给大家带来一些帮助

第一件事还是把思维导图贴给大家，因为用的是免费版，所以有水印，如果需要原始版本的话，可以加我的微信：

目前我在负责新的业务，业务中有一块是调用别的集群的服务进行扣款。之前的同事把这块做成异步通知调用然后等待返回，返回成功就在表里记录成功。由于两块业务在不同的集群，为了确保资金安全，防止出现资金风险，只能依靠第二天的对账来保证，但这种调取方式经常会出现资金差错，又需要人工介入。

和大佬讨论了一会，决定在两个服务之间加入消息队列，通过消息队列来保证数据的一致性，也减少出现资金差错的概率。

那么这一章我们就来学习一下消息中间件的内容。

一、什么时候需要消息队列

异步处理 ：处理如短信下发、状态推送、用户注册、数据同步等功能，提高系统的并发能力，集中力量处理重要的部分（同步处理），将非核心功能丢给MQ。
系统解耦 ：可在模块、服务、接口等不同粒度上实现解耦。
重试补偿 ：在跨机器数据传输的整个过程中，只要任意一个环节出错，都会导致问题的产生。可以通过MQ的重试补偿机制去尽可能的处理掉这些异常。
流量削锋 ：对于秒杀场景下的下单处理。服务器收到消息后，首先写入消息队列，然后按照自己的消息处理能力做处理。
日志处理 ：可以定时将日志写入MQ，并且主动订阅日志记录。

二、消息队列核心概念

1、消息服务器Broker：消息服务器，作为server提供消息核心服务

2、消息生产者Producer：发送消息到消息队列。

3、消息消费者Consumer：从消息队列接收消息。

4、消息队列Queue：一个先进先出的消息存储区域。消息按照顺序发送接收，一旦消息被消费处理，该消息将从队列中删除。

1、 本地队列 ：本地队列按照功能可划分为初始化队列，传输队列，目标队列和死信队列

★初始化队列：用作消息触发功能。
  
  ★传输队列：是暂存待传的消息，条件许可的情况下，通过管道将消息传送到其他的队列管理器。
  
  ★目标队列：是消息的目的地，可以长期存放消息。
  
  ★死信队列：如果消息不能送达目标队列，也不能再路由出去，则被自动放入死信队列保存。
复制代码

2、 别名队列&远程队列 ：是一个队列定义，用来指定远端队列管理器的队列。使用了远程队列，程序就不需要知道目标队列的位置。
3、 模型队列 ：模型队列定义了一套本地队列的属性结合，一旦打开模型队列，队列管理器会按照这些属性动态地创建出一个本地队列。

5、主题Topic：主题，发布订阅模式下的消息统一汇集地，不同生产者向topic发送消息，由MQ服务器分发到不同的订阅者，实现消息的消费

6、消息体Message

三、消息模式

1、PTP点对点

特点：

每个消息只有一个消费者（Consumer）(即一旦被消费，消息就不再在消息队列中)
发送者和接收者之间在时间上没有依赖性
接收者在成功接收消息之后需向队列应答成功
利用FIFO先进先出的特性，可以保证消息的顺序性。

终于，不用借大佬的图片，我来给大家画图

2、Pub/Sub发布订阅

特点：

每个消息可以有多个消费者：和点对点方式不同，发布消息可以被所有订阅者消费
发布者和订阅者之间有时间上的依赖性。
针对某个主题（Topic）的订阅者，它必须创建一个订阅者之后，才能消费发布者的消息。
为了消费消息，订阅者必须保持运行的状态。

通过这两张图片，我们应该能比较清晰的分辨出这两种模式的区别

三、常用协议

只要是通信之间，就会用到协议，就像我们说话的语言一样，不同的语言连通着不同的人群。消息队列自然也是一样的也是一样，想要互相通信，就要使用同一种协议。

1、AMQP

AMQP即Advanced Message Queuing Protocol，是应用层协议的一个开放标准，为面向消息的中间件设计。消息中间件主要用于组件之间的解耦，消息的发送者无需知道消息使用者的存在，反之亦然。AMQP是二进制协议，主要特征是 面向消息、队列、路由（包括点对点和发布/订阅） 。

应用场景：当简单的发布－订阅模型不能满足使用要求。

优点：可靠、通用

2、STOMP

STOMP（Streaming Text Orientated Message Protocol）是流文本定向消息协议，是一种为MOM(Message Oriented Middleware，面向消息的中间件)设计的简单文本协议。STOMP提供一个可互操作的连接格式，允许客户端与任意STOMP消息代理（Broker）进行交互，通常作用于 发布－订阅 的模型。

应用场景：信息交换基于文本，要求简单的场景。

优点：命令模式（非topic/queue模式）

3、XMPP

XMPP（可扩展消息处理现场协议，Extensible Messaging and Presence Protocol）是基于可扩展标记语言（XML）的协议，多用于即时消息（IM）以及在线现场探测。适用于服务器之间的准即时操作。核心是基于XML流传输，这个协议可能最终允许因特网用户向因特网上的其他任何人发送即时消息，即使其操作系统和浏览器不同。 但XML编码格式占用带宽大 。

应用场景：尽可能的简化客户端，复杂的都放在服务端。

优点：通用公开、兼容性强、可扩展、安全性高

4、JMS

JMS是基于JVM消息代理的规范,是对AMQP，MQTT，STOMP，XMPP等协议更高一层的抽象。JMS是一个Java平台中关于面向消息中间件（MOM）的API，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。

应用场景：在java体系中，多个服务可以通过JMS进行交互，不需要应用修改代码，但是其对跨平台的支持较差。

优点：异步、可靠

四、常用MQ对比分析

简然要做MQ选型，我们肯定要从大量的MQ做选择，什么样的MQ更适合我们的项目，因此，了解每一种MQ的特征和优缺点是必不可少的。

1、RocketMQ

RocketMQ是阿里系下开源的一款 分布式、队列模型的消息中间件 ，原名Metaq，3.0版本名称改为RocketMQ，是阿里参照kafka设计思想使用java实现的一套MQ。同时将阿里系内部多款MQ产品（Notify、metaq）进行整合，只维护核心功能，去除了所有其他运行时依赖，保证核心功能最简化，在此基础上配合阿里上述其他开源产品实现不同场景下MQ的架构，目前主要多用于订单交易系统。

特点：

基于队列模型：具有高性能、高可靠、高实时、分布式等特点；
Producer、Consumer、队列都支持分布式；
Producer向一些队列轮流发送消息，队列集合称为Topic。Consumer如果做广播消费，则一个Consumer实例消费这个Topic对应的所有队列，如果做集群消费，则多个Consumer实例平均消费这个Topic对应的队列集合；
能够保证严格的消息顺序；
提供丰富的消息拉取模式；
高效的订阅者水平扩展能力；
实时的消息订阅机制；
亿级消息堆积能力；
较少的外部依赖。

优点：

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

缺点：

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

2、RabbitMQ

使用Erlang编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMPP, SMTP,STOMP，也正是如此，使的它变的非常重量级，更适合于企业级的开发。同时实现了Broker架构，核心思想是生产者不会将消息直接发送给队列，消息在发送给客户端时先在中心队列排队。对路由(Routing)，负载均衡(Load balance)、数据持久化都有很好的支持。多用于进行企业级的ESB整合。

特点：

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

优点：

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

缺点：

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

3、ActiveMQ

Apache下的一个子项目。使用Java完全支持JMS1.1和J2EE 1.4规范的 JMS Provider实现，少量代码就可以高效地实现高级应用场景。可插拔的传输协议支持，比如：in-VM, TCP, SSL, NIO, UDP, multicast, JGroups and JXTA transports。RabbitMQ、ZeroMQ、ActiveMQ均支持常用的多种语言客户端 C++、Java、.Net,、Python、 Php、 Ruby等。

特点：

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

优点：

跨平台(JAVA编写与平台无关，ActiveMQ几乎可以运行在任何的JVM上)；
可以用JDBC：可以将数据持久化到数据库。虽然使用JDBC会降低ActiveMQ的性能，但是数据库一直都是开发人员最熟悉的存储介质；
支持JMS规范：支持JMS规范提供的统一接口;
支持自动重连和错误重试机制；
有安全机制：支持基于shiro，jaas等多种安全配置机制，可以对Queue/Topic进行认证和授权；
监控完善：拥有完善的监控，包括WebConsole，JMX，Shell命令行，Jolokia的RESTful API；
界面友善：提供的WebConsole可以满足大部分情况，还有很多第三方的组件可以使用，比如hawtio；

缺点：

社区活跃度不高；
根据其他用户反馈，会出莫名其妙的问题，会丢失消息；
不适合用于上千个队列的应用场景；

4、Kafka

Kafka起初是由LinkedIn公司采用Scala语言开发的一个分布式、多分区、多副本且基于zookeeper协调的分布式消息系统，现已捐献给Apache基金会。它是一种高吞吐量的分布式发布订阅消息系统，以可水平扩展和高吞吐率而被广泛使用。目前越来越多的开源分布式处理系统如Cloudera、Apache Storm、Spark、Flink等都支持与Kafka集成。