下载文档原格式
消息中间件与rabbitmq（⼀）本⽂将从三步讲述消息中间件从⽣产消费者模型到消息中间件⽣产消费者模型的作⽤以及适⽤场景⼿动实现消费⽣产者模型的缺陷消息队列消息中间件消息中间件的定义与常⽤类型消息中间价的操作消息中间件的选型消息中间的优缺点消息队列定义消息队列，⼀般我们会简称它为MQ(Message Queue)，直⽩的说就是储存消息与释放消息的先进先出结构。
那么把数据放到消息队列叫做⽣产者，从消息队列⾥边取数据则被叫做消费者。
三⼤属性作为消息队列⼀般具备如下3⼤属性：消息顺序 分区有序的队列通过分布式处理，⽀持更⾼的并发，但由于队列的分布式特性，DMS⽆法保证能够以接收消息的精确顺序进⾏消费。
如果⽤户要求保持顺序，建议在每条消息中放置排序信息，以便在收到消息时对消息重新排序。
全局有序的队列对消息消费遵循先⼊先出规则（FIFO），适⽤于对消费顺序要求较⾼的场景。
⾄少⼀次传递 在极少数情况下，当⽤户接收或删除消息时，存储消息副本的服务器之⼀可能不可⽤。
如果出现这种情况，则该不可⽤服务器上的消息副本将不会被删除，并且在接收消息时可能会再次获得该消息副本。
这被称为“⾄少⼀次传递”，因此，⽤户的应⽤程序应该设计为幂等的应⽤程序（即，如果应⽤程序多次处理同⼀条消息，则不得受到不利影响）。
消息较少时单次消费不能获取指定数量的消息 从消息队列中消费消息时，DMS每次从部分消息存储分区中读取消息返回消息给消费者，如果队列中的消息数⽐较少，则单次消费可能会少于指定条数，但多次消费最终可获取全部消息。
功能与优点解耦弹性伸缩冗余存储流量削峰异步通信数据同步1，解耦我们作为A系统开发，当A系统处于1时刻的时候他只需需要向系统B与系统C提供相应的数据，但是因为某些原因B系统需要被D系统替代，那么我们要在A代码中去掉B系统的换成C系统。
⽐如后来下游数据系统⼜出现问题，那么我们是不是⼜要更改代码。
但是我们可以直接发数据发送给相应的消息队列，然后让BCD。
RabbitMQ-消息中间件协议
（AMQP,MQTT,OpenMessage,Kafka）
消息中间件常⽤协议
消息中间件的协议，都是基于tcp/ip,或者是udp协议。
但是单纯的tcp/ip,或者是udp⽆法满⾜消息队列的功能，因此在此基础上发展出下⾯的协议。
（尽管HTTP协议也是基于tcp/ip,或者是udp，但依然不采⽤，理由见下⽂）
AMQP（⾼级消息队列协议）
特点：
⽀持分布式
rabbitMQ和ActiveMQ⽀持该协议
MQTT（消息队列遥测传输协议）
特点：
适⽤物联⽹
低宽带，⽹络不稳定状况
rabbitMQ和ActiveMQ⽀持该协议（但是默认关闭⽀持，需要⼿动打开）
OpenMessage协议
Kafka协议
特点：
⼆进制协议，效率极好
不⽀持事务
⾯试题：为什么消息中间件不直接使⽤http协议呢？。
消息中间件术语消息中间件（Messaging Middleware）是指用于不同应用程序或组件之间进行通信和传递消息的软件工具。
它充当了应用程序之间的桥梁，使得它们可以高效地进行信息交流和协作。
消息中间件通过提供一种异步、可靠和可扩展的通信机制，帮助不同的应用程序实现解耦和可靠性。
消息中间件的核心概念包括消息、生产者、消费者和代理。
消息是信息的载体，可以是文本、对象或二进制数据。
生产者是消息的发送者，负责将消息发送到消息中间件。
消费者是消息的接收者，负责从消息中间件中获取消息并进行处理。
代理是消息中间件的核心组件，负责接收、存储和转发消息。
消息中间件的一个重要特性是异步通信。
在传统的同步通信方式中，发送者和接收者必须同时在线才能进行通信，这对于分布式系统来说是一种限制。
而异步通信则解决了这个问题，发送者和接收者可以分别独立地进行操作，通过消息中间件来传递消息。
这种方式可以提高系统的灵活性和可伸缩性。
另一个重要特性是可靠性。
消息中间件通常会提供消息持久化机制，即使在消息发送或接收过程中出现故障，消息也能够得到保存并在故障恢复后重新发送。
这种机制可以确保消息的可靠传递，避免消息的丢失或重复处理。
消息中间件还可以实现发布-订阅模式（Publish-Subscribe），这是一种常见的消息传递模式。
在发布-订阅模式中，生产者将消息发布到主题（Topic）上，而多个消费者可以订阅这个主题并同时接收消息。
这种模式可以实现一对多的消息传递，适用于广播和通知场景。
除了发布-订阅模式，消息中间件还支持点对点模式（Point-to-Point）。
在点对点模式中，生产者将消息发送到队列（Queue）中，而消费者通过从队列中获取消息来接收。
这种模式适用于任务分发和负载均衡等场景。
消息中间件的另一个重要应用是事件驱动架构（Event-Driven Architecture）。
在事件驱动架构中，系统的各个组件通过发送和接收事件来进行协作。
常见的中间件有哪些？世界著名的资讯机构GigaGroup把中间件分为三大类，共十五种。
另一家世界著名的资讯机构IDC同时指出，最近几年到未来的2002年，增长率最高的中间件将集中在数据存取中间件、消息中间件、交易中间件、对象中间件、应用服务器中间件5种。
·数据访问中间件适用于应用程序与数据源之间的互操作模型，客户端使用面向数据库的API，以提请直接访问和更新基于服务器的数据源，数据源可以是关系型、非关系型和对象型。
这类中间件大都基于SQL语句，采用同步通讯方式。
此类中间件使应用开发简单，但如果是透过广域网使用，会带来严重的效率问题，因为在低速网上来回交互SQL语句会使通讯流量过大，同时对数据压缩、加密带来不便。
·消息中间件消息中间件适用于需要进行网络通信的系统上，负责建立网络通信的逻辑通道，由消息中间件实现数据或文件发送。
消息中间件的一个重要作用是可以实现跨平台操作，越来越多的分布式应用采用消息中间件来构建，通过消息中间件来把应用扩展到不同的操作系统和不同的网络环境中间件领域目前最热门的技术是异步的消息中间件，异步中间件技术比同步中间件技术具有更强的容错性，在系统故障时可以保证消息的正常传输，因而在过去的两年里增长迅速。
·交易中间件交易中间件是专门针对联机交易处理系统而设计的。
交易中间件就是一组程序模块，用以大大减少开发一个联机交易处理系统所需的编程量。
交易中间件的主要标准是X/OPEN组织定义的分布式交易处理参考模型。
交易中间件理论上相对成熟，功能和性能界定清晰，但基本上适用于联机交易系统，如银行业务系统、定票系统等。
交易中间件管理由应用声明和提交的交易，并通过两阶段提交协议等方式保证分布式交易的完整性、控制并发、实现交易路由和均衡负载。
·对象中间件面向对象的中间件提供一个标准的构件框架，能使不同的厂家的软件通过不同的地址空间、网络和操作系统互相交互访问。
主流消息中间件架构分析Kafka首先还是来看Kafka的系统架构（做消息中间件逃不开要去了解Kafka）。
Kafka ecosystem包含以下几块内容：•Producer•Consumer•Kafka cluster•ZooKeeper其中ZooKeeper承当了NameServer的角色，同时用于保存系统的元数据，提供选主、协调等功能。
Broker是真正的服务端，用于存储消息。
可用性首先看外部依赖的可用性。
如果你的系统“强依赖”了外部的其他服务，那么你的系统的可用性必然和外部服务的可用性相关。
（强依赖表示不可脱离依赖的服务保持正常运行）从上面的架构可以看出Kafka只是依赖了ZooKeeper，而ZooKeeper本身是高可用的（2N+1个节点的ZK集群可以容忍N个节点故障），所以不会对整个集群的可用性造成影响。
接着看Kafka自身的可用性。
谈可用性必然就会涉及到备份问题，没有备份就意味着存在单点问题，也就没有高可用可言了。
所以我们具体来看一下Kafka的备份策略。
Kafka Replication的数据流如上图所示，从图中可以得到的一些信息：1. 分区是有备份的，如topic1-part1上图中有3个2. 分区的备份分布在不同的Broker上，上图中topic1-part1分布在broker1、broker2、broker3上，其中broker1上的为Leader3. 分区的Leader是随机分布的，上图中topic1-part1的Leader在broker1，topic2-part1的Leader在Broker上，topic3-part1的Leader的Broker4上4. 消息写入到Leader分区，之后通过Leader分区复制到Follower分区Kafak这样的Replication策略，保证了任何一个Broker出现故障时，系统依旧是可用的。
如broker1出现故障，此时会重新选举topic1-part1的Leader，之后可能是broker2或者broker3上的topic1-part1成为Leader然后负责消息的写入。
消息中间件概述什么是消息中间件？消息中间件(MQ)的定义其实并没有标准定义。
⼀般认为，消息中间件属于分布式系统中⼀个⼦系统，关注于数据的发送和接收，利⽤⾼效可靠的异步消息传递机制对分布式系统中的其余各个⼦系统进⾏集成。
⾼效：对于消息的处理处理速度快。
可靠：⼀般消息中间件都会有消息持久化机制和其他的机制确保消息不丢失。
异步：指发送完⼀个请求，不需要等待返回，随时可以再发送下⼀个请求，既不需要等待。
⼀句话总结，我们消息中间件不⽣产消息，只是消息的搬运⼯。
为什么要⽤消息中间件？假设⼀个电商交易的场景，⽤户下单之后调⽤库存系统减库存，然后需要调⽤物流系统进⾏发货，如果交易、库存、物流是属于⼀个系统的，那么就是接⼝调⽤。
但是随着系统的发展，各个模块越来越庞⼤、业务逻辑越来越复杂，必然是要做服务化和业务拆分的。
这个时候就需要考虑这些系统之间如何交互，⼀般的处理⽅式就是RPC（Remote Procedure Call）（具体实现dubbo,SpringCloud）。
系统继续发展，可能⼀笔交易后续需要调⽤⼏⼗个接⼝来执⾏业务，⽐如还有风控系统、短信服务等等。
这个时候就需要消息中间件登场来解决问题了。
所以消息中间件主要解决分布式系统之间消息的传递，同时为分布式系统中其他⼦系统提供了松耦合的架构，同时还有以下好处： 低耦合 低耦合，不管是程序还是模块之间，使⽤消息中间件进⾏间接通信。
异步通信能⼒ 异步通信能⼒，使得⼦系统之间得以充分执⾏⾃⼰的逻辑⽽⽆需等待。
缓冲能⼒ 缓冲能⼒，消息中间件像是⼀个巨⼤的蓄⽔池，将⾼峰期⼤量的请求存储下来慢慢交给后台进⾏处理，对于秒杀业务来说尤为重要。
伸缩性 伸缩性，是指通过不断向集群中加⼊服务器的⼿段来缓解不断上升的⽤户并发访问压⼒和不断增长的数据存储需求。
就像弹簧⼀样挂东西⼀样，⽤户多，伸⼀点，⽤户少，浅⼀点，啊，不对，缩⼀点。
是伸缩，不是深浅。
衡量架构是否⾼伸缩性的主要标准就是是否可⽤多台服务器构建集群，是否容易向集群中添加新的服务器。
数据通信中间件的比较与仿真测试①数据通信中间件是一种用于实现分布式系统中不同节点之间的数据交流和通信的软件。
它们可以在不同节点之间传递数据，提供高效的通信机制，确保数据的安全传输和可靠性。
它们还可以对数据进行处理和转换，实现节点之间的数据同步和共享。
目前市场上有许多不同的数据通信中间件可供选择。
下面对其中的一些中间件进行比较与仿真测试，以便更好地了解它们的优缺点和适用场景。
1. ZeroMQ：ZeroMQ是一种轻量级的消息队列中间件，它支持多种通信模式，包括请求-回应、发布-订阅和推送-拉取。
它具有快速、可靠和灵活等特点，在高并发的场景下表现良好。
在仿真测试中，ZeroMQ的吞吐量和延迟都比较优秀，可以满足大部分分布式系统的通信需求。
2. RabbitMQ：RabbitMQ是一种基于AMQP协议的消息队列中间件，它以可靠性和稳定性著称。
它支持消息持久化、消息路由和负载均衡等功能，可以满足高可靠性和高可用性的需求。
在仿真测试中，RabbitMQ的吞吐量较低，延迟较高，适用于对数据传输有较高要求的场景。
3. Apache Kafka：Kafka是一种分布式流处理平台，可以用于构建实时数据流应用程序和系统。
它以高吞吐量、可持久化和可水平扩展等特点著称。
在仿真测试中，Kafka的吞吐量和延迟表现出色，适用于对数据传输速度要求较高的大规模数据处理系统。
4. Redis：Redis是一个高性能的内存数据库，可用作缓存、发布-订阅系统和消息队列。
它支持多种数据结构和多种协议，并具有快速读写、持久化和高可用性等特点。
在仿真测试中，Redis的吞吐量和延迟都表现出色，适用于对数据处理速度要求较高的场景。
不同的数据通信中间件适用于不同的场景和需求。
在选择中间件时，需要考虑系统的性能要求、数据传输的可靠性和安全性等因素。
通过进行比较和仿真测试，可以选出最适合自己系统的数据通信中间件。
消息中间件（MQ）⾸先MQ是什么？MQ是Message Queue(消息队列)。
消息队列是⼀种应⽤程序对应⽤程序之间的通信⽅法、应⽤程序通过写和检索⼊列队的针对应⽤程序的数据（消息）来进⾏通信，⽽不需要专⽤连接来链接它们。
消息传递指的是程序之间通过在消息中发送数据进⾏通信，⽽不是直接调⽤彼此来通信，直接调⽤通常是⽤于诸如远程过程调⽤的技术。
排队指的是在应⽤程序通过队列来通信，队列的使⽤除去了接收和发送应⽤程序同时执⾏的要求。
消息中间件的概况：消息队列技术是分布式应⽤间交换信息的⼀种技术，消息队列可驻留在内存或者磁盘上，队列存储消息直到它们被应⽤程序读⾛为⽌，应⽤程序可独⽴的执⾏，它们不需要直到彼此的位置。
或者继续执⾏前不需要等待接收程序接收到的消息。
MQ相关的概念：（1）消息(Message)：消息是MQ中最⼩的概念，本质上是⼀段数据，它能被⼀个或多个应⽤程序理解，是应⽤程序之间传递的消息载体。
（2）队列(Queue) a、本地队列：本地队列按照功能划分为初始化队列、传输队列、死信队列 初始化队列：⽤作消息触发的功能 传输队列：只是暂存待传的消息，条件许可的情况下，通过管道将消息传递达到其他的队列管理器。
⽬标队列：是消息的⽬的地，可以长期存放消息 死信队列：当消息不能送到⽬标队列，也不再路由出去。
则⾃动放⼊死信队列保存。
b、别名队列和远程队列 只是⼀个队列的定义，⽤来指定远程队⾥管理器的队列、使⽤了远程队列，程序就不需要知道⽬标队列的位置。
c、模型队列：模型队列定义了⼀套本地队列的属性结合，⼀旦打开模型队列，队列管理器会按照这些属性动态的创建出⼀个本地队列。
（3）队列管理器（Queue Manager）队列管理器是⼀个负责向应⽤程序提供消息服务的机构，如果把队列管理器⽐作数据库，那么队列就是其中的⼀张表。
（4）通道（channel）通道是两个管理器之间的⼀种单向点对点的通信连接，若需要双向交流，可建⽴⼀对通信。
市场上的消息中间件： mom4j mom4j是一个完全实现JMS1.1规范的消息中间件并且向下兼容JMS1.0与1.02.它提供了自己的消息处理存储使它独立于关系数据与语言,所以它的客户端可以用任何语言开发.
OpenJMS
OpenJMS是一个开源的Java Message Service API 1.0.2 规范的实现,它包含有以下特性： *. 它既支持点到点（point-to-point）（PTP）模型和发布/订阅（Pub/Sub）模型。 *. 支持同步与异步消息发送 *. JDBC持久性管理使用数据库表来存储消息 *. 可视化管理界面。 *. Applet支持。 *. 能够与Jakarta Tomcat这样的Servlet容器结合。 *. 支持RMI, TCP, HTTP 与SSL协议。 *. 客户端验证 *. 提供可靠消息传输、事务和消息过滤
UberMQ
UberMQ完全实现了Java Message Service 规范。UberMQ是因为现有的许多JMS提供商已经违背了分布式计算的核心原则：快速与简单而开发的。 Hermes JMS
利用它提供的Swing UI可以很好的实现监控JMS providers。 ActiveMQ
ActiveMQ是一个开放源码基于Apache 2.0 licenced 发布并实现了JMS 1.1。它能够与Geronimo，轻量级容器和任Java应用程序无缝的给合。
Somnifugi
Somnifugi使得工作在同一个java虚拟机中的线程能实现消息互发。 MantaRay
MantaRay基于peer-2-peer 技术。它具有以下特性: 1.它既支持点对点(point-to-point)的域，又支持发布/订阅(publish/subscribe)类型的域。 2.并且提供对下列类型的支持：经认可的消息传递,事务型消息的传递，一致性消息和具有持久性的订阅者支持。 3.消息过滤体制。 4.能与WebLogic and WebSphere 给合。 5.支持TCP, UDP 与 HTTP传输协。 Presumo Presumo也是一个实现Java Message Service API的JMS消息中间件。 JORAM
JORAM一个类似于openJMS分布在ObjectWeb之下的JMS消息中间件。 JMS4Spread
JMS4Spread是一个消息系统.它部分地实现了Java消息服务(JMS) API. Open Message Queue
Open Message Queue是Sun Java System Message Queue的一个开源版本。Open message queue是一个企业级，可升级，非常成熟的消息服务器。它为面向消息的系统集成提供一套完整的JMS（Java Message Service ）实现。由于Open MQ源自Sun的Java Message Queue，所以其具有Java System Message Queue拥有的所有特性，功能和性能 。
FFMQ
FFMQ是一个轻量级，高性能，快速的Native JMS1.1开源实现。支持SSL远程连接，自动防故障的持久化机制，基于模板定义目的地（Destination），采用模式匹配自动创建目的地（Destination）。
MQSSave/MQSLoad
MQSSave是一个简单的Java程序，能够读取MQSeries队列的消息保存至文件中。而MQSLoad是一相反的Java程序，能够读取文件中的消息然后加载至MQSeries队列中。
HornetQ
HornetQ是一个支持集群和多种协议，可嵌入、高性能的异步消息系统。HornetQ完全支持JMS，HornetQ不但支持JMS1.1 API同时也定义属于自己的消息API，这可以最大限度的提升HornetQ的性能和灵活性。在不久的将来更多的协议将被HornetQ支持。 HornetQ拥有超高的性能，HornetQ在持久化消息方面的性能可以轻易的超于其它常见的非持久化消息引擎的性能。当然，HornetQ的非持久化消息的性能会表现的更好！ HornetQ完全使用POJO，纯POJO的设计让HornetQ可以尽可能少的以来第三方的包。从设计模式来说，HornetQ这样的设计入侵性也最小。HornetQ既可以独立运行，也可以与其它Java应用程序服务器集成使用。 HornetQ拥有完善的错误处理机制，HornetQ提供服务器复制和故障自动转移功能，该功能可以消除消息丢失或多个重复信息导致服务器出错。 HornetQ提供了灵活的集群功能，通过创建HornetQ集群，您可以享受到到消息的负载均衡带来的性能提升。您也可以通过集群，组成一个全球性的消息网络。您也可以灵活的配置消息路由。 HornetQ拥有强大的管理功能。HornetQ提供了大量的管理API和监控服务器。它可以无缝的与应用程序服务器整合，并共同工作在一个HA环境中。
Apache Qpid Apache Qpid是最新开放企业信息标准AMQP（Advanced Message Queuing Protocol）的一个开源实现。Java版实现完全支持JMS标准，可运行在任意Java平台上。此外Qpid还提供AMQP Client APIs的各种语言实现包括： C++ Java, fully conformant with JMS 1.1 C# .NET, 0-10 using WCF Ruby Python
Spring AMQP
Spring AMQP是一个用于替换原先Spring JMS支持的消息解决方案。提供收发消息的模板，还支持基于消息驱动的POJO。用法和配置与Spring中对JMS的支持一样。这个项目包含Java和.NET两个版本。
Kafka
Kafka是一个高吞吐量分布式消息系统。linkedin开源的kafka。 Kafka就跟这个名字一样，设计非常独特。首先，kafka的开发者们认为不需要在内存里缓存什么数据，操作系统的文件缓存已经足够完善和强大，只要你不搞随机写，顺序读写的性能是非常高效的。kafka的数据只会顺序append，数据的删除策略是累积到一定程度或者超过一定时间再删除。Kafka另一个独特的地方是将消费者信息保存在客户端而不是MQ服务器，这样服务器就
不用记录消息的投递过程，每个客户端都自己知道自己下一次应该从什么地方什么位置读取消息，消息的投递过程也是采用客户端主动pull的模型，这样大大减轻了服务器的负担。Kafka还强调减少数据的序列化和拷贝开销，它会将一些消息组织成Message Set做批量
存储和发送，并且客户端在pull数据的时候，尽量以zero-copy的方式传输，利用sendfile（对应java里的 FileChannel.transferTo/transferFrom）这样的高级IO函数来减少拷贝开销。可见，kafka是一个精心设计，特定于某些应用的MQ系统，这种偏向特定领域的MQ系统我估计会越来越多，垂直化的产品策略值的考虑。 play-rabbitmq 这是Play! Framework开发框架的一个扩展模块。用于生产和消费RabbitMQ消息。 队列消息系统 FQueue
FQueue是一个高性能、基于磁盘持久存储的队列消息系统。兼容memcached协议，能用memcached的语言都可以良好的与它通信。 FQueue为你提供一个不需要特别优化，高性能的一个消息系统。
特性 1. 基于磁盘持久化存储。 2. 支持memcached协议。 3. 支持多队列，密码验证功能。 4. 高性能，能达到数十万qps。 5. 低内存消耗。100-300M内存即可工作得很好。 6. 高效率IO读写算法，IO效率高。 7. 纯JAVA代码。支持进程内JVM级别的直接调用。 8. 在不需要强顺序的场景下，支持多机负载均衡。 不支持 1. 不支持topic方式的订阅功能。 2. 不支持主从复制。
主流消息中间件及选型推荐： ActiveMQ:（还有升级版叫Apollo, 由于转向Scala，原来的架构都要改掉。但是只支持storm协议，不支持JMS），在网络上别人反映，消息量越来越大时，当出现消息堆积时，性能争骤下降，主要卡在磁盘写入，用了硬件加速，也还是不能忍受。
消息中间件的技术选型心得－RabbitMQ、ActiveMQ和ZeroMQ 作者：chszs，转载需注明。博客主页：http://blog.csdn.net/chszs RabbitMQ、ActiveMQ和ZeroMQ都是极好的消息中间件，但是我们在项目中该选择哪个更适合呢？很多开发者面临这个烦恼。下面我会对这三个消息中间件做一个比较，看了后你们就心中有数了。
RabbitMQ是AMQP协议领先的一个实现，它实现了代理(Broker)架构，意味着消息在发送到客户端之前可以在中央节点上排队。此特性使得RabbitMQ易于使用和部署，适宜于很多场景如路由、负载均衡或消息持久化等，用消息队列只需几行代码即可搞定。但是，这使得它的可扩展性差，速度较慢，因为中央节点增加了延迟，消息封装后也比较大。
ZeroMQ是一个非常轻量级的消息系统，专门为高吞吐量/低延迟的场景开发，在金融界的应用中经常可以发现它。与RabbitMQ相比，ZeroMQ支持许多高级消息场景，但是你必须实现ZeroMQ框架中的各个块（比如Socket或Device等）。ZeroMQ非常灵活，但是你必须学习它的80页的手册（如果你要写一个分布式系统，一定要阅读它）。
