RabbitMQ无疑是目前最流行的消息队列之一，对各种语言环境的支持也很丰富，作为一个.NET developer有必要学习和了解这一工具。消息队列的使用场景大概有3种：
关于数据一致性的文章，园子里已经有很多了，如果你还不了解，那么可以通过以下的几篇文章去快速地了解了解，有个感性认识即可。
消费者的类型包括：普通消费者，saga，saga 状态机，路由活动（分布式追踪），处理器 handlers，工作消费者 job comsumers
MassTransit，直译公共交通， 是由Chris Patterson开发的基于消息驱动的.NET 分布式应用框架，其核心思想是借助消息来实现服务之间的松耦合异步通信，进而确保应用更高的可用性、可靠性和可扩展性。通过对消息模型的高度抽象，以及对主流的消息代理（包括RabbitMQ、ActiveMQ、Kafaka、Azure Service Bus、Amazon SQS等）的集成，大大简化了基于消息驱动的开发门槛，同时内置了连接管理、消息序列化和消费者生命周期管理，以及诸如重试、限流、断路器等异常处理机制，让开发者更好的专注于业务实现。 简而言之，MassTransit实现了消息代理透明化。无需面向消息代理编程进行诸如连接管理、队列的申明和绑定等操作，即可轻松实现应用间消息的传递和消费。
Saga 最初出现在1987年Hector Garcaa-Molrna & Kenneth Salem发表的一篇名为《Sagas》的论文里。其核心思想是将长事务拆分为多个短事务，借助Saga事务协调器的协调，来保证要么所有操作都成功完成，要么运行相应的补偿事务以撤消先前完成的工作，从而维护多个服务之间的数据一致性。举例而言，假设有个在线购物网站，其后端服务划分为订单服务、支付服务和库存服务。那么一次下订单的Saga流程如下图所示：
MassTransit本身定位轻量级的服务总线，并支持多种传输方式如：RabbitMQ、Azure Service Bus、ActiveMQ、Amazon SQS、Kafka、Azure Event Hub。消息异常处理：重试配置、重新交付、erro管道、死信管道。分布式事务处理：sagas、Courier。容器支持：.NETcore自身的、autofac、castle windsor等、调度支持：Quartz 、hangfire。更多功能参考官网文档。
方法改为 CreateUsingRabbitMq，并且添加 rabbitmq host
DAPP的底层区块链开发平台，就像手机的iOS和Android系统一样，是各种DAPP的潜在生态环境。DApp是源自底层区块链平台生态的各种分布式应用程序，也是区块链世界中的基本服务提供商。Dapp在区块链中，就像应用程序在iOS和Android中一样。
RabbitMQ是使用Erlang编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMPP, SMTP, STOMP，也正因如此，它非常重量级，更适合于企业级的开发。同时实现了Broker构架，这意味着消息在发送给客户端时先在中心队列排队。对路由，负载均衡或者数据持久化都有很好的支持。
消息冲队列移除之后，在一定时间之后重新投入消息队列。需要配置调度模块（scheduling）
状态机作为一种程序开发范例，在实际的应用开发中有很多的应用场景，其中.NET 中的async/await 的核心底层实现就是基于状态机机制。状态机分为两种：有限状态机和无限状态机，本文介绍的就是有限状态机，有限状态机在任何时候都可以准确地处于有限状态中的一种，其可以根据一些输入从一个状态转换到另一个状态。一个有限状态机是由其状态列表、初始状态和触发每个转换的输入来定义的。如下图展示的就是一个闸机的状态机示意图：
RabbitMQ是一个开源的AMQP实现，服务器端用Erlang语言编写，支持多种客户端，如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等，支持AJAX。用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性等方面表现不俗。
Saga模式使用一系列本地事务来提供事务管理，而一个本地事务对应一个Saga参与者，在Saga流程里面每一个本地事务只操作本地数据库，然后通过消息或事件来触发下一个本地事务，如果其中一个本地事务失败了，Saga就会执行一系列补偿事务来实现回滚操作。（补偿事务简单来讲就是对之前本地事务做的修改导致不一致的情况执行反向操作来消除掉不一致的状态）。
今年从原来的Team里面被抽出来加入了新的Team，开始做Java微服务的开发工作，接触了Spring Boot, Spring Cloud等技术栈，对微服务这种架构有了一个感性的认识。虽然只做了两个月的开发工作，但是对微服务架构的兴趣却没有结束，又因为自己的.NET背景（虽然对.NET的生态有点恨铁不成钢），想要探索一下在.NET平台下的微服务架构的可行性，也准备一些材料作为公司内部培训和分享课程的素材。幸运的是，在.NET Core首届在线峰会上，看到了很多前辈的分享，也增强了自己要摸索和实践.NET Core微服务架构的决心。因此，站在各位前辈的肩膀上（详见第四部分的学习资料），我学习并总结了这个系列的文章，主要面向有.NET Web开发背景（本系列不会主要讲解.NET Core，不过不会阻碍你的阅读），没有接触过或者很少接触微服务架构的初级开发童鞋，文中介绍的开源技术也不一定是最佳的选择，事实上混合式架构（Linux+Windows+开源组合）与Docker+K8S的组合已经成了现在主流企业级和互联网项目的默认标准，重点是大家转变这个思路，拥抱Open Source，拥抱Cloud，也拥抱.NET Core，才会让.NET的生态好起来。鲁迅先生说，“世上本无路，走的人多了也就成了路”，对于.NET生态也一样，只有我们拥抱的人（这里主要指使用.NET相关开源技术的人）多了，也才会有好的生态，特与君共勉。当然，这里并不是说要抱死.NET，或者鼓吹.NET多么好，没有绝对好的技术栈，只有刚刚好的业务需求，爱.NET Core，也不排斥Java等其他技术栈，相互合作，共同构建，脱离微软（这里指广义上的老一代微软全家桶：ASP.NET+MSSQL+WindowsServer等），拥抱开源，任重而道远！
在上一篇中，我们了解了MassTransit这个开源组件的基本用法，这一篇我们结合一个小案例来了解在ASP.NET Core中如何借助MassTransit+Quartz.Net来实现数据的最终一致性。当然，实现数据的最终一致性有很多方案，这里只是举一种我所学到的比较简单易于学习的实现方式而已。
前面介绍了 RabbitMQ 流控、镜像队列、网络分区、多机集群部署、高可用集群部署、集群运维管理、Java 调用的三种方式等相关的知识点，今天我将详细的为大家介绍 RabbitMQ 监控相关知识，希望大家能够从中收获多多！如有帮助，请点在看、转发支持一波！！！
下面的文字来自CAP的Wiki文档：https://github.com/dotnetcore/CAP/wiki
本文针对的主要是RabbitMQ服务管理，可以当做一个命令手册进行查阅。在本文章开始之间，我们先通过Docker来简单启动一个RabbitMQ服务实例。
队列(queue)：存在RabbitMQ中的邮筒，虽然消息是在应用程序和RabbitMQ中进行传递，但队列才是唯一能够存储消息的地方。队列的大小取决于宿主机器的内存和磁盘容量，它本质上是一个巨大的消息缓存池。多个生产者可以发送消息给同一个队列，多个消费者也可以从同一个队列中读取消息。这个队列有一个特点，先进先出。
如果rabbitmq.conf和rabbitmq-env.conf 的两个文件不存在，那么我们可以创建该文件，然后我们可以通过环境变量 指定该文件的位置。
延迟信息处理，比如10分钟之后给下单未付款的用户发送邮件提醒。解耦系统，对于新增的功能可以单独写模块扩展，比如用户确认评价之后，新增了给用户返积分的功能，这个时候不用在业务代码里添加新增积分的功能，只需要把新增积分的接口订阅确认评价的消息队列即可，后面再添加任何功能只需要订阅对应的消息队列即可。
RabbitMQ 是一个消息代理。这主要的原理十分简单，就是通过接受和转发消息。你可以把它想象成邮局：当你将一个包裹送到邮局，你会相信邮递员先生最终会将邮件送到接件人手上。RabbitMQ就好比一个邮箱，邮局或邮递员。
本系列教程主要针对使用java语言进行Rabbitmq的相关编程。阅读前请确认已经安装过rabbit服务。关于如何安装rabbitmq，请参考如何使用rabbitmq.
这是我上周去面试的，技术问题一共问了十多个问题，项目介绍以及一些软技能的，这类就不提了。
上一篇总结了可能出现的异常场景，并对RabbitMQ提供的可用性保证进行了分析，在出现服务器宕机后，仍然可以正常服务。另外，需要尽快恢复异常的服务器，重新加入集群，推送未消费的消息，通过监控可第一时间接收到错误并进行处理。
ApacheKafka是最流行的事件流处理系统。在这个领域中有很多同类的系统可以拿来比较。但是最关键的一点就是性能。Kafka以速度著称，但是，它现在能有多快，以及与其他系统相比又如何呢？我们决定在最新的云硬件上测试kafka的性能。 为了进行比较，我们选择了传统的消息broker RabbitMQ和基于Apache Bookeeper的消息broker Apache Pulsar。我们要关注以下几点，1.系统吞吐量。2.系统延迟。因为他们是生产中事件流系统的主要性能指标，特别是吞吐量测试测量每个系统在利用硬件（特别是磁盘和CPU）方面的效率。延迟测试测量每个系统交付实时消息的延迟程度，包括高达p99.9%的尾部延迟，这是实时和任务关键型应用程序以及微服务体系结构的关键需求。 我们发现Kafka提供了最好的吞吐量，同时提供了最低的端到端延迟，最高达到p99.9的百分比。在较低的吞吐量下，RabbitMQ以非常低的延迟交付消息。
消息队列：多个生产者可以向同一个消息队列发送消息，但是一个消息只能被一个消费者消费。
RabbitMQ是目前非常热门的一款消息中间件，不管是互联网大厂还是中小企业都在大量使用。作为一名合格的开发者，有必要对RabbitMQ有所了解。
一般而言，如果你选择RabbitMQ，那肯定就是把可靠性放在第一位。毕竟，RabbitMQ可是金融行业消息队列的标配。如果把性能放在第一位，那毫无疑问，必须是Kafka。但是，可靠性毕竟是相对的，就拿大火的阿里云，AWS云，或者传统的IBM小型机，Oracle数据库，没有谁敢说自己可靠性100%，都是说几个9。所以，本文的目的很明确，就是尽可能的提高我们RabbitMQ的可靠性，从发送、存储、消费、集群、监控、告警等多个维度给出可行性方案，指导开发者以及运维人员获取更加可靠的消息投递，保障我们的业务系统安全、可靠、稳定的运行。
2020版中间件面试题总结（RabbitMQ+Kafka+ZooKeeper）
在上一课中，我们已经学习到了什么是消息队列，有哪些消息队列，以及我们会用到哪个消息队列。今天，就直接进入主题，学习第一种，最简单，但也是最常用，最好用的消息队列模式。
要分析这个问题，首先我们得估算下在队列消息堆积的情况下进行生产消费，RabbitMQ的内存占用情况。
rabbitmq是蓝鲸所依赖的消息队列服务，影响着多个服务，如作业平台、标准运维、监控平台、节点管理、日志平台等。因为rabbitmq服务异常而导致的故障往往比较隐蔽，这类故障往往无法在页面直接反馈出来。在生产环境中曾遇到过因为rabbitmq异常，导致作业任务以及标准运维任务执行卡住的情况，如果故障发生在夜间，会导致一些重要的定时任务无法按照预期执行，容易造成一些重大运维事故。所以通过监控掌握rabbitmq服务的运行情况，对于整个蓝鲸服务的正常运行至关重要。这里提供一个rabbitmq监控实践总结。
本文最初发布于 Confluent 官方博客，经授权由 InfoQ 中文站翻译并分享。
要做技术选型，那么必须对现今的各个消息中间件有个深入的理解才能做技术选型。否则别人问你，你为什么要用这个消息中间件，你说不出个所以然来，怎么做架构师呢？
被概括为“开源分布式消息代理”，用Erlang编写，有助于在复杂的路由方案中有效地传递消息，可以通过服务器上启用的插件进行扩展，高可用（队列可以在集群中的机器上进行镜像）
RabbitMQ实现延迟队列需要依赖插件rabbitmq-delayed-message-exchange。
首先确认一个点，持久化和非持久化的消息都会落地磁盘，区别在于持久化的消息一定会写入磁盘(并且如果可以在内存中也会有一份)，而非持久化的消息只有在内存吃紧的时候落地磁盘。两种类型消息的落盘都是在RabbitMQ的持久层中完成的。
来源: MoienTajik/AspNetCore-Developer-Roadmap.
可以看到，除了默认的交换机，SpringBoot已经帮我们创建好了延迟交换机order-delay-exchange，并且此时messages delayed为0，因为我们还未向交换机投递消息。
我目前的项目最后使用的是RabbitMQ，这里依然是结合网上大神们的优秀博客，对kafka和rabbitmq进行简单的比对。最后附上参考博客。
RabbitMQ转载原文【推荐】:https://www.jianshu.com/p/78847c203b76
前段时间总结完了「深入浅出MyBatis」系列，对MyBatis有了更全面和深入的了解，在掘金社区也收到了一些博友的喜欢，很高兴。另外，短暂的陪产假就要结束了，小宝也二周了，下周二就要投入工作了，希望自己尽快调整过来，加油努力。
是指应用程序对应用程序的一种高效可靠的消息传递的通信方法,通过提供消息传递和消息排序模型，他可以在分布式环境下扩展进程间的通信，典型的生产者和消费者的代表
RabbitMQ是开源的消息中间件，它是轻量级的，支持多种消息传递协议，可以部署在分布式和联合配置中，以满足高级别、高可用性需求。并且可在许多操作系统和云环境上运行，并为大多数流行语言提供了广泛的开发工具。（这里只介绍JAVA下的RabbitMQ的使用，感兴趣的可以查看官方文档：http://www.rabbitmq.com/getstarted.html）；
在第一篇教程中，我们编写了两个程序，用于从一个指定的队列发送和接收消息。在本文中，我们将创建一个工作队列，用于在多个工作线程间分发耗时的任务。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
