Kafka 概述

你可以把系统想象成很多人要互相发消息：

订单系统
支付系统
日志系统
行为分析系统
.....

如果它们直接互相发消息：

A 崩了，B 就收不到消息
B 太忙处理不过来，消息直接丢了
耦合太高，改一个全要改

就像：所有人直接面对面喊话，吵死、乱死、还容易漏。

有了 Kafka 会怎样？

所有消息先丢给 Kafka，谁需要谁自己来取。
你可以这么记：

生产者（Producer）：发消息的人（比如订单系统）
消费者（Consumer）：收消息的人（比如支付、日志、数据分析）
Kafka：中间的大仓库 + 快递站

1. 核心角色

生产者（Producer）：负责产生消息并发送到 MQ。图中的数据源（MySQL、Flume、网络端口）就是生产者。
MQ 消息队列：作为中间层，负责暂存和转发消息。图中的 queue1、queue2、queue3 是不同的消息队列，用于分类存放不同类型的消息。
消费者（Consumer）：从 MQ 中拉取消息并进行处理。图中的目的地（Hadoop、SparkStreaming、Flink、SpringBoot）就是消费者。

2. 解耦的体现

在没有消息队列的情况下，每个数据源都需要和每个目的地直接对接，代码和依赖会变得非常复杂。
有了消息队列后：
生产者只关心发送：数据源（如 MySQL）只需要把数据发送到对应的队列（如 queue1），完全不用关心数据最终被谁处理。
消费者只关心消费：目的地（如 SparkStreaming）只需要从自己关心的队列（如 queue2）中拉取数据，完全不用关心数据是谁发的。
独立扩展与修改：如果需要新增一个数据源，或者替换一个目的地，只要它们遵守和 MQ 的接口约定，就不会影响到其他任何系统。

1. 同步处理（上半部分）
这是传统的 “串行等待” 模式：
用户填写注册信息并提交。
系统将注册信息写入数据库。
系统立即调用短信接口发送短信。
等待短信发送完成（大约 3 秒）后，才向用户返回 “注册成功” 的页面。
问题：
用户体验差：必须等待短信发送完成，才能看到结果，感觉 “卡顿”。
系统响应慢：整个流程被短信这个慢操作拖慢，影响并发能力。
故障影响大：如果短信接口超时或失败，整个注册流程也会失败。

2. 异步处理（下半部分）
这是引入消息队列后的 “解耦提速” 模式：
用户填写注册信息并提交。
系统将注册信息写入数据库。
系统不直接发送短信，而是把 “发送短信” 的请求写入 MQ 消息队列，然后立即返回。
用户瞬间收到 “注册成功” 的页面，体验流畅。
独立的短信服务从 MQ 队列中取出请求，慢慢处理发送短信的任务。
优势：
用户体验提升：核心流程（注册）瞬间完成，用户无需等待。
系统解耦：注册服务和短信服务互不依赖，各自独立运行。
削峰填谷：即使有大量注册请求，短信服务也可以按自己的节奏处理，不会被压垮。
故障隔离：短信服务暂时不可用，也不会影响用户注册。

1. 点对点模式（Point-to-Point）
核心特点：一条消息只能被一个消费者消费，消费后就从队列中删除。
流程：
生产者（Producer）将消息发送到消息队列。
消费者（Consumer）主动从队列中拉取消息。
消费者处理完消息后，向队列发送确认（Ack）。
队列收到确认后，将该消息从队列中删除。
适用场景：任务分发、订单处理等，确保每个任务只被执行一次。
------------------------
2. 发布 / 订阅模式（Publish/Subscribe）
核心特点：一条消息可以被多个订阅了对应主题（Topic）的消费者同时消费，消息不会因为被消费而删除。
流程：
生产者（Producer）将消息发布到特定的主题（Topic），比如图中的 Topic1、Topic2。
多个消费者（Consumer）订阅（Subscribe）自己感兴趣的主题。
当主题中有新消息时，所有订阅了该主题的消费者都会收到这条消息。
适用场景：日志收集、实时数据分析、用户行为通知等，允许多方同时处理同一份数据流。