Broker：接收和分发消息的应用，RabbitMQ Server 就是 Message Broker
在项目中使用RabbitMQ时，我们可能会遇到这样的问题:如一个订单系统当用户付款成功时我们往消息中间件添加一条记录期望消息消费者修改订单状态，但是最终实际订单状态并没有被修改成功。遇到这种问题我们排查的思路如下:
MQ(message queue)，从字面意思上看，本质是个队列，FIFO 先入先出，只不过队列中存放的内容是 message 而已，还是一种跨进程的通信机制，用于上下游传递消息。在互联网架构中，MQ 是一种非常常见的上下游“逻辑解耦+物理解耦”的消息通信服务。使用了 MQ 之后，消息发送上游只需要依赖 MQ，不用依赖其他服务。
MQ(message queue)，从字面意思上看，本质是个队列，FIFO 先入先出，只不过队列中存放的内容是message 而已，还是一种跨进程的通信机制，用于上下游传递消息。在互联网架构中，MQ 是一种非常常见的上下游“逻辑解耦+物理解耦”的消息通信服务。使用了 MQ 之后，消息发送上游只需要依赖 MQ，不用依赖其他服务。
RabbitMQ属于中间件的一种，其实很多东西都是中间件比如说mysql redis都是的 其实中间件是一种概念，只要是实现软件和软件之间沟通连接的软件都可以叫做中间件
消费者完成一个任务可能需要一段时间，如果其中一个消费者处理一个长的任务并仅只完成了部分突然它挂掉了，会发生什么情况。RabbitMQ 一旦向消费者传递了一条消息，便立即将该消息标记为删除。在这种情况下，突然有个消费者挂掉了，我们将丢失正在处理的消息。以及后续发送给该消费者的消息，因为它无法接收到。
RabbitMQ是实现了高级消息队列协议（AMQP）的开源消息代理软件（亦称面向消息的中间件）。RabbitMQ服务器是用Erlang语言编写的，而群集和故障转移是构建在开放电信平台框架上的。所有主要的编程语言均有与代理接口通讯的客户端库。
MQ全称为Message Queue，即消息队列， RabbitMQ是由erlang语言开发，基于AMQP（Advanced Message Queue 高级消息队列协议）协议实现的消息队列，它是一种应用程序之间的通信方法，消息队列在分布式系统开 发中应用非常广泛。RabbitMQ官方地址：http://www.rabbitmq.com/
是指应用程序对应用程序的一种高效可靠的消息传递的通信方法,通过提供消息传递和消息排序模型，他可以在分布式环境下扩展进程间的通信，典型的生产者和消费者的代表
早在之前就了解到了消息中间件，但是一直没有系统的学习，最近花了一段时间系统学习了当下最为主流的 RabbitMQ 消息队列，学习过程中也随时记录，刚开始学习的时候懵懵懂懂，做的笔记都比较杂乱，系统学习完后我将笔记内容不断反复修改，对章节进行设计调整，最终整合出了以下好理解、案例多、超详细的 RabbitMQ 学习笔记，希望能帮到大家～
比如有一个订单系统，还要一个库存系统，用户下订单后要调用库存系统来处理，直接调用话，库存系统出现问题咋办呢？
默认的端口15672：rabbitmq管理平台端口号 默认的端口5672： rabbitmq消息中间内部通讯的端口 默认的端口号25672 rabbitmq集群的端口号
RabbitMQ 就是 AMQP 协议的 Erlang 的实现(当然 RabbitMQ 还支持 STOMP2、 MQTT3 等协议 ) AMQP 的模型架构和 RabbitMQ 的模型架构是一样的，生产者将消息发送给交换器，交换器和队列绑定 。
**Connection** **极大减少了操作系统建立** **TCP connection** **的开销**
导文： 1.什么是RabbitMQ 2.Java开发技术大杂烩(三）之电商项目优化、rabbitmq、Git、OSI、VIM、Intellj IDEA、HTTP、JS、Java
根据RabbitMQ的工作模式，一条消息从生产者发出，到消费者消费，需要经历以下4个步骤：
答：采用AMQP高级消息队列协议的一种消息队列技术,最大的特点就是消费并不需要确保提供方存在,实现了服务之间的高度解耦
RabbitMQ和Kafka都提供持久的消息保证。两者都提供至少一次和至多一次的保证，另外，Kafka在某些限定情况下可以提供精确的一次（exactly-once）保证。
Java面试总结汇总，整理了包括Java基础知识，集合容器，并发编程，JVM，常用开源框架Spring，MyBatis，数据库，中间件等，包含了作为一个Java工程师在面试中需要用到或者可能用到的绝大部分知识。欢迎大家阅读，本人见识有限，写的博客难免有错误或者疏忽的地方，还望各位大佬指点，在此表示感激不尽。文章持续更新中…
利用RabbitMQ集群横向扩展能力，均衡流量压力，让消息集群的秒级服务能力达到百万，Google曾做过此类实验；有货在某些推送场景下也做了类似尝试，在此对此前实践经验以及踩得坑做些总结工作。
—1— 背景 利用RabbitMQ集群横向扩展能力，均衡流量压力，让消息集群的秒级服务能力达到百万，Google曾做过此类实验；有货在某些推送场景下也做了类似尝试，在此对此前实践经验以及踩得坑做些总结工作。 RabbitMQ概述 RabbitMQ是基于AMQP协议实现的消息中间件的一种，常用于在分布式系统中存储转发消息，表现为易用、可扩展、高可用等特点，最初活跃在金融系统中。消息中间件的主要作用是让服务组件之间能够解耦，消息生产者无需关注消息消费者的存在与行为。 1.Message:由Producer发出
公众号改版后文章乱序推荐，希望你可以点击上方“Java进阶架构师”，点击右上角，将我们设为★“星标”！这样才不会错过每日进阶架构文章呀。
解耦：A 系统发送数据到 BCD 三个系统，通过接口调用发送。如果 E 系统也要这个数据呢？那如果 C 系统现在不需要了呢？A 系统负责人几乎崩溃…A 系统跟其它各种乱七八糟的系统严重耦合，A 系统产生一条比较关键的数据，很多系统都需要 A 系统将这个数据发送过来。如果使用 MQ，A 系统产生一条数据，发送到 MQ 里面去，哪个系统需要数据自己去 MQ 里面消费。如果新系统需要数据，直接从 MQ 里消费即可；如果某个系统不需要这条数据了，就取消对 MQ 消息的消费即可。这样下来，A 系统压根儿不需要去考虑要给谁发送数据，不需要维护这个代码，也不需要考虑人家是否调用成功、失败超时等情况。
RabbitMQ提供了publisher confirm机制来避免消息发送到MQ过程中丢失。这种机制必须给每个消息指定一个唯一ID。消息发送到MQ以后，会返回一个结果给发送者，表示消息是否处理成功。
「 户外依然大雨滂沱，只是这回彷彿不仅命运一人独自哭泣，不晓得由来，窗外的雨水似乎渗上我心头，有些寒冻，有些缩麻，还有些苦涩。城市万家灯火，橘黄街灯与家户里的温暖流洩，我总觉得这时候的我，最脆弱。-----Y」
在消息队列选型时，我们调研了市场上比较常用ActiveMQ，RabbitMQ，RocketMQ，Kafka。
fanout exchange 可以做成备份的交换机，因为 fanout 的消息是广播的方式
当连接失败时，消息可能还在客户端和服务器之间传输 - 它们可能处于两侧的解码或编码的中间过程，在 TCP 堆栈缓冲区中，或在电线上飞行。 在这种情况下，传输中的信息将无法正常投递 - 它们需要被重新投递。Acknowledgements机制让服务器和客户端知道何时需要重新投递。
当消息与任一绑定的队列符合匹配标准时，RabbitMQ服务器将以FIFO的顺序将消息放入队列中。放入队列数据结构中的并不是实际消息，而是消息的引用
RabbitMQ是一个消息中间件:它接受并转发消息。你可以把它当做一个快递站点，当你要发送一个包裹时，你把你的包裹放到快递站，快递员最终会把你的快递送到收件人那里，按照这种逻辑RabbitMQ是一个快递站，一个快递员帮你传递快件。RabbitMQ与快递站的主要区别在于，它不处理快件而是接收，存储和转发消息数据。
采用 AMQP 高级消息队列协议的一种消息队列技术,最大的特点就是消费并不需要确保提供方存在,实现了服务之间的高度解耦
通过程序执行发现生产者总共发送 4 个消息，消费者 1 和消费者 2 分别分得两个消息，并且是按照有序的一个接收一次消息
消息（Message）是指应用于应用之间传送的数据，消息的类型包括文本字符串、JSON、XML、内嵌对象等等...
生产消息的应用，生产者需要指定将消息发送到哪个exchange，并且指定routingkey(这是为了exchange可以将消息路由到相关的队列)。
RabbitMQ 是一个开源的消息代理和队列服务器，用来通过普通协议在完全不同的应用中间共享数据，RabbitMQ 是使用 Erlang 语言来编写的，并且 RabbitMQ 是基于 AMQP 协议的。
https://gitee.com/boring-yingjie/rabbit-mq-message-confirmation.git
1.生产者(Publisher): 发布消息到RabbitMQ中的交换机(Exchange)上
消息生产者如果向交换机发送了一个无法被路由到任何队列上的消息,那么此时交换机会判断消息的mandatory属性值:
关于消息队列，从前年开始断断续续看了些资料，想写很久了，但一直没腾出空，近来分别碰到几个朋友聊这块的技术选型，是时候把这块的知识整理记录一下了。
1983年孟买26岁的工程师Vivek Ranadive设想一种软件总线，同年Teknekron诞生了。
当初我学RabbitMQ的时候，第一时间就上GitHub找相应的教程，但是令我很失望的是没有找到，Spring，Mybatis之类的教程很多，而RabbitMQ的教程几乎找不到，看的最多的就是朱小厮大佬的博客。后来想着索性自己总结一下吧，有不恰当的地方欢迎小伙伴指出。
RabbitMQ是一个流行的开源消息中间件，被广泛用于分布式系统和企业应用中。它是一个可靠的、高效的、可扩展的、支持多种消息协议的消息队列系统。本文将介绍RabbitMQ的基础知识，包括其功能、Spring MVC的集成和各个功能点的介绍和使用方法。
队列(queue)：存在RabbitMQ中的邮筒，虽然消息是在应用程序和RabbitMQ中进行传递，但队列才是唯一能够存储消息的地方。队列的大小取决于宿主机器的内存和磁盘容量，它本质上是一个巨大的消息缓存池。多个生产者可以发送消息给同一个队列，多个消费者也可以从同一个队列中读取消息。这个队列有一个特点，先进先出。
使用微服务系统，组件之间充分解耦 使用消息中间件，解耦业务逻辑 使用数据库，持久化业务数据
消息发送的几种模式 4种交换器类型 Direct Exchange: 直连交换器 小结：直连交换器发送消息会根据路由和交换机的绑定关系发送到队列 如果交换器名称为"",将使用默认交换器 默认交换器不会绑定任何队列，mq会直接把route_key当做queue名称去查找 Fanout Exchange: 分发交换器（扇出交换器） 小结: 分发交换器发送消息会分发至所有和其有绑定的队列中，这样消息会被多个消费者
消息确认是保证消息传递可靠性的重要步骤，上一节我们说到持久化，持久化只能保证消息不丢失，但是如果消息如果投递失败我们怎么进行补偿操作呢？解决办法就是实现回调函数进行操作，在消息的发送和消息的消费都可以进行补偿操作，下面我们就要讲解消息确认。
SpringBoot中使用RabbitMQ消息队列——路由、通配符、订阅模式 这篇文章中已经整合了rabbitmq。
原文链接：https://chaser520.iteye.com/blog/2428253
发送方确认模式：将信道设置成confirm模式（发送方确认模式），则所有在信道上发布的消息都会被指派一个唯一的ID。一旦消息被投递到目的队列后，或者消息被写入磁盘后（可持久化的消息），信道会发送一个确认给生产者（包含消息唯一ID）。如果RabbitMQ发生内部错误从而导致消息丢失，会发送一条nack（not acknowledged，未确认）消息。
距离上一次发文章已经很久了，其实这段时间一直也没有停笔，只不过在忙着找工作还有学校结课的事情，重新弄了一下博客，后面也会陆陆续续会把文章最近更新出来~
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
