消息队列综合知识
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如何保证消息顺序消费
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如何解决数据堆积
产生消息堆积的原因
消费者组或者消费端出现再平衡情况
1.消费组成员发生变更，有新消费者加入或者离开，或者有消费者崩溃；
2.消费组订阅的主题数量发生变更；
消费组订阅的分区数发生变更。
消费能力本身有限
比如单条消息的处理时间不稳定
突然的生产高峰，消费能力有限
消息重复推送
低版本kafka消息配置不合理
6.kafka如何解决重复消费问题
消息生产客户端
可以不用关注
消息消费端
保存消息id，建立去重表，自己去重
消费之前进行幂等逻辑判断
高性能/高吞吐的原因
1.顺序文件日志
零拷贝
高性能日志索引存储协议
2.日志冗余
3.topic多分区
4.服务端时间轮算法
系统部署架构
kafka的系统部署架构
主要角色&概念
消息生产者/producer
概念：消息生产者，就是向 kafka broker 发消息的客户端；
生产者发送模式
1.同步（synchronize）：调用send方法发送消息后会返回一个Future对象，可以通过Future对象知道消息是否发送成功（Kafka默认同步，即producer.type=sync）。
2.异步（asynchronize）：调用send方法并制定一个回调函数，服务器再响应时调用该函数。
3.发送后就不管了（OneWay）：消息发给服务器，不关心是否正常到达。
消息消费者/consumer
消费组
主题
主题：数据记录发布的地方，可以用来区分业务系统。Kafka中的Topic是多订阅者模式，一个topic可以拥有一个或多个消费者来订阅它。
对于每个topic，Kafka集群都会有一个或多个分区。分区的角色分为leader分区和follower分区，每个分区都是有序且顺序不便的数据集，并且不断的追加到结构化的log文件中。
分区
位移/偏移量
日志
副本
副本的特性
1.同一个分区下的所有副本保存有相同的消息序列
2.本质就是一个只能追加写消息的日志文件
3.副本分散保存在不同的 Broker 上，从而能够对抗部分 Broker 宕机带来的数据不可用（Kafka 是有若干主题概，每个主题可进一步划分成若干个分区。每个分区配置有若干个副本）
副本类型：
领导者副本
追随者副本
browker
browker的概念
Broker：一个独立的Kafka服务器被称为broker，它用于接收生产者的消息，并设置消息的偏移量，还会把消息保存到磁盘中。
kafka集群的概念
多个Kafka实例组成Kafka集群，每个实例都被称为broker。其中每个Kafka集群中都会有一个节点被选为领导节点，也叫做broker中央控制器。
browker master 节点
作用
1.管理整个集群的分区：当某个topic增加分区数量的时候，由中央控制器管理重新分配分区的工作。
2.监控副本的状态
支持的特性
消息过期时间
延迟队列
消息路由
消息轨迹
消息审计
消息代理
kafka消息投递和消费的过程？
1.
kafka采用拉取模型，由消费者自己记录消费状态，每个消费者互相独立地顺序拉取每个分区的消息。
RocketMQ
rocketmq概念和架构
组件概念
生产者Producer
消费者Consumer
名字服务Name Server
代理服务器Broker Server
消息内容Messaage
消息主题Topic
标签Tag
消息队列MessageQueue
存储概念
ConsumeQueue
CommitLog
IndexFile
ActivityMQ
MQTT
RabbitMQ
消息队列中的推模型和拉模型
1.推模型
由消息服务器根据一定规则将消息推送到指定消费者中
2.拉模型
由消费者根据订阅关系从消息服务器中拉取消息消费
收藏
收藏
0 条评论
回复 删除
下一页
