这是我参与「第五届青训营 」伴学笔记创作活动的第 8 天

消息队列

• 消息队列(MQ)，指保存消息的一个容器，本质是一个队列。但这个队列，需要支持高吞吐，高并发，并且高可用。

Kafka

• 应用场景:搜索服务，直播服务，订单服务，支付服务

• 如何使用kafka:

  • 创建集群
  • 新增topic
  • 编写生产者逻辑
  • 编写消费者逻辑

• 批量发送（batch），减少IO次数，加强发送能力

• 通过压缩，减少消息大小

• 整个 Kafka Core 中权重最大、使用频率最高的三个角色是 Broker、Producer 和 Consumer，这几个角色的使用和我们的业务开发也是息息相关，对这些角色的核心机制进行深入了解对后续的业务开发、故障排查是有很大帮助

  • Broker 端是 Kafka 整个内部处理流程最复杂的组件了，这当中的机制没有办法一个一个列举出来详细说，我这里选择了 Controller 和 Broker 管理机制，还有副本管理中的高水位机制来进行介绍

  之所以选择这几个机制进行解读，是因为他们对帮助理解集群故障转移过程中的行为、影响面有很大帮助，其他机制都是围绕着 这些核心的一些外围机制，是一些辅助角色

  • 目前生产端的消息发送是基于异步发送机制实现的，通过 RecordAccumulator 去做了解耦了消息生产和网络请求

RocketMQ

• 针对低延时场景

  • Broker启动的时候，会往每台NameServer（因为NameServer之间不通信，所以每台都得注册）注册自己的信息，这些信息包括自己的ip和端口号，自己这台Broker有哪些topic等信息。
  • Producer在启动之后会跟会NameServer建立连接，定期从NameServer中获取Broker的信息，当发送消息的时候，会根据消息需要发送到哪个topic去找对应的Broker地址，如果有的话，就向这台Broker发送请求；没有找到的话，就看根据是否允许自动创建topic来决定是否发送消息。

  • Broker在接收到Producer的消息之后，会将消息存起来，持久化，如果有从节点的话，也会主动同步给从节点，实现数据的备份

    Consumer启动之后也会跟会NameServer建立连接，定期从NameServer中获取Broker和对应topic的信息，然后根据自己需要订阅的topic信息找到对应的Broker的地址，然后跟Broker建立连接，获取消息，进行消费

  。