RabbitMQ

思维导图、视频、代码携手揭秘RabbitMQ编程，干货多多，趣味多多！ 目录 思维导读 视频 代码 思维导读 视频 链接：https://pan.baidu.com/s/1w0Iz9TomGwBj2-2ZkAr1IQ 提取码：n152 代码 https://gitee.com/cakin24/RabbitMQDemo/tree/master/src/main/java/com/rabbitmq 来源： oschina 链接： https://my.oschina.net/u/4347428/blog/4285895

1.为什么要保证顺序 消息队列中的若干消息如果是对同一个数据进行操作，这些操作具有前后的关系，必须要按前后的顺序执行，否则就会造成数据异常。举例： 比如通过mysql binlog进行两个数据库的数据同步，由于对数据库的数据操作是具有顺序性的，如果操作顺序搞反，就会造成不可估量的错误。比如数据库对一条数据依次进行了 插入->更新->删除操作，这个顺序必须是这样，如果在同步过程中，消息的顺序变成了 删除->插入->更新，那么原本应该被删除的数据，就没有被删除，造成数据的不一致问题。 2.出现顺序错乱的场景 （1）rabbitmq ①一个queue，有多个consumer去消费，这样就会造成顺序的错误，consumer从MQ里面读取数据是有序的，但是每个consumer的执行时间是不固定的，无法保证先读到消息的consumer一定先完成操作，这样就会出现消息并没有按照顺序执行，造成数据顺序错误。 rabbitmq消息顺序错乱第一种情况示意图.png ②一个queue对应一个consumer，但是consumer里面进行了多线程消费，这样也会造成消息消费顺序错误。 abbitmq消息顺序错乱第二种情况示意图.png （2）kafka ①kafka一个topic，一个partition，一个consumer，但是consumer内部进行多线程消费，这样数据也会出现顺序错乱问题。

RabbitMQ简介： RabbitMQ即一个消息队列，主要是用来实现应用程序的异步和解耦。同时RabbitMQ也能起到消息缓冲，消息分发的作用。RabbitMQ使用的是AMQP（Advanced Message Queue Protocol/高级消息队列协议/）协议，它是一种二进制协议。 RabbitMQ的工作原理： RabbitMQ有4个组件，生产者（发送消息者）、Exchange、Queue队列、消费者（消息接收者）。当生产者发出消息时，会先经过Exchange，有Exchange转发给队列，然后由消息接收者消费。 消息中间件：系统间通信的。 通常使用的有：一、HTTP。二、RPC （同步请求：也就是需要服务提供者提供一个服务，需要消费者回应之后服务提供者才能去做其他事情）。 三、消息队列 （异步请求，解耦、缓冲） 异步： 也就是和同步相反。 解耦： 就是提供者和消费者之间的关系不需要紧紧相连，通过中间的消息队列即可实现解耦。 缓冲： 就是加入服务提供者提供了很多消息给消费者，这个时候如果没有消息队列就容易直接将消费者压垮掉，但是有了消息队列之后，可以直接将大量的消息传入消息队列实现了一个缓冲的作用。 这个时候又出现了一个新的消息中间件——RabbitMQ，它的愿景是取代一切其他的消息中间件。 来源： oschina 链接： https://my.oschina.net/u

MQ（消息队列） 1、为什么使用MQ MQ可以 解耦 、 异步 、 削峰 。 解耦场景：使用Pub/Sub 发布订阅模型，可以一个系统发布消息，多个系统订阅消费。 异步场景：用户一个请求，后台需要调用多个服务完成，可以将每一个服务放入一个队列，分别异步执行。 削峰：一般Mysql 每次可处理2k左右请求，如果请求量突然暴增，DB将承受不住，甚至宕机，将请求放入队列，根据DB处理能力，排队消费。 引入MQ面对的问题： 系统可用性降低：MQ服务挂了，系统也就挂了 系统复杂度提高：如何保证消费不重复，消息不丢失，消息传递的顺序行，都需要解决 一致性问题出现：A系统处理成功，B系统没有处理成功，咋办 各消息队列对比： 特性 ActiveMQ RabbitMQ RocketMQ Kafka 单机吞吐量 万级，比 RocketMQ、Kafka 低一个数量级 同 ActiveMQ 10 万级，支撑高吞吐 10 万级，高吞吐，一般配合大数据类的系统来进行实时数据计算、日志采集等场景 topic 数量对吞吐量的影响 topic 可以达到几百/几千的级别，吞吐量会有较小幅度的下降，这是 RocketMQ 的一大优势，在同等机器下，可以支撑大量的 topic topic 从几十到几百个时候，吞吐量会大幅度下降，在同等机器下，Kafka 尽量保证 topic 数量不要过多，如果要支撑大规模的 topic

摘要：Kafka中的位移是个极其重要的概念，因为数据一致性、准确性是一个很重要的语义，我们都不希望消息重复消费或者丢失。而位移就是控制消费进度的大佬。本文就详细聊聊kafka消费位移的那些事，包括： 概念剖析 kafka的两种位移 关于位移（Offset），其实在kafka的世界里有两种位移： 分区位移：生产者向分区写入消息，每条消息在分区中的位置信息由一个叫offset的数据来表征。假设一个生产者向一个空分区写入了 10 条消息，那么这 10 条消息的位移依次是 0、1、…、9； 消费位移：消费者需要记录消费进度，即消费到了哪个分区的哪个位置上，这是消费者位移（Consumer Offset）。 注意，这和上面所说的消息在分区上的位移完全不是一个概念。上面的“位移”表征的是分区内的消息位置，它是不变的，即一旦消息被成功写入到一个分区上，它的位移值就是固定的了。而消费者位移则不同，它可能是随时变化的，毕竟它是消费者消费进度的指示器。 消费位移 消费位移，记录的是 Consumer 要消费的下一条消息的位移， 切记，是下一条消息的位移！ 而不是目前最新消费消息的位移 假设一个分区中有 10 条消息，位移分别是 0 到 9。某个 Consumer 应用已消费了 5 条消息，这就说明该 Consumer 消费了位移为 0 到 4 的 5 条消息，此时 Consumer 的位移是 5

消息队列 为什么写这篇文章? 博主有两位朋友分别是小A和小B: 小A，工作于传统软件行业(某社保局的软件外包公司)，每天工作内容就是和产品聊聊需求，改改业务逻辑。再不然就是和运营聊聊天，写几个SQL，生成下报表。又或者接到客服的通知，某某功能故障了，改改数据，然后下班部署上线。每天过的都是这种生活，技术零成长。 小B，工作于某国企，虽然能接触到一些中间件技术。然而，他只会订阅/发布消息。通俗点说，就是调调API。对为什么使用这些中间件啊？如何保证高可用啊？没有充分的认识。 庆幸的是两位朋友都很有上进心，于是博主写这篇文章，帮助他们复习一下关于消息队列中间件这块的要点 复习要点 本文大概围绕如下几点进行阐述: 为什么使用 消息队列 ？ 使用消息队列有什么缺点? 消息队列 如何选型? 如何保证消息队列是高可用的？ 如何保证消息不被重复消费? 如何保证消费的可靠性传输? 如何保证消息的顺序性？ 我们围绕以上七点进行阐述。需要说明一下，本文不是《消息队列从入门到精通》这种课程，因此只是提供一个复习思路，而不是去教你们怎么调用消息队列的API。建议对消息队列不了解的人，去找点消息队列的博客看看，再看本文，收获更大 正文 1、为什么要使用 消息队列 ? 分析:一个用消息队列的人，不知道为啥用，这就有点尴尬。没有复习这点，很容易被问蒙，然后就开始胡扯了。 回答:这个问题

RabbitMQ是目前非常热门的一款消息中间件，不管是互联网大厂还是中小企业都在大量使用。作为一名合格的开发者，有必要对RabbitMQ有所了解，本文是RabbitMQ快速入门文章，主要内容包括RabbitMQ是什么、RabbitMQ核心概念、常用交换器类型、用Docker安装RabbitMQ等。 RabbitMQ简介 以熟悉的电商场景为例，如果商品服务和订单服务是两个不同的微服务，在下单的过程中订单服务需要调用商品服务进行扣库存操作。按照传统的方式，下单过程要等到调用完毕之后才能返回下单成功，如果网络产生波动等原因使得商品服务扣库存延迟或者失败，会带来较差的用户体验，如果在高并发的场景下，这样的处理显然是不合适的，那怎么进行优化呢？这就需要消息队列登场了。 消息队列提供一个异步通信机制，消息的发送者不必一直等待到消息被成功处理才返回，而是立即返回。消息中间件负责处理网络通信，如果网络连接不可用，消息被暂存于队列当中，当网络畅通的时候在将消息转发给相应的应用程序或者服务，当然前提是这些服务订阅了该队列。如果在商品服务和订单服务之间使用消息中间件，既可以提高并发量，又降低服务之间的耦合度。 RabbitMQ就是这样一款我们苦苦追寻的消息队列。RabbitMQ是一个开源的消息代理的队列服务器，用来通过普通协议在完全不同的应用之间共享数据。 RabbitMQ是使用Erlang语言来编写的

springboot 整合 RabbitMQ 消息队列作为分布式系统中重要的组件，可以有效解决应用耦合，异步消息，流量削锋等系列问题，有利于实现高性能，高可用，可伸缩和最终一致性架构。可应用在业务解耦，消息异步分发(提高应用响应速度)。本文主要讲述springboot部署rabbitmq的一些简单消息发送。 依赖包 < ! -- 消息队列 rabbitmq 依赖包 -- > < dependency > < groupId > org . springframework . boot < / groupId > < artifactId > spring - boot - starter - amqp < / artifactId > < / dependency > < ! -- 消息队列 rabbitmq 依赖包 end -- > 配置 写在application.properties文件 ## == == == == == == == rabbitmq配置 == == == == = 后台 http : / / ip地址 : 15672 / spring . rabbitmq . host = ip地址 spring . rabbitmq . port = 5672 spring . rabbitmq . username = root spring . rabbitmq .

问题： We'd be interested to hear any experiences with the pros and cons of ActiveMQ vs RabbitMQ vs ZeroMQ. 我们有兴趣听听ActiveMQ与RabbitMQ和ZeroMQ的优缺点。 Information about any other interesting message queues is also welcome. 还欢迎有关任何其他有趣的消息队列的信息。 解决方案： 参考一： https://stackoom.com/question/34E5/ActiveMQ或RabbitMQ或ZeroMQ或-关闭 参考二： https://oldbug.net/q/34E5/ActiveMQ-or-RabbitMQ-or-ZeroMQ-or-closed 来源： oschina 链接： https://my.oschina.net/u/4428122/blog/4355406

mq 提供了两种方式确认消息的可靠投递 confirmCallback 确认模式 returnCallback 未投递到 queue 退回模式 在使用 RabbitMQ 的时候，作为消息发送方希望杜绝任何消息丢失或者投递失败场景。RabbitMQ 为我们提供了两个选项用来控制消息的投递可靠性模式。 rabbitmq 整个消息投递的路径为： producer->rabbitmq broker cluster->exchange->queue->consumer message 从 producer 到 rabbitmq broker cluster 则会返回一个 confirmCallback 。 message 从 exchange->queue 投递失败则会返回一个 returnCallback 。我们将利用这两个 callback 控制消息的最终一致性和部分纠错能力。 对于消息异常，可以使用以下方法进行解决 使用RepublishMessageRecoverer这个MessageRecoverer会发送发送消息到指定队列 给队列绑定死信队列，因为默认的RepublishMessageRecoverer会发送nack并且requeue为false。这样抛出一场是这种方式和上面的结果一样都是转发到了另外一个队列。详见DeadLetterConsumer