首页  思维导图  详情

消息队列综合知识

2020-12-18 18:48:23   0  举报





AI智能生成

消息队列面试知识导图

消息队列

面试

作者其他创作

大纲/内容

优点

应用解耦

流量削峰

日志处理

消息通信

应用问题

死信队列

延时消息

消息语义

at least once

exactly once

at most once

消息重复消费

消息的幂等性

事务消息

消息顺序

如何保证多条消息之间的业务顺序？

rabbitmq的解决方案

kafka的解决方案

rocketmq的解决方案

消息堆积

原因

1.消费者消费速度在一定时间内远远跟不上生产着的生产速度

2.消费者进程挂掉或者其他原因导致消费速度下降

解决方案

1.重启消费者进程，恢复消费速度

2.提高消费者进程数量加快消费

3.丢弃消息

4.持久化消息后尝试重新消费

5.降低生产者生产消息的速度，对非重要消息进行降级

消息持久化

为什么要进行消息持久化？

如何进行消息的持久化？

持久化之后的读写效率怎么衡量？

持久化策略有哪些

持久化存储

基于mysql的消息持久化

基于磁盘文件的持久化

持久化策略

同步写磁盘后返回消息发送成功

异步写磁盘后返回消息发送成功

使用零拷贝技术

消息丢失

消息溯源

死信队列DLQ(Deal Letter Queue)

背景

消息被拒绝

消息过期

队列达到最大长度

应用场景

实现延迟队列

实现重试队列

消息的ACK机制

消息队列产品

Kafka

优点

高可用性

高吞吐量、低延迟

可靠性

持久化

可扩展性

高可用性

核心问题

1.kafka如何保证消息顺序消费

生产者方面

比如说我们建了一个 topic，有三个 partition。生产者在写的时候，其实可以指定一个 key，比如说我们指定了某个订单 id 作为 key，那么这个订单相关的数据，一定会被分发到同一个 partition 中去，而且这个 partition 中的数据一定是有顺序的

消费者方面

消费者从 partition 中取出来数据的时候，也一定是有顺序的。

单线程情况下可以保证消息消费的顺序，但是吞吐量比较低

多线程情况下比如有主子订单的情况下，子订单可能会被先处理，这样就出现了消息消费乱序的问题了

解决方案

写 N 个内存 queue，具有相同 key 的数据都到同一个内存 queue；然后对于 N 个线程，每个线程分别消费一个内存 queue 即可，这样就能保证顺序性。

这里的可以实际上相对于生产者发送的这个key做了一个分组，对于客户端来说这N个queue就是中转了下kafka来的消息作为生产者，消费者内部重新起线程消费。简单来说就是一个多生产者多消费者模型

2.kafka如何保证消息不丢失

产生消息丢失的原因有哪些

消息生产客户端问题

使用同步模式的时候，有3种状态保证消息被安全生产，在配置为1（只保证写入leader成功）的话，如果刚好leader partition挂了，数据就会丢失。

使用异步模式的时候，当缓冲区满了，如果配置为0（还没有收到确认的情况下，缓冲池一满，就清空缓冲池里的消息），
数据就会被立即丢弃掉。

kafka集群问题

集群参数设置不合理

主browker挂了

消息消费端问题

如果在消息处理完成前就提交了offset，那么就有可能造成数据的丢失。由于Kafka consumer默认是自动提交位移的，所以在后台提交位移前一定要保证消息被正常处理了，因此不建议采用很重的处理逻辑，如果处理耗时很长，则建议把逻辑放到另一个线程中去做。为了避免数据丢失，现给出两点建议：
enable.auto.commit=false 关闭自动提交位移
在消息被完整处理之后再手动提交位移

网络问题

磁盘IO问题

生产者方面

选择合适的发送策略

消费者方面

消息处理完成之后提交offset

3.kafka如何选举leader

4.kafka如何分区

5.kafka如何解决数据堆积

产生消息堆积的原因

消费者方面

消费者组或者消费端出现再平衡情况