Pulsar-Consumer
“Pulsar is a distributed pub-sub messaging platform with a very flexible messaging model and an intuitive client API.”
Pulsar是pub-sub模式的分布式消息平台，拥有灵活的消息模型和直观的客户端API。
Pulsar由雅虎开发并开源的下一代消息系统，目前是Apache软件基金会的孵化器项目。
本片文章简单介绍Pulsar的Consumer，包含以下内容：
- Consumer的体系
- 消费逻辑的实现
1. Consumer体系
A consumer is a process that attaches to a topic via a subscription and then receives messages.
Consumer通过订阅关系绑定到Topic（和Producer类似，都是绑定到一个Topic上），并接收消息。
Consumer支持：
- 同步接收消息：阻塞用户线程等待消息
- 异步接收消息：异步等待消息（通过Future返回消息）
- 通过MessageListener返回消息：接收消息后回调用户的MessageListener
Consumer提供了三类获取消息的方式，其中异步的方式包含通过Future异步等待消息和通过MessageListener被动接收消息。MessageListener和另外两种方式是互斥的，一旦Consumer注册了MessageListener接口，则必须通过MessageListener处理消息，主动触发receive获取消息将抛出异常。
Consumer的继承关系：
- Consumer：定义了消费者相关的接口
- ConsumerBase：接口中基础方法的实现，抽象类
- ConsumerImpl：在ConsumerBase基础上的Consumer具体实现
- MultiTopicsConsumerImpl：组合多个ConsumerImpl完成对多Topic/Partition的消费
Consumer的设计和Producer是一致的，通过接口定义行为，基础类实现基本能力，在通过组合的方式来实现消费多个Topic/Partition（Producer则是像多个Topic发送消息）。
1.1 消费进度提交
Consumer处理消息后需要发送acknowledgement到Broker，这样Broker可以丢弃消息（应该是移动消费offset的操作，类似RocketMQ，并不是真正的删除消息）。支持单挑消息提交或者批量提交，批量提交则以最后一条消息的offset为准。（只是记录一个offset比较某个位置之前的消息都已经被Consumer处理，所以批量提交其实只是把最大的offset提交）
1.2 订阅模型
订阅模型决定了消息时如何被投递给Consumer的。在Pulsar中，订阅模型有： exclusive、shared、 failover。
Exclusive
只能有一个Consumer绑定到订阅关系上，其他Consumer尝试绑定到订阅关系上时会报错（Exclusive是默认的订阅模型）。
Shared
在Shared模型中，多个Consumer可以绑定到一个订阅关系上。消息按照round-robin模式被投递给各个Consumer。若某个Consumer宕机，被投递给该Consumer的未被ACK（没有acknowledgement）的消息将被重新投递给其他的Consumer进行消费。
Shared模式带来的限制：
- 消息时按照round-robin模式投递给各个Consumer的，所以消息顺序无法得到保障
- 同样因为round-robin模式，无法使用批量提交acknowledgement的功能（如上图Consumer C-3如果提交了m4会导致m3被标记为已经消费，但实际Consumer C1可能还没处理m3）
failover
在Failover模型中，多个Consumer可以绑定到一个订阅关系上，但是只有一个称为Master Consumer的消费者能消费消息。对多个Consumer按照name进行排序，第一个Consumer则为Master Consumer。
在Master Consumer失效（比如断开连接）后，Master Consumer未提交的消息和后续的消息会提交给后续的Consumer。
2. 消费逻辑的实现
Consumer获取消息的核心API有以下两个，分别实现同步获取消息和异步获取消息：
/**
* Receives a single message.
* <p>
* This calls blocks until a message is available.
*
* @return the received message
* @throws PulsarClientException.AlreadyClosedException
* if the consumer was already closed
* @throws PulsarClientException.InvalidConfigurationException
* if a message listener was defined in the configuration
*/
Message<T> receive() throws PulsarClientException;
/**
* Receive a single message
* <p>
* Retrieves a message when it will be available and completes {@link CompletableFuture} with received message.
* </p>
* <p>
* {@code receiveAsync()} should be called subsequently once returned {@code CompletableFuture} gets complete with
* received message. Else it creates <i> backlog of receive requests </i> in the application.
* </p>
*
* @return {@link CompletableFuture}<{@link Message}> will be completed when message is available
*/
CompletableFuture<Message<T>> receiveAsync();MessageListener则通过ConsumerBuilder接口进行设置并传入到Consumer的构造方法中。
这三个API都由ConsumerImpl#messageReceived触发，即Consumer接收到消息后根据请求的类型来决定：
- 同步获取消息的，将消息放入内存队列，被挂起的线程会从队列中获取消息
- 异步获取消息的，执行callback将消息放入future
- 通过MessageListener处理消息的，通过ListenerExecutor执行逻辑
可见Pulsar在消费模式上处理是统一的，即无论客户端采用何种方式进行消息的接收，消息统一由服务端进行“推送”，而在Consumer内部根据用户请求的类型进行处理。
通过ConsumerImpl#messageReceived的实现可以发现Pulsar的消息消费是一种“推”的模型，这和RocketMQ的“拉”的模型差异是很大的（RocketMQ采用一种Long-Polling的方式，由Consumer主动发起请求从服务端获取数据，若服务端有需要处理的消息，请求立即返回；如果没有消息，这个请求会在服务单阻塞一段时间，直到新消息到达或者请求即将超时，返回给客户端）。
Consumer获取消息的模型
具体看Pulsar-Consumer获取消息的代码实现会发现它也不是一种纯粹的，类似淘宝Notify的推的模式，而是一种推拉结合的方式，示意如下：
- Consumer向Broker发送FLOW请求，通知Broker可以推送消息给Consumer
- Broker将消息通过MESSAGE请求将消息推送给Consumer
这是一个反复的过程，每次Consumer接收消息处理后都会继续发送FLOW请求给Broker。
这是在RocketMQ或者Kafka的设计中都没有的一种方式，这种方式进行一定的拓展则可以实现类似akka的Dynamic Push/Pull模式（详见公众号历史文章：《Push or Pull?》）。
在阅读Pulsar Consumer部分代码的时候还发现非常有趣的一点，当你搜索“Consumer”时会出现一个Consumer接口和一个Consumer类：
- 接口: org.apache.pulsar.client.api.Consumer
- 类: org.apache.pulsar.broker.service.Consumer
Consumer接口是Client模块定义Consumer行为的，为什么在Broker模块会有一个Consumer类？
实际在Broker端会给链接上来的Consumer构造一个对应的Consumer对象，维护远端的Consumer的链接等信息。所有对远端的Consumer的操作会封装在Broker端的Consumer中。这样可以更好的实现代码的可插拔性，降低耦合，提升代码的可测试性。比如在测试Broker端的逻辑时，只需要Mock一个Consumer类来模拟各种正常和网络异常的情况，而不需要真正的启动一个Consumer。
总结
本文主要是介绍一下Pulsar Consumer模块的相关概念和一些模型，没有深入的解读代码实现。Pulsar Consumer的实现方式还是非常有趣的，和大家比较熟悉的RocketMQ的实现方式差异比较大，值得一读。
