小薛博客

Appearance

一、入门说明 ​

1、是什么 ​

RabbitMQ是一个开源的消息代理和队列服务器，用来通过普通协议 在完全不同的应用之间共享数据，RabbitMQ是使用Erlang语言来编写 的，并且RabbitMQ是基于AMQP协议的

2、应用场景 ​

1、系统解耦 ​

有个系统A，这个系统A会产出一个核心数据，现在下游有系统B和系统C需要使用这个数据

image-20220426164252935

痛点

现在要是来了系统D、系统E、系统F、系统G等，多个系统都需要这份核心数据呢？

如何解决

将系统A自己的一份核心数据发送到MQ中间件中，下游各个系统按需自取即可。

image-20220426165951724

通过 MQ 消息中间件的使用，重构系统之间的耦合，让系统具备高度的可扩展性。

2、异步调用 ​

假设你有一个系统调用链路，是系统A调用系统B耗时20ms，系统B调用系统C耗时200ms，系统C调用系统D耗时2000ms

image-20220426170029809

痛点

卡脖子的系统D调用耗时2000ms，如何缩短调用耗时？

如何解决

系统A -> 系统B -> 系统C，仅仅耗费220ms后直接反馈成功

系统C就是发送个消息到MQ中间件里，由系统D去消费MQ中的消息，慢慢的异步来执行这个耗时2s的业务处理。

通过这种方式直接将核心链路的执行性能提升了10倍

总结

对用户来说比同步获取更加快捷，用户体验非常好，都是100%成功。（让用户以为自己抢到了，欺骗ing ）

对系统访问压力来说，异步因为没有真正执行，不会造成某时刻对系统的访问压力剧增，而是放入MQ队列，慢慢去消费！

3、流量削峰 ​

有一个系统，平时正常的时候每秒可能就几百个请求，系统部署在8核16G的机器的上，正常处理都是OK的，每秒几百请求是可以轻松抗住的

痛点

大促活动高峰

如何解决

搭机器

image-20220426173137302

加MQ

image-20220426173146590

面试题突袭

为什么引入MQ，你上面说的对，引入MQ后的优点(异步解耦削峰)，那请你谈谈引入MQ后的缺点

系统可用性降低，MQ一旦挂了，危险。。。。。

系统复杂度提高

数据一致性问题

本来好好的，A 系统调用 BC 系统接口，如果 BC 系统出错了，会抛出异常，返回给 A 系统让 A 系统知道，这样的话就可以做回滚操作了。

但是使用了 MQ 之后，A 系统发送完消息就完事了，默认为成功了。而刚好 C 系统写数据库的时候失败了，但是 A 认为 C 已经成功了。

这样一来数据就不一致了。

通过分析引入 MQ 的优缺点之后，就明白了使用 MQ 有很多优点，但是会发现它带来的缺点又会需要你做各种额外的系统设计来弥补。

最后你可能会发现整个系统复杂了好几倍

怎么保证 MQ 消息不丢失?100%投递成功

不要用redis做MQ，专业的人做专业的事

image-20220426173303339

3、下载 ​

https://www.rabbitmq.com/download.html

image-20220426173324417

MQ高级特性和复杂生产落地案例

  • 消息可靠性投递 如何保证消息不丢

image-20220426173350844

  • 消息确认消费
  • 消费端限流
  • TTL
  • 死信队列
  • 延迟队列
  • 日志与监控
  • 消息追踪
  • 消息补偿
  • 幂等性保证
  • MQ和分布式事务

4、和其它MQ产品的对比 ​

1、RabbitMQ模型 ​

image-20220426173452479

image-20220426173455885

2、Kafka模型 ​

image-20220426173507569

image-20220426173510350

1 Kafka与RabbitMQ比没有Exchange的概念，生产者直接发消息Topic（队列）。

2 Kafka的订阅者是通过消费组（Consumer Group）来体现的，每个消费组都可以重复消费Topic一份完整的消息，不同消费组之间消费进度彼此不受影响。例如Message1能被Consumer Group 1和Consumer Group2里的消费者都消费一次。

3 消费组中包含多个消费者，同个Group的消费者之间是竞争消费的关系。例如Message2只能够被Consumer Group里某一个Consumer只消费一次。

4 Kafka具有消息存储的功能，消息被消费后不会被立即删除，因为需要被不同的Consumer Group多次消费同个消息，因此会在Topic维护一个Consumer Offset，每消费成功Offset自增1.

对比图

image-20220426173601621

3、对比总结 ​

共同点

RabbitMQ与Kafka都有很好的客户端语言支持、安全机制与生态支持。

性能

Kafka的诞生的是处理高并发日志的，吞吐量比较高，每秒请求数达到数十万量级

RabbitMQ每秒请求数则为万级别，有测试报告指出Kafka是RabbitMQ的10倍以上性能。

运维便捷

RabbitMQ相对比较方便，可以使用yum或者docker安装，自带Web管理UI，没有额外的依赖，除了需要做镜像队列外需要引入HAproxy。

Kafka则需要依赖Zookeeper，也没有自带的管理工具，可以使用第三方的Kafka Eagle代替，Kafka Manager过于难用，另外Kafka没有yum安装，docker镜像也是社区人员自己建的。

有序性

RabbitMQ理论上是全局有序性的，但是由于【发后既忘】+【自动确认】机制的原因，如果在同个队列的多个消费者做相同的业务处理时，他们的各自的执行任务无法保证有序完成。如果确保100%有序可以使用【非自动确认】，但会影响消费性能。

Kafka支持分区有序性，如果对有序性有严格要求可以设置单个Partition，可是单个Partition并发性比较低，因此在多个Partition情况下可以根据业务指定key把相关的消息路由到同一个Partition，例如相同UserId行为信息可以到Partition 1进行处理。

时效性

Kafka基本上无论在客户端还是服务端都是以【异步批量】的机制进行处理，通俗的讲就是先攒起来一堆消息，到了某个阀值再发送，也会导致一些消息可靠性与消息有时效上的问题，当然可以通过各种配置策略进行解决。

消息回溯

Kafka在消费完了消息后不会立即删除，只会修改offset，如果之前部分业务消费失败了可以重新设置offset进行重新消费。

RabbitMQ则是[发后既忘]的机制，一但消费者确认消息则删除，但是可以通过死信进行补偿消费。

此外RabbitMQ在队列消息堆积多的情况下性能表现不佳，所以尽可能的及时消费消息。

特色功能

RabbitMQ具有死信的功能，可以通过死信形成重复消费与延时发送。-----java用的多

Kafka具有流处理功能，可以收集用户的行为日志进行存储与分析。 ------大数据用的多

5、安装 ​

官网 https://www.rabbitmq.com/download.html

重点

先安装erlang再安装rabbitmq

两者的匹配要符合官网配对要求

https://www.rabbitmq.com/which-erlang.html

docker安装步骤说明

https://hub.docker.com/_/rabbitmq

sh
docker pull rabbitmq:3.9.15-management
docker run -d --name=rabbitmq -p 15672:15672 -p 5672:5672 rabbitmq:3.9.15-management

RabbitMQ的控制台说明

http://localhost:15672/

image-20220509094713428

三大端口

image-20220509094859369

amqp——协议端口，5672

clustering——集群端口，25672

rabbitMQ management——rabbitmq的web页面管理端口，15672

Java程序访问端口5672，通过amqp协议与rabbit进行通信

6、新增加一个用户 ​

image-20220509095039593

7、新增一个Virtual Host ​

image-20220509095334621

image-20220509095448815

image-20220426174546634

为什么有时效果看不到

image-20220509095521101