《kafka 核心技术与实战》课程学习笔记（一）

fangzhan666

已于 2023-06-21 17:08:11 修改

阅读量429

点赞数

分类专栏：消息队列文章标签： kafka 分布式中间件

于 2022-01-17 18:07:24 首次发布

本文链接：https://blog.csdn.net/fangzhan666/article/details/122496576

版权

消息队列专栏收录该内容

18 篇文章 1 订阅

订阅专栏

消息引擎系统 ABC

Apache Kafka 是一款开源的消息引擎系统。
消息引擎系统是一组规范，企业利用这组规范在不同系统之间传递语义准确的消息，实现松耦合的异步式数据传递。
- 系统 A 发送消息给消息引擎系统，系统 B 从消息引擎系统中读取 A 发送的消息。
- 消息引擎传输的对象是消息。
- 如何传输消息属于消息引擎设计机制的一部分。
既然消息引擎是用于在不同系统之间传输消息的，那么如何设计待传输消息的格式从来都是一等一的大事。一条消息需要做到信息表达业务语义而无歧义，同时它还要能最大限度地提供可重用性以及通用性。
- 一个比较容易想到的是使用已有的一些成熟解决方案，比如使用 CSV、XML 亦或是 JSON。
- Kafka 选择使用的是纯二进制的字节序列。
- 当然消息还是结构化的，只是在使用之前都要将其转换成二进制的字节序列。
消息设计出来之后还不够，消息引擎系统还要设定具体的传输协议，即用什么方法把消息传输出去。Kafka 同时支持两种消息引擎模型：
- 点对点模型：也叫消息队列模型。系统 A 发送的消息只能被系统 B 接收，其他任何系统都不能读取 A 发送的消息。
- 发布/订阅模型：它有一个主题（Topic）的概念，可以理解成逻辑语义相近的消息容器。
  - 该模型也有发送方和接收方，只不过提法不同。
  - 发送方也称为发布者（Publisher），接收方称为订阅者（Subscriber）。
  - 和点对点模型不同的是，这个模型可能存在多个发布者向相同的主题发送消息，而订阅者也可能存在多个，它们都能接收到相同主题的消息。
为什么系统 A 不能直接发送消息给系统B，中间还要隔一个消息引擎呢？
- 答案就是“削峰填谷”。
- 所谓的“削峰填谷”就是指缓冲上下游瞬时突发流量，使其更平滑。
- 特别是对于那种发送能力很强的上游系统，如果没有消息引擎的保护，“脆弱”的下游系统可能会直接被压垮导致全链路服务“雪崩”。
- 但是，一旦有了消息引擎，它能够有效地对抗上游的流量冲击，真正做到将上游的“峰”填满到“谷”中，避免了流量的震荡。
- 消息引擎系统的另一大好处在于发送方和接收方的松耦合，这也在一定程度上简化了应用的开发，减少了系统间不必要的交互。
当引入了 Kafka 之后。上游订单服务不再直接与下游子服务进行交互。
- 当新订单生成后它仅仅是向 Kafka Broker 发送一条订单消息即可。
- 类似地，下游的各个子服务订阅 Kafka 中的对应主题，并实时从该主题的各自分区（Partition）中获取到订单消息进行处理，从而实现了上游订单服务与下游订单处理服务的解耦。
- 这样当出现秒杀业务时，Kafka 能够将瞬时增加的订单流量全部以消息形式保存在对应的主题中，既不影响上游服务的 TPS，同时也给下游子服务留出了充足的时间去消费它们。
- 这就是 Kafka 这类消息引擎系统的最大意义所在。

mq 和 rpc 的区别往大了说属于数据流模式（dataflow mode）的问题。

常见的数据流有三种：1. 通过数据库；2. 通过服务调用（REST/RPC）; 3. 通过异步消息传递（消息引擎，如 Kafka）。
RPC 和 MQ 是有相似之处的，毕竟远程调用一个服务也可以看做是一个事件，但不同之处在于：1. MQ 有自己的 buffer，能够对抗过载（overloaded）和不可用场景；2. MQ 支持重试；3. 允许发布/订阅模式。4.RPC 是介于通过数据库和通过 MQ 之间的数据流模式。