分布式通信：发布订阅
什么是发布订阅？
远程调用的核心是在网络服务层封装了通信协议、序列化、传输等操作，让用户调用远程服务如同进行本地调用一样。
这种通信方式虽然也是设置成异步的，但是因为进程之间是直接交互的，所以当进程比较多时，会导致进程维护通信的复杂度非常高，且一个进程通信接口改变，与其通信的进程都会受到影响。
为了解决这个问题，我们需要设计专门的异步通信模式，包括消息发布订阅和消息队列两种方式。
发布订阅的三要素：
- 生产者，负责产生数据放到消息中心。
- 消费者，向消息中心订阅自己感兴趣的消息。
- 消息中心，当发布者推送数据到消息中心后，消息中心根据消费者订阅情况将数据推送给对应的订阅者。
两种消息系统模式
消息系统包括两种典型模式：
- 点对点模式，生产者将消息发送到消息中心，然后消费者从消息中心取出对应的消息进行消费，消息被消费后，消息中心不再存储该消息，这样其他消费者无法再消费该消息。点对点模式虽然支持多个消费者，但是一个消息只能被一个消费者消费，不允许重复消费。
- 发布订阅模式，生产者可以发送消息到消息中心，而消息中心通常以主题（Topic）进行划分，每条消息都会有相应的主题，消息会被存储到自己所属的主题中，订阅该主题的所有消费者都可以获得该消息进行消费。
点对点模式中的一个消息，只能被一个消费者消费，发布订阅模式中的一个消息，可以被多个消费者消费。
发布订阅模式的关键特征：
- 实现了系统解耦，易于维护。
- 实现了异步执行，避免高负载。
Kafka发布订阅原理
Kafka是一种典型的发布订阅消息系统，它的架构包括三部分：
- 生产者（Producer），负责发布消息到消息中心。
- 消费者（Consumer），向消息中心订阅自己感兴趣的消息，获得数据后进行数据处理。
- 消息中心（Broker），负责存储生产者发布的消息和管理消费者订阅信息，根据消费者订阅信息，将消息推送给消费者。
Kafka的架构如如下所示。
上图中还包括ZooKeeper集群，它用来协调和管理Broker和Consumer，实现Broker和Consumer的解耦，并未系统提高可靠性保证。Consumer和Broker启动时都会向ZooKeeper进行注册，由ZooKeeper进行统一管理和协调。
ZooKeeper会存储一些元数据信息，比如对于Broker，会存储主题对应哪些分区，每个分区的存储位置等，对于Consumer，会存储xiaofeizu中包含哪些Consumer，每个Consumer回负责消费哪些分区等。
Kafka Broker
为了解决消息存储的负载均衡和系统可靠性，Kafka引入了主题和分区的概念。
主题是一个逻辑概念，指消息类型或者数据类型。
分区指一个主题的内容可以被划分成多个集合，分布在不同的Broker上，不同的Broker在不同的节点上。
分区设计带来的好处：
- 实现负载均衡。
- 实现消息备份（我们可以设置Replicates)。
Kafka Consumer
Kafka中的消费组，指的是多个消费者的一个集合，一个消费组中的消费者共同消费主题消息，并且主题中每个消息只可以由消费组中的某一个消费者进行消费。
引入消费组可以解决单个消费者消费消息效率过低的问题。
观察者模式和发布订阅模式
观察者负责监控被观察者的状态变更，如果被观察者的状态发生改变，那么观察者根据状态的变更执行相关操作。观察者模式定义了被观察者和观察者的直接交互或者通信关系。
发布订阅模式中存在发布者、订阅者和消息中心，订阅者需要向消息中心指定自己对哪些数据感兴趣，发布者推送的数据放入消息中心后，消息中心根据订阅者订阅信息推送数据。发布者与订阅者之间引入了消息中心，实现的是间接通信。
观察者模式采用了直接通信，观察者与被观察者通信时延低一些，但它们的依赖关系比较强，不管是被观察者还是观察者的逻辑或接口有更改，另外一个都会受到影响。而发布者和订阅者模式采用间接通信，引入消息中心，相对比较厚重，且通信时延高一些，但实现了订阅者和发布者的解耦。
发布订阅中的消息传递模式
发布订阅中的消息传递有两种模式：
- 拉模式：消费者主动去拉取消息。
- 推模式：消息中心推送消息给消费者。
推模式中，消息中心需要考虑消费者的消费能力，不能把消费者压垮了，但从消息中心的角度看，这样可以控制消息的消费速度，调控积压消息。
拉模式中，消费者自己控制消息消费速度，但有可能会导致消息中心中消息挤压，会有消息丢失或者消息中心不可用的风险。