学习《消息队列高手课》后总结梳理

学前

在学习之前，实际对消息队列的一个认识总结：

1.消息队列有什么作用？

削峰，异步处理，减轻并发压力，代码解耦等

2.主要的消息队列有哪些？

rabbitmq,kafka 各有什么优劣势，因为实际生产环境用的不多，所以体验也不深刻。

3.消息队列的主要架构？

有生产者，消费者，队列，交换机，代理等

代理broker与交换机exchange的区别主要是

4.生产者如何确保消费者一定能收到消息？

增加确认机制

5.队列，交换机以及消息队列的元数据，是如何存储，保证消息队列重启后不丢失的？

将数据进行持久化

6.队列里面的消息是如何存储的，最大一个队列能存储多少条？

队列里面具体的消息也是支持持久化的，rabbitmq一个队列大概能存储10W条数据

7.消息队列的队列里面的生产者生成数据，消费者消费数据，全部都有日志记录吗？

可以通过配置交换机或者队列的tracing来进行日志记录

8.消息队列的集群有哪几种？

在消息队列的消息很大的时候，才会有集群的需求，而且消息队列的集群，也并不是真正的数据全部同步到每一个节点，保证可用性，而只是消息路由分发来保障性能的提升。

9.消息队列的消息是否可以设置有效期？

给消息队列的消息设置有效期是必要的，否则不能被消费的消息，一直积压，可能造成内存不足。

10.消息队列里面的消息能否设置优先级？

在同一个消息队列中，通过priority可以设置此消息的一个优先级，优先级高的会被放在最前面保证优先被消费。

11.消息队列一般是用什么语音编写的？

C语音，执行快，rabbitmq是使用一个比较小众的erlang语言，rocketmq是使用java开发的，kafka是用java和scala开发的。

12.消息队列为什么会有配置一个所占服务器内存占比多大的时候，自动宕机？

主要是考虑到占比过大，默认0.4会影响到服务器上其他服务，所以先牺牲自己。而且不会去检测什么条件下自己再重启（坑）。

13.当前对消息队列的认识架构图

14.我想从这个课程里面学到什么？

如何排查问题，更底层的逻辑梳理，源码的深刻理解

学后

消息队列生态系统全景图：

学完之后新的理解：

1.应用场景？

主要是分布式应用的多进程之前的通信，用来解决通信问题。分布式系统的最基础的问题就是通信。

2.消息队列的基本概念中：主题topic，订阅subscribe，分区partition？

主题：消息队列中生产者，消费者，队列，交换机都要与一个主题相关联起来，这个作为一个链接，来链接这些主体。

订阅：消息队列的发布/订阅。订阅了才能消费。

分区：消息队列通过分区进行空间的隔离，每个分区之间不会相互影响。是kafka才有的概念，相当于是rocketmq中的队列。

3.关于为什么要使用消息队列？

我上面罗列了几项，主要是说明异步和解耦，实际更重要的也有流量削峰填谷，在物联网应用中应该是有很多场景可以使用，目前我们还没有用到，后续可以加上。

4.消息队列的引入也会带来一定的缺点？

主要是本来是同步处理的，变成异步处理，增加了系统的复杂度，加大了相应时间，消息到底有没有被消费也是需要逻辑来进行控制。

5.常见的消息队列的比较：rabbitmq,rocketmq,kafka?

 6.消息队列中“队列模式”和“发布订阅模式”有什么区别？

“队列模式”：有生产者，消费者，队列；“发布订阅模式”有发布者，订阅者，和主题。生产者对应发布者，消费者对应订阅者，队列就相当于主题，区别就在于，“队列模式”一个消息只能被一个消费者消费，“发布订阅模式”一个消息可以多个订阅了相同主题的订阅者消费。就是消息能被一次消费还是多次消费的问题。可以粗略理解，“队列模式”是“分布订阅模式”的一种。

rabbitmq采用的是“队列模型”，rocketmq和kafka都是采用的“发布订阅模型”

7.消息队列中的事务是指？

主要是指在生产者和消费者之间数据的一致性。rocketmq实现事务，是通过mq server去主动回查生产者，这个是否应该被投递到消费者。最开始是一个半消息推送状态，只有其他处理完了，要提交确认了，才需要mq server 投递到消费者消费。

8.消息队列关于消息的重复性策略是什么样的？

主要有三种：

最多一次 <=1 不会重复，有可能会丢失数据

最少一次 >=1 会重复，但一定有一次

只有一次 =1 不多也不少就一次

实际要保证只有一次，会有复杂的机制。我们一般通过 最少一次+每次消费确保幂等性来实现

9.如果消息队列中一个消息消费时报错了，会阻塞其他队列的消费吗？

理论上，这里会有一个重试机制，如果重试多次，还是消费失败，那这里会有一个“死信队列”，专门存储这种消费失败的消息，以免阻塞其他消息的正常消费。

10.解决消息积压的办法？

【复制粘贴】

a.临时扩容消费端，通过硬件增加消费速度

b.服务降级，关闭一些不重要的服务，在消息生产者端限流

c.通过日志分析造成积压的原因，三阶段，消息发送是否有问题，消息存储是否有问题，消息消费是否有问题。根据定位解决问题

==========================

没有银弹

“好的架构不是设计出来的，而是演进出来的”

“技术不一定能完美解决存在的问题，但确实可以解决我们实际应用问题”