这是我参与「第五届青训营 」伴学笔记创作活动的第 14 天
1.消息队列的应用场景有哪些？
异步处理，应用解耦，流量削锋和消息通讯
2.Kafka的哪些Feature让其可以支撑大吞吐写入的场景？
- Zero Copy(零拷贝)技术
- Page Cache(页缓存)+磁盘顺序写
- 分区分段+索引
- 批量读写
- 批量压缩
3.Kafka Consumer Rebalance的流程简述？
新的consumer加入到组的过程如下：
- consumer 首先会寻找负责该 consumer grouo 是由哪个节点的 Coordinator 负责
- 在获取到节点后，consumer 向 Coordinator 发送加入请求
- Coordinator 会为每个 consumer 分配 id 号，并从中选择出 leader 角色
- consumer 收到响应后，发现自己被选择为 leader 角色，会执行分区算法，将该topic的分区怎么分配给这个 group 的成员。然后将分配结果发送给Coordinator
- 如果是follower角色，那么向Coordinator发送请求获取该自己的分区分配结果。
4.BMQ相比较Kafka有哪些优势？
5.RocketMQ有哪些特有的Feature？
- 削峰填谷（主要解决瞬时写压力大于应用服务能力导致消息丢失、系统奔溃等问题）
- 系统解耦（解决不同重要程度、不同能力级别系统之间依赖导致一死全死）
- 提升性能（当存在一对多调用时，可以发一条消息给消息系统，让消息系统通知相关系统）
- 蓄流压测（线上有些链路不好压测，可以通过堆积一定量消息再放开来压测）
6.RocketMQ事务消息处理流程简述？
7.你认为MQ后面应该如何发展？（开放题）
事务消息
首先服务 A 发送一个半事务消息(也称 half 消息)至 MQ 中。为什么要先发送一个 half 消息呢？这是为了保证服务 A 和 MQ 之间的通信正常，如果无法正常通信，则服务 A 可以直接返回一个异常，也就不用处理后面的逻辑的了。
如果 half 消息发送成功，MQ 收到这个 half 消息后，会返回一个 success 响应给服务 A。
服务 A 接收到 MQ 返回的 success 响应后，开始处理本地的业务逻辑，并提交本地事务。
如果服务 A 本地事务提交成功，则会向 MQ 中发送 commit，表示将 half 消息提交，MQ 就会执行第 5 步操作；如果服务 A 本地事务提交失败，则直接回滚本地事务，并向 MQ 中发送 rollback，表示将之前的 half 消息进行回滚，MQ 接收到 rollback 消息后，就会将 half 消息删除。
如果 commit，则将 half 消息写入到磁盘。
如果 MQ 长时间没有接收到 commit 或者 rollback 消息，例如：服务 A 在处理本地业务时宕机了，或者发送的 commit、rollback 因为在弱网环境，数据丢失了。那么 MQ 就会在一定时间后尝试调用服务 A 提供的一个接口，通过这个接口来判断 half 消息的状态。所以服务 A 提供的接口，需要实现的业务逻辑是：通过数据库中对应数据的状态来判断，之前的 half 消息对应的业务是否执行成功。如果 MQ 从这个接口中得知 half 消息执行成功了，那么 MQ 就会将 half 消息持久化到本地磁盘，如果得知没有执行成功，那么就会将 half 消息删除。
服务 B 从 MQ 中消费到对应的消息。
服务 B 处理本地业务逻辑，然后提交本地事务。
