1.什么是消息队列，有哪些应用场景
1.消息队列概念
2.应用场景
3.Kafka与RabbitMQ的区别
4.RabbitMQ的确认机制
RabbitMQ消息队列：
通过不同的 队列名称（queue） 和 Exchange 来区分不同的任务类型,并且给每个任务添加不同的消费者组进行处理。消费者处理完后给消息队列发送ack应答，表明处理完消息，可以继续接收。
使用qos保证负载均衡：避免单个消费者处理过多消息而其他消费者空闲的情况，通过设置预取消息数量，处理时间，流程类似于这样。
5.出现消息积压怎么处理
6.死信队列
7.RabbitMQ的交换器类型
2.Kafka有哪些模块
3.Kafka为什么快
4.Kafka是如何保证消息有效性的（不丢失的）
5.Kafka是如何保证消息的顺序性的
6.出现消息挤压的时候如何处理
1.应急策略
2.长期策略
7.Kafka的消费模式
Kafka 消费主要有两种模式：
点对点（Consumer Group）：同一个 group 内的消费者会均摊一个 topic 的分区数据，实现负载均衡。
广播（不同 Group）：不同的 group 可以独立消费同一个 topic，互不影响。
我们项目里用的是 Consumer Group 模式，通知服务需要高可用，所以会部署多个消费者实例，它们在同一个 group 内，通过分区保证消息不会被重复消费，提升并发能力。
8.ISR机制
1.什么是ISR机制
2.ISR机制怎么工作的
1. 副本加入 ISR
一个 Follower 副本想要进入 ISR，需要满足两个条件（由 Broker 端参数 replica.lag.time.max.ms 控制，默认 30 秒）：
时间差：Follower 副本最后一次向 Leader 拉取数据的时间，不能超过
replica.lag.time.max.ms。这表示 Follower 不能“掉队”太久。偏移量差（旧版本，现已主要使用时间判断）：Follower 副本与 Leader 副本之间的消息条数差不能超过一定阈值（由
replica.lag.max.messages控制，但因生产环境流量波动大，此参数已不推荐使用）。
简单来说，一个 Follower 只要在最近 30 秒内成功地从 Leader 那里获取了数据，它就被认为是“同步的”，就会待在 ISR 里。
2. 副本被踢出 ISR
如果某个 Follower 副本因为网络问题、宕机、GC 停顿或 I/O 缓慢等原因，导致在 replica.lag.time.max.ms 时间内都没有成功从 Leader 拉取数据，Leader 就会将它从 ISR 集合中移除。
此时，这个 Follower 就“失步”了，它不再被认为是可靠的备份。
3. 副本重新加入 ISR
那个被踢出的 Follower 并不会永久失效。当它恢复过来，重新开始从 Leader 拉取数据，并且最终追赶上了 Leader 的进度（即满足了重新加入 ISR 的条件），Leader 会将它重新加回 ISR 集合。
这个过程是动态和自动的。
4. ISR 与消息确认（Acks）
ISR 机制与生产者的请求确认模式 (acks) 紧密配合，让用户可以在性能和数据可靠性之间灵活选择：
acks=0：生产者不等待任何确认。速度最快，但可能丢数据。acks=1（默认）：生产者只需等待 Leader 将消息写入其本地日志即可。这是一个很好的平衡，但如果 Leader 写入后立即宕机且数据未同步到 ISR 中的任何 Follower，数据仍会丢失。acks=all（或acks=-1）：这是与 ISR 强相关的设置。生产者需要等待 Leader 将消息成功复制到 ISR 中的所有副本 后才收到确认。这是最安全的方式，可以保证只要 ISR 中至少有一个副本存活，数据就不会丢失。
8.kafka怎么解决脑裂问题
1.成为leader的评判标准
2.与Raft的"term"机制的本质区别
评论