工作快4年了，有时很迷茫，有时很有干劲，学习了一些技术，也忘记了一些技术，即使对一些技术，了解的深度不够，至少自己学习过使用过，那么在面对问题时，不会显得那么无力，解决问题后，也能有更大的收获。
消息队列（Messeage Queue，MQ）是在分布式系统架构中常用的一种中间件技术，从字面表述看，是一个存储消息的队列，所以它一般用于给 MQ 中间的两个组件提供通信服务。
服务APIs使用版本语法来命名APIs的版本。版本语法包含三个部分：MAJOR.MINOR.PATCH。
微服务之间的通信方式对微服务架构内的各种软件质量因素有重大影响（有关微服务网络内通信的关键作用的更多信息）。沟通方式会影响软件的性能和效率等功能性需求，以及可变性、可扩展性和可维护性等非功能性需求。因此，有必要考虑不同方法的所有优缺点，以便在具体用例中合理选择正确的沟通方式。 本文比较了以下样式：REST、gRPC 和使用消息代理 (RabbitMQ) 的异步通信，在微服务网络中了解它们对软件的性能影响。沟通方式的一些最重要的属性（反过来会影响整体表现）是：
个人理解:我把它分成两个词消息和队列。当一大批客户端同时产生大量的网络请求（消息）时候，服务器的承受能力肯定是有一个限制的。这时候要是有个容器，先让这些消息排队就好了，还好有个叫队列的数据结构，通过有队列属性的容器排队(先进先出)，把消息再传到我们的服务器，压力减小了好多，这个很棒的容器就是消息队列
在web开发中有一种情况，我们或许希望在发送http请求的同时，后台服务订阅了该http请求，并对消息作出相应的处理，该怎么做呢？我们之前学过broker模式，这种模式可以在两个后台服务进行消息的发布和订阅，其实我们仍然可以利用这一点。
在云原生环境中，异步架构对于解耦服务、增强可伸缩性和增强系统可靠性至关重要。消息队列构成了异步架构的基础，您可以从诸多选项中选择一个，从开源工具如Kafka和RabbitMQ到托管系统如Google Cloud Pub/Sub和AWS SQS不等。然而，测试排队的异步工作流呈现出独特的挑战。本文探讨了使用OpenTelemetry测试这些工作流的实用方法，重点关注成本效益、资源优化和运维简单性。
rabbitMQ是市面上应用很广的一种应用间传送数据的通信方式，是由erlang语言开发，主要特点就是异步通信，实现服务与服务之间的解耦。
RabbitMQ是一种比较流行的消息中间件，之前我一直使用redis作为消息中间件，但是生产环境比较推荐RabbitMQ来替代Redis，所以我去查询了一些RabbitMQ的资料。相比于Redis，RabbitMQ优点很多，比如：
通过前2篇的介绍，了解了消息通信的主要元素和交互过程，以及如何运行和管理RabbitMQ，这篇将站在开发模式的角度理解「面向消息通信」带来的好处，以及在各种场景下的最佳实践。
本文介绍在 Redis、Apache Kafka、RabbitMQ、ZeroMQ 和 IBM MQ 等技术中使用的消息交换架构和路由方法的基本模式。另外介绍如何使用这些模式简化架构师和开发人员之间的互动。
消息生产者如果向交换机发送了一个无法被路由到任何队列上的消息,那么此时交换机会判断消息的mandatory属性值:
笔者最近研究了下rabbitmq，便很好奇它是怎么保证不丢失消息的呢？于是便整理了这篇文章来跟大家分享下，自己的理解，如有不准确的地方或者不同的意见，还请各位能够给出反馈，我们可以讨论，相互学习，相互成长。
在我们使用RabbitMQ过程中, 无法感知消息是否正确的到达broker. 如果不进行配置的话, 默认情况是不会返回任何信息给生产者的. 因此RabbitMQ提供了三种方法来进行消息的确认:
1.引言 RabbitMQ——Rabbit Message Queue的简写，但不能仅仅理解其为消息队列，消息代理更合适。RabbitMQ 是一个由 Erlang 语言开发的AMQP（高级消息队列协议）的开源实现，其内部结构如下： RabbitMQ作为一个消息代理，主要和消息打交道，负责接收并转发消息。RabbitMQ提供了可靠的消息机制、跟踪机制和灵活的消息路由，支持消息集群和分布式部署。适用于排队算法、秒杀活动、消息分发、异步处理、数据同步、处理耗时任务、CQRS等应用场景。 下面我们就来学习下
从安装环境，配置入门，到HelloWorld实操，各种类型消息传递的演示代码，原理介绍，答疑解惑，面试题，全面介绍RabbitMQ消息队列。 RabbitMQ集群搭建另外一篇文章介绍。
在微服务架构中，会将一个完整的应用程序拆分成一组服务。这些服务之间需要经过协作，通过接口调用，才能组成一个完整的应用。
RPC（Remote Procedure Call）：远程过程调用，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的思想。
如上图，在不使用消息队列服务器的时候，用户的请求数据直接写入数据库，在高并发的情况下数据库压力剧增，使得响应速度变慢。但是在使用消息队列之后，用户的请求数据发送给消息队列之后立即 返回，再由消息队列的消费者进程从消息队列中获取数据，异步写入数据库。由于消息队列服务器处理速度快于数据库（消息队列也比数据库有更好的伸缩性），因此响应速度得到大幅改善。
在分布式系统中,我们广泛运用消息中间件进行系统间的数据交换,便于异步解耦。现在开源的消息中间件有很多,前段时间产品 RocketMQ (MetaQ的内核) 也顺利开源,得到大家的关注。
其实就是一个以队列作为消息通信的组件，本质上是一个消息转发器。可以对消息进行接收、存储和消费。当前业界比较流行的消息中间件有rabbitmq，rocketmq和Kafka。我用的比较多的是rabbitmq。
本文转自https://developer.51cto.com/art/201906/597963.htm
从概念上讲，一条消息是一个发送方与一个或多个接收方之间的一次信息交换。自从大型机问世以来，消息交换一直是计算机编程和架构设计的重要组成部分。
美国计算机科学家，LaTex的作者Leslie Lamport说：“分布式系统就是这样一个系统，系统中一个你甚至都不知道的计算机出了故障，却可能导致你自己的计算机不可用。”一语道破了开发分布式系统的玄机，那就是它的复杂与不可控。所以Martin Fowler强调：分布式调用的第一原则就是不要分布式。这句话看似颇具哲理，然而就企业应用系统而言，只要整个系统在不停地演化，并有多个子系统共同存在时，这条原则就会被迫打破。盖因为在当今的企业应用系统中，很难寻找到完全不需要分布式调用的场景。Martin Fowler
交通控制示例应用程序模拟高速公路交通控制系统。 其用途是检测超速车辆，并向违规司机发送罚款通知。 这些系统实际上存在于现实生活中，下面是它们的工作原理。 一组摄像头（每个车道上方各一个）被放置在高速公路的起点和终点（假设该路段为 10 公里），没有上匝道或下匝道。 当车辆在摄像头下方经过时，摄像头会拍摄车辆照片。 使用光学字符识别 (OCR) 软件，从照片中提取车辆的车牌号。 系统使用每个车辆的入口和出口时间戳来计算该车辆的平均速度。 如果平均速度高于高速公路的最大速度限制，系统会检索司机信息并自动发送罚款通知。
◆ RabbitMQ如何保证消息的可靠性# RabbitMQ消息丢失的三种情况 ◆生产者弄丢消息时的解决方法# 方法一：生产者在发送数据之前开启RabbitMQ的事务(采用该种方法由于事务机制，会导致吞吐量下降，太消耗性能。) 方法二：开启confirm模式(使用springboot时在application.yml配置文件中做如下配置，实现confirm回调接口，生产者发送消息时设置confirm回调) 小结：事务机制和 confirm机制最大的不同在于，事务机制是同步的，你提交一个事务之后会阻塞在那儿
目前对消息队列并不了解其原理，本篇文章主要是通过慕课网学习归纳的一些笔记，为后续学习打下基础。 众所周知在对网站设计的时候，会遇到给用户“群发短信”，“订单系统有大量的日志”，“秒杀设计”等，服务器没法处理这种瞬间迸发的压力，这种情况要保证系统正常有效的使用，就需要“消息队列”的帮助。本篇主要通过消息队列的思路进行学习。 主要了解如下知识： 1、队列是个什么东西，他能干什么？ 2、对列的应用场景有哪些？ 3、如何使用队列对业务进行解偶？ 4、如何使用Redis队列来消除高压力？ 5、专业的对列系统RabbitMQ如何使用？ 归纳如下主要内容 @消息队列的概念，原理和场景 @解耦案例：队列处理订单系统和配送系统 @流量削峰案例：Redis的List类型实现秒杀 @RabbitMQ：更专业的消息系统实现方案
目前，公司方面 RPC 调用如 Dubbo、Feign 已经能支持基于灰度的调用，但是 MQ 还没有支持灰度的能力，因此导致在测试和生产环境业务验证、消息隔离方面体验比较差，因此我们基于 RabbitMQ 和 Kafka 实现了消息灰度的能力。
RabbitMQ（六）——RPC模式 （原创内容，转载请注明来源，谢谢） 一、概述 RabbitMQ的RPC模式，支持生产者和消费者不在同一个系统中，即允许远程调用的情况。通常，消费者作为服务端，放置
大概意思是架构师没有选用 RPC 框架来做服务间调用，而选择用 MQ 来代替。是不是很意外？
1.生产者(Publisher): 发布消息到RabbitMQ中的交换机(Exchange)上
RabbitMQ是一个开源的免费的消息队列系统，一端往消息队列中不断写入消息，而另一端则可以读取或者订阅队列中的消息。它是用Erlang编写的，并实现了高级消息队列协议（AMQP）。
大家好，我是小❤，一个漂泊江湖多年的 985 非科班程序员，曾混迹于国企、互联网大厂和创业公司的后台开发攻城狮。
“RabbitMQ？”“Kafka？”“RocketMQ？”...在日常学习与开发过程中，我们常常听到消息队列这个关键词，可能你是熟练使用消息队列的老手，又或者你是不懂消息队列的新手，不论你了不了解消息队列，本文都将带你搞懂消息队列的一些基本理论。如果你是老手，你可能从本文学到你之前不曾注意的一些关于消息队列的重要概念，如果你是新手，相信本文将是你打开消息队列大门的一板砖。
摘要 RabbitMQ是最为流行的消息中间件，是处理高并发业务的利器。本系列教程，将跟大家一起学习RabbitMQ。 目录 RabbitMQ是什么？ RabbitMQ的特点是什么？ 一、RabbitMQ是什么？ RabbitMQ是基于Erlang开发的目前最流行的开源消息中间件，类似于MSMQ、ActiveMQ等消息队列组件。RabbitMQ是轻量级的，无论是在本地还是云端，都非常容易部署。它支持多种消息协议。RabbitMQ可以部署在分布式和联合配置中，以满足高规模，高可用性要求。RabbitMQ支持多种
分布式系统中,我们广泛运用消息中间件进行系统间的数据交换,便于异步解耦。现在开源的消息中间件有很多,前段时间我们自家的产品 RocketMQ (MetaQ的内核) 也顺利开源,得到大家的关注。
今天这篇，我们主要讲解微服务架构究竟应该怎么进行服务间通信，同步通信和异步通信各有哪些问题，又应该怎么解决这些问题。
MQ 是什么？队列是什么，MQ 我们可以理解为消息队列(message queue)，队列我们可以理解为管道。以管道的方式做消息传递。
如某个系统会往数据库写数据，但是数据库只能支撑每秒1000左右的并发写入，并发量再高就容易宕机。
转载自 https://blog.csdn.net/lyhkmm/article/details/78775369
消息中间件也可以称消息队列，是指用高效可靠的消息传递机制进行与平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息队列模型，可以在分布式环境下扩展进程的通信。
SDK 形式，利用 threadlocal 实现 trace。http, grpc, rabbitMQ, springcloud-gateway, 异步线程池这类常见场景。
用户每次抢单的时候，一旦排队，我们设置一个自增值，让该值的初始值为1，每次进入抢单的时候，对它进行递增，如果值>1，则表明已经排队,不允许重复排队,如果重复排队，则对外抛出异常，并抛出异常信息100表示已经正在排队。
gRPC 也是基于以下理念：定义一个*服务*，指定其能够被远程调用的方法（包含参数和返回类型）。在服务端实现这个接口，并运行一个 gRPC 服务器来处理客户端调用。在客户端拥有一个*存根*能够像服务端一样的方法。
关于RabbitMQ是什么以及它的概念，不了解的可以先查看一下下面推荐的几篇博客 https://blog.csdn.net/whoamiyang/article/details/54954780 https://www.cnblogs.com/frankyou/p/5283539.html https://blog.csdn.net/mx472756841/article/details/50815895 官网介绍：http://www.rabbitmq.com/getstarted.html 本文git
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
