消息队列

原文地址：https://blog.csdn.net/anzhsoft/article/details/19563091 1 历史 RabbitMQ是一个由erlang开发的AMQP（Advanced Message Queue ）的开源实现。AMQP 的出现其实也是应了广大人民群众的需求，虽然在同步消息通讯的世界里有很多公开标准（如 COBAR的 IIOP ，或者是 SOAP 等），但是在异步消息处理中却不是这样，只有大企业有一些商业实现（如微软的 MSMQ ，IBM 的 Websphere MQ 等），因此，在 2006 年的 6 月，Cisco 、Redhat、iMatix 等联合制定了 AMQP 的公开标准。 RabbitMQ是由RabbitMQ Technologies Ltd开发并且提供商业支持的。该公司在2010年4月被SpringSource（VMWare的一个部门）收购。在2013年5月被并入Pivotal。其实VMWare，Pivotal和EMC本质上是一家的。不同的是VMWare是独立上市子公司，而Pivotal是整合了EMC的某些资源，现在并没有上市。 RabbitMQ的官网是http://www.rabbitmq.com 2 应用场景 言归正传。RabbitMQ，或者说AMQP解决了什么问题，或者说它的应用场景是什么？ 对于一个大型的软件系统来说

原创声明 本文作者：黄小斜 转载请务必在文章开头注明出处和作者。 什么是消息队列 “RabbitMQ？”“Kafka？”“RocketMQ？”...在日常学习与开发过程中，我们常常听到消息队列这个关键词，可能你是熟练使用消息队列的老手，又或者你是不懂消息队列的新手，不论你了不了解消息队列，本文都将带你搞懂消息队列的一些基本理论。如果你是老手，你可能从本文学到你之前不曾注意的一些关于消息队列的重要概念，如果你是新手，相信本文将是你打开消息队列大门的一板砖。 根据百度百科的说法，“消息队列”是在消息的传输过程中保存消息的容器。消息队列管理器在将消息从它的源中继到它的目标时充当中间人。队列的主要目的是提供路由并保证消息的传递；如果发送消息时接收者不可用，消息队列会保留消息，直到可以成功地传递它。` 为什么要使用消息队列 我觉得使用消息队列主要有两点好处： 1.通过异步处理提高系统性能（削峰、减少响应所需时间）; 2.降低系统耦合性。如果在面试的时候你被面试官问到这个问题的话，一般情况是你在你的简历上涉及到消息队列这方面的内容，这个时候推荐你结合你自己的项目来回答。 《大型网站技术架构》第四章和第七章均有提到消息队列对应用性能及扩展性的提升。 在我平时的日常工作中，用到消息队列的场景可不少，比如，我有一个定时任务需要在A应用每天7点开始调度，那么定时任务系统如何告诉这个A应用呢

1、消费端限流 2、消息的ACK与重回队列 3、TTL消息 4、死信队列 消费端限流 什么是消费端的限流？ 假设一个场景，首先，我们RabbitMQ服务器有上万条未处理的消息，我们随便打开一个消费者客户端，会出现下面情况： 巨量的消息瞬间全部推送过来，但是我们单个客户端无法同时处理这么多数据！ 消费端限流 RabbitMQ提供的解决方案 RabbitMQ提供了一种qos（服务质量保证）功能，即在非自动确认消息的前提下，如果一定数目的消息（通过基于Consumer或者Channel设置Qos的值）未被确认前，不进行消费新的消息 Void BasicQos(uint prefetchSize, ushort prefetchCount, bool global); prefetchSize：0 不限制消息大小 prefetchSize：会告诉RabbitMQ不要同时给一个消费者推送多于N个消息，即一旦有N个消息还没有ack，则该Consumer将block（阻塞）掉，直到有消息ack Global：true\false是否将上面设置应用于Channel；简单来说，就是上面限制是Channel级别的还是Consumer级别 注意： prefetchSize和global这两项，RabbitMQ没有实现，暂且不研究； prefetch_count在no_ask=false的情况下生效

1、为什么要使用消息队列? 　　(1)解耦 　　传统模式的缺点：系统间耦合性太强，如上图所示，系统A在代码中直接调用系统B和系统C的代码，如果将来D系统接入，系统A还需要修改代码，过于麻烦！ 　　中间件模式：将消息写入消息队列，需要消息的系统自己从消息队列中订阅，从而系统A不需要做任何修改。 　　(2)异步 　　传统模式缺点：一些非必要的业务逻辑以同步的方式运行，太耗时间。 　　中间件模式：将消息写入消息队列，非必要的业务逻辑以异步的方式运行，以加快响应速度 　　(3)削峰 　　传统模式缺点：并发量大的时候，所有的请求直接怼到数据库，造成数据库连接异常 　　中间件模式：系统A慢慢的按照数据库能处理的并发量，从消息队列中慢慢拉取消息。在生产中，这个短暂的高峰期积压是允许的。 2、使用了消息队列会有什么缺点？ 　　分析：一个使用了MQ的项目，如果连这个问题都没有考虑过，就把MQ引进去了，那就给自己的项目带来了风险。我们引入一个技术，要对这个技术的弊端有充分的认识，才能做好防御。 　　系统的可用性降低：如果消息队列挂了，那么系统也会受到影响 　　系统的复杂性增加：要多考虑很多方面的问题，比如一致性问题、如何保证消息不被重复消费，如何保证消息可靠传输。因此，需要考虑的东更多，系统的复杂性增大。 　　 　　 来源： https://www.cnblogs.com/jiehanshi/p

声明 本文转自https://developer.51cto.com/art/201906/597963.htm 什么是RPC RPC（Remote Procedure Call）：远程过程调用，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的思想。 RPC 是一种技术思想而非一种规范或协议，常见 RPC 技术和框架有： 应用级的服务框架：阿里的 Dubbo/Dubbox、Google gRPC、Spring Boot/Spring Cloud。 远程通信协议：RMI、Socket、SOAP(HTTP XML)、REST(HTTP JSON)。 通信框架：MINA 和 Netty。 目前流行的开源 RPC 框架还是比较多的，有阿里巴巴的 Dubbo、Facebook 的 Thrift、Google 的 gRPC、Twitter 的 Finagle 等。 常用的RPC框架 gRPC：是 Google 公布的开源软件，基于最新的 HTTP 2.0 协议，并支持常见的众多编程语言。RPC 框架是基于 HTTP 协议实现的，底层使用到了 Netty 框架的支持。 Thrift：是 Facebook 的开源 RPC 框架，主要是一个跨语言的服务开发框架。 用户只要在其之上进行二次开发就行，应用对于底层的 RPC 通讯等都是透明的

🙂🙂🙂关注 微信公众号：【芋艿的后端小屋】 有福利： RocketMQ / MyCAT / Sharding-JDBC 所有 源码分析文章列表 RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址 您对于源码的疑问每条留言 都 将得到 认真 回复。 甚至不知道如何读源码也可以请教噢 。 新的 源码解析文章 实时 收到通知。 每周更新一篇左右 。 认真的 源码交流微信群。 1、概述 2、Producer 发送消息 DefaultMQProducer#send(Message) DefaultMQProducerImpl#sendDefaultImpl() DefaultMQProducerImpl#tryToFindTopicPublishInfo() MQFaultStrategy MQFaultStrategy LatencyFaultTolerance LatencyFaultToleranceImpl FaultItem DefaultMQProducerImpl#sendKernelImpl() 3、Broker 接收消息 SendMessageProcessor#sendMessage AbstractSendMessageProcessor#msgCheck DefaultMessageStore#putMessage 4

在php开发中使用rabbitmq消息队列时，需要安装PHP扩展amqp，安装步骤如下： 直接使用pecl进行amqp扩展的安装， /usr/local/php/bin/pecl install amqp 如果缺少librabbitmq库文件，需要先安装librabbitmq，步骤如下： 1 wget https://github.com/alanxz/rabbitmq-c/releases/download/v0.7.1/rabbitmq-c-0.7.1.tar.gz 2 tar -zxvf rabbitmq-c-0.7.1.tar.gz 3 cd rabbitmq-c-0.7.1 4 ./configure --prefix=/usr/local/rabbitmq-c 5 make && make install librabbitmq安装完成后，继续执行 /usr/local/php/bin/pecl install amqp 此时需要输入安装librabbitmq的安装目录/usr/local/rabbitmq-c，此时得到amqp.so扩展模块路径/usr/local/php/lib/php/extensions/no-debug-non-zts-20160303/amqp.so，加入php.ini配置文件， [amqp] extension=/usr/local/php

原文：https://www.cnblogs.com/yanbigfeg/p/9674238.html#_label3 目录 Queue 命名空间 示例代码 效果展示 MSMQ 开启安装 命名空间 示例代码 效果展示 本机查看消息队列 补充感谢 ConcurrentQueue 首先我们知道队列是先进先出的机制，所以在处理并发是个不错的选择。然后就写两个队列的简单应用。 回到顶部 Queue 命名空间 命名空间：System.Collections，不在这里做过多的理论解释，这个东西非常的好理解。 可以看下官方文档：https://docs.microsoft.com/zh-cn/dotnet/api/system.collections.queue?view=netframework-4.7.2 示例代码 我这里就是为了方便记忆做了一个基本的例子，首先创建了QueueTest类： 包含了获取队列的数量，入队和出队的实现 1 public class QueueTest 2 { 3 public static Queue<string> q = new Queue<string>(); 4 5 #region 获取队列数量 6 public int GetCount() 7 { 8 9 return q.Count; 10 } 11 #endregion 12 13 #region

1.引入pom.xml <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-amqp</artifactId> </dependency> 2.application.yml配置 spring: rabbitmq: host: 127.0.0.1 port: 5672 username: admin password: admin publisher-confirms: true publisher-returns: true template: mandatory: true listener: concurrency: 2 #最小消息监听线程数 max-concurrency: 2 #最大消息监听线程数 3.创建MQ配置文件 import lombok.extern.slf4j.Slf4j; import org.springframework.amqp.core.Binding; import org.springframework.amqp.core.BindingBuilder; import org.springframework.amqp.core.DirectExchange; import org.springframework.amqp

Kafka 官方对于自身的 LAG 监控并没有太好的方法，虽然Kafka broker 自带有 kafka-topic.sh, kafka-consumer-groups.sh, kafka-console-consumer.sh 等脚本，但是对于大规模的生产集群上，使用脚本采集是非常不可靠的。 Burrow 简介 LinkedIn 公司的数据基础设施Streaming SRE团队正在积极开发Burrow，该软件由Go语言编写，在Apache许可证下发布，并托管在 GitHub Burrow 上。 它收集集群消费者群组的信息，并为每个群组计算出一个单独的状态，告诉我们群组是否运行正常，是否落后，速度是否变慢或者是否已经停止工作，以此来完成对消费者状态的监控。它不需要通过监控群组的进度来获得阈值，不过用户仍然可以从中获得消息的延时数量。 Burrow 的设计框架 Burrow自动监控所有消费者和他们消费的每个分区。它通过消费特殊的内部Kafka主题来消费者偏移量。然后，Burrow将消费者信息作为与任何单个消费者分开的集中式服务提供。消费者状态通过评估滑动窗口中的消费者行为来确定。 这些信息被分解成每个分区的状态，然后转化为Consumer的单一状态。消费状态可以是OK，或处于WARNING状态（Consumer正在工作但消息消费落后），或处于ERROR状态