1. 消息队列的两种方式（点对点和发布订阅模式）
1.1. 点对点模式
点对点模式：消息生产者发送消息到队列，消费者从队列中取出消息。每个消息只能被一个消费者处理，确保消息不会被重复消费。这适用于需要任务队列或订单处理等场景。例如，多个消费者可以同时监听同一队列，但每条消息只会被一个消费者获取。
- 单消费者消费（1:1）
- 每条消息只能被一个消费者处理
- 典型应用：订单处理系统、银行交易队列
1.2. 发布订阅模式：多订阅者广播（1:N）
发布订阅模式：消息被发布到一个主题（Topic），所有订阅该主题的消费者都会收到消息的副本。这样，一条消息可以被多个消费者处理，适用于事件广播、实时通知等场景。例如，用户注册成功后，需要同时发送邮件和短信，就可以用发布/订阅模式。
注意点：订阅者必须提前订阅
1.3. 两者区别：
1.3.1. 消息接收方数量
- 点对点模式：单消费者消费（1:1）
-
- 每条消息只能被一个消费者处理
- 典型应用：订单处理系统、银行交易队列
- 发布订阅模式：多订阅者广播（1:N）
-
- 消息会推送给所有有效订阅者
- 典型应用：新闻推送、实时股票报价
1.3.2. 消息生命周期
点对点：消息被消费后立即删除
flowchart LR
Producer-->|消息A|Queue
Consumer1-.->|获取消息A|Queue
Queue-->|删除消息A|Consumer1
发布订阅：消息持久化至所有订阅者消费
flowchart LR
Producer-->|消息B|Topic
Topic-->|推送消息B|Subscriber1
Topic-->|推送消息B|Subscriber2
Topic-->|消息B保留|存储
1.3.3. 消费者关系
点对点：消费者竞争关系（负载均衡）
消费者集群共同处理同一队列
发布订阅：消费者独立关系（并行处理）
订阅者之间无感知，各自独立消费
1.3.4. 场景选择建议
选择点对点：当需要确保任务不重复执行（如支付扣款）
选择发布订阅：当需要事件多端同步（如库存变更通知）
2. kafka重要组件
- Broker：处理消息存储和传输的服务器实例。
- Topic，消费者组和Partition：消息分类和分区机制。
- Producer和Consumer：生产者和消费者的客户端。
- ZooKeeper（或新的KRaft协议）：集群协调服务。
- Replica和ISR：数据复制和同步机制。
- Controller：管理集群元数据和协调。
- Offset：消费者进度跟踪。
获取上面解释的还很笼统，举个一个栗子吧：
kafka可以理解是一个专门管理订单的大集团，
Broker可以理解为是不同城市的公司，例如上海有一个Broker，纽约有一个Broker
Topic可以理解为不同分类，例如服装订单是一个Topic，食物订单是一个Topic，根据业务需求可以有多个topic，每个Topic互不影响，消费者组可以理解为一个需要浏览订单的团队，Partition可以理解为【专属前台】专门接待消费者组的成员，例如封装订单属于属于服装Topic，会有生产厂商需要去看，快递公司需要去看，政府收税需要去看，这三个团队每一个都是一个消费者组，彼此互不干涉，各看各的，每一个消费者组派来一个消费者来的时候都会有一个自己的专属前台进行接待，当然一个消费者可以有一个也可以有多个，所以当一个消费者组里有三个消费者那么至少要有三个partition使得每个消费者都有属于自己的partition，为了公平，如果增加partition的话最好是三的倍数，此外一个partition可以服务于其他消费者组的消费者。
生产者可以理解是用户产生了订单，所以只要发订单就是生产者，当然发送订单一定要指定partition，消费者则是具体处理的人，例如处理服装订单的生产厂商可能有多个厂，谁处理完谁就可以领新的订单，但是如果一个生产厂商领了订单那么另一个生产厂商就领不了这个订单啦，只能领下一个订单啦
ZooKeeper可以理解为是公司总部，负责记录有多少类订单（topic）多少个专属前台（partition），还要时刻知道哪个城市的公司瘫痪啦，以及选出哪个公司作为总经理
Replica和ISR分布可以理解备份和记录哪个broker还正常运行，Replica分为Leader和Follower，即主副本，例如服装类订单选择上海作为Leader即主副本，纽约和伦敦作为Follower即从副本，食物订单则选纽约作为Leader，上海和伦敦作为Follower，伦敦可能是其他订单作为Leader，Leader则负责接收Producer发来的订单，给Consumer消费订单，这个信息也会被Leader同步到对应的Follower，这样的目的是防止上海的Leader突然瘫痪，可以立即选择伦敦或者纽约作为Leader继续对接Producer和Consumer，而ISR则是记录哪个城市的Broker还正常运行，例如伦敦之前已经瘫痪啦，上海又处理了一部分订单，然后伦敦逐渐恢复正常但是上海又瘫痪啦，此时伦敦的订单可能并不全，信息有问题，所以此时会选还在ISR的Broker作为Leader，因此说Replica和ISR主要是数据复制和同步机制
Controller可以理解为总经理，负责协调各个broker的工作
Offset则是记录不同消费者组此时消费到哪里啦，例如上一个消费者消费了第5个订单，那么同一个消费者组的消费者再来则会消费第六个订单