一、Pulsar数据生产流程
- 1、客户端调用pulsar提供给客户端的API，进行数据的生产操作，将生产的消息传递给producer。
- 2、在生产端内部有一个MessageWriter的类，基于这个类实现数据分发操作，默认方案为round-robin(轮询)，同时为了提高效率，在一定的时间内，只会选择一个partition
除了支持轮询方案外，如果在传递消息指定key，会采用hash取模的方式确定要发送到那个partition，同时pulsar支持自定义分发策略。 - 3、客户端在此连接broker，根据要发送的partition获取对应服务的broker节点。
- 4、broker收到消息后调用bookkeeper的客户端并发去写多个副本。
- 5、broker端会等待bookkeeper写入完成，当broker收到所有副本的ack之后，会认为这条消息已经写入成功，broker会返回客户端，告知这条消息已经被持久化完成。
说明：整个写入操作，客户端不会跟zookeeper打交道，也不会和bookkeeper打交道，只需要和broker即可。
二、Pulsar数据读取流程
Consumer在消费数据时候，主要有二种情况，一种为broker中已经缓存了消息，一种为broker中没有缓存信息：
- 1、消费者连接broker地址，根据要读取的对应topic的分配，确定要连接的最终的broker地址，如果没有指定分片，那么就连接每一个分片对应的broker地址。
- 2、对应的broker首先判断消息是否已经有缓存数据，如果存在，直接从内存中采用推的方式发送给消费者，将消息放置在一个receiver 队列中，消费端从队列中读取即可，如果没有缓存，此时broker端通过bookkeeper的客户端到bookie中读取数据(内部可以读取任意副本的数据)
三、Pulsar数据读写故障处理流程
生产端产生失败：
- 当出现 [发消息网络断开，broker宕机] 等情况时候，这个时候producer有 pending 队列，会在设置的超时时间内进行重试策略。
Broker端出现宕机
- 因为broker是没有状态的，所以它不保存任何数据，一旦宕机后，topic的管理权会被其他broker掌管，这个时候，服务会被快速恢复
Bookkeeper出现宕机
- 存储节点只负责数据存储，bookkeeper本身是一个集群，故如果只挂掉一个bookie，并不影响，所以broker是不会感知的，除非所有的bookie都挂掉，没有足够的副本去写入数据。
消费端消费失败
消息没有被consume进行ack确认，下次可以继续消费。也可以通过failover的subscription进行consume故障转移。
一个订阅同时只有一个消费者，但是可以拥有多个备份消费者，一旦主消费者故障，则备份消费者接管，进行消费即可；同时pulsar还支持一个分区对应多个消费者，或者一个消费端对应多个分片的情况。
同时只要消息没有被消费者所消息，在pulsar中消息就没有变成确认状态，下次依然是可以再次消费的。
