- 生产者
（如会议方、出版社）负责生成数据（论文）并发布到消息中心（论文网站）；
- 消费者
（如学生、老师）向消息中心订阅感兴趣的内容（如分布式、AI 相关论文）；
- 消息中心
（如 ACM、知网）根据订阅关系，将生产者发布的数据推送给对应消费者（如邮件通知）。
该模式类比 “送货上门”，通过解耦生产与消费流程，实现数据的定向分发。
生产者将消息发送到消息中心，然后消费者从消息中心取出对应的消息进行消费。消息被消费后，消息中心不再存储该消息，因此其他消费者无法再消费该消息。也就是说，点对点模式虽然支持多个消费者，但一个消息只能被一个消费者消费，不允许重复消费。
这种模式就好比，限定了每篇论文只能被一个用户消费，比如现在有一篇分布式相关的论文，这篇论文推送给学生 A 之后，论文网站就必须将其删除或下架，也就是说其他用户无法再获取或阅读该论文了。（当然实际情况并不是这样的，这里只是为了方便你理解，我做了相应的假设。）
生产者可以发送消息到消息中心，而消息中心通常以主题（Topic）进行划分，每条消息都会有相应的主题，消息会被存储到自己所属的主题中，订阅该主题的所有消费者均可获得该消息进行消费。
比如图中假设生产者 1 发布一个 Topic 相关数据或消息，消费者 1～3 均订阅了该 Topic 消息，则该消息会推送消费者 1～3，也就是说同一个消息被 3 个消费者消费了。
这种模式就好比，不同的方向代表不同的主题，比如分布式领域代表一个主题，当会议方或出版社发布分布式相关的论文时，该论文会被存储到论文网站的分布式主题下，同时学生或老师也会根据自己感兴趣的主题进行订阅。如果学生 A 订阅了分布式主题，那么当会议方或出版社发布分布式相关的论文后，会议网站会将这些论文推送给学生 A。
可以看到，Kafka 中除了 Producer、Broker、Consumer 之外，还有一个 ZooKeeper 集群。
Zookeeper 集群用来协调和管理 Broker 和 Consumer，实现了 Broker 和 Consumer 的解耦，并为系统提供可靠性保证。ZooKeeper 集群可以看作是一个提供了分布式服务协同能力的第三方组件，Consumer 和 Broker 启动时均会向 ZooKeeper 进行注册，由 ZooKeeper 进行统一管理和协调。
ZooKeeper 中会存储一些元数据信息，比如对于 Broker，会存储主题对应哪些分区（Partition），每个分区的存储位置等；对于 Consumer，会存储消费组（Consumer Group）中包含哪些 Consumer，每个 Consumer 会负责消费哪些分区等。
从上面的介绍可以看出，Broker 负责存储消息数据，Consumer 负责消费数据，Consumer 消费数据的能力会影响 Broker 数据存储是否溢出的问题。若 Consumer 消费太慢，会导致 Broker 存储溢出，Broker 就会丢弃一部分消息。
因此，Broker 和 Consumer 是 Kafka 的核心。接下来，我将带你进一步了解 Kafka 中 Broker 和 Consumer 的关键技术，如下图所示：
在 Kafka 中，为了解决消息存储的负载均衡和系统可靠性问题，所以引入了主题和分区的概念。其中，主题是一个逻辑概念，指的是消息类型或数据类型，就好比电子论文案例所讲的分布式是一个主题。
而分区是针对主题而言的，指的是一个主题的内容可以被划分成多个集合，分布在不同的 Broker 上，不同的 Broker 在不同的节点上。这里的集合就是分区，其中同一个分区只属于一个 Broker。
-
通过将 Topic 的消息分散到多个分区，分布在不同 Broker 上，避免单个 Broker 负载过高，提升系统处理能力。
-
通过设置多个分区存储相同内容，分布在不同 Broker 上，实现消息备份，保障系统数据可靠性。
Kafka 中的消费组，指的是多个消费者的一个集合。一个消费组中的消费者共同消费主题消息，并且主题中每个消息只可以由消费组中的某一个消费者进行消费。
引入消费组的目的是什么呢？我们知道，在消息过多的情况下，单个消费者消费能力有限时，会导致消费效率过低，从而导致 Broker 存储溢出，丢弃一部分消息。Kafka 为了解决这个问题，所以引入了消费组。
假设在电商购物平台（为了方便理解，我对电商购物平台做了一定的简化）中，用户首先在订单系统下单，下单后库存系统会进行出货，通知系统则负责通知用户，整个流程可以用发布订阅的模式进行，如下图所示：
订单系统对应发布订阅模式中的生产者，消息中心有个主题专门存放下单信息，每次用户下单后，订单系统会向该主题写入数据；
库存系统和通知系统对应发布订阅模式中的消费者，它们会向消息中心订阅下单信息相关的主题；
订单系统向消息中心发布订单信息后，库存系统和通知系统都会获取到相应的下单信息，然后进行各自后续的操作，即库存系统进行出货，通知系统通过短信或邮件等方式通知用户。
观察者模式中，观察者和被观察者直接关联。被观察者状态一旦改变，就会主动通知观察者执行相应操作。比如进程 A 的变量变化，进程 B 和进程 C 会根据变化分别执行不同操作。这种模式直接通信，响应快，但两者耦合度高，一方改变，另一方就得调整。
发布订阅模式引入了消息中心，发布者将消息发至消息中心，订阅者提前告知消息中心自己感兴趣的内容，消息中心再按需推送。像学术论文平台，出版社上传论文，研究者订阅感兴趣领域，平台按订阅推送。该模式下发布者和订阅者不直接接触，解耦性强，扩展性好，但因消息需经中心中转，架构复杂，通信也会慢一些。
