论Pulsar消息模型

1、队列QUEUE模型
队列模型主要采用无序或者共享的方式来消费消息。通过队列模型，用户可以创建多个
消费者从单个管道中接收消息；当一条消息从队列发送出来后，多个消费者中的只有
一个接收和消费这条消息，消息系统实现并决定哪个消费者接收消息。队列模型通常
与无状态应用结合使用。无状态应用不关心排序，但能确认活删除单条信息，以及尽可能
扩展消费并行性的能力。包括rabibtmq\rocketmq

2、流式STREAM模型
对于一个管道，使用流式模型，始终只有一个消费者使用和消费消息。消费者按照消息
写入管道的确切顺序接收从管道发送的消息。 流式模型与有状态应用关联。有状态的应用
更加关注消息的顺序及状态。消息的消费顺序决定了有状态应用的状态。消息的顺序影响
应用处理逻辑的正确性

3、Apache Pulsar通过-->producer-topic-subsription-consumer消息模型，支持队列与流式模型
在pulsar中，topic用于发送消息的通道，每一个topic对应BookKeeper中的一个分布式日志。发布者
发布的每条消息只在topic中存储一次；存储的过程中，BookKeeper会将消息复制存储在多个存储
节点上；topic中的每条信息，可以根据消费者的订阅需求，多次被使用，每个订阅者对应一个消费组。
消息在topic存储一次，但用户可以用不通的订阅方式来消费消息。
1、消费者被组合在一起以消费消息，每个消费组是一个订阅
2、每个topic可以有不同的消费组
3、每组消费者都是队topic的一个订阅
4、每组消费者可以拥有自己不同的消费方式：独占-Exclusive 故障切换-Failover 共享-Share

4、消费方式
1、独占订阅--在任何时间，一个消费组中有且只有一个消费者来消息topic中的消息
2、故障切换订阅--多个消费者可以附加到同一订阅，但一个订阅中的所有消费者，只有一个消费者被选为该订阅
的主消费者，其他消费者将被指定为故障转移消费者。当主消费者断开连接时，分区将重新分配
给其中一个故障转移消费者，而新分配的消费者将成为新的主消费者。这种情况时，所有未确认ACK
的消息都将传递给新的主消费者
3、共享订阅--在同一个订阅背后，用户按照应用的需求挂载任意多的消费者。订阅中的所有消息以循环分发
形式发送给订阅背后的多个消费者，并且一个消息只传递给一个消费者。当消费者断开连接时，所有传递给它
但还未确认ACK的消息将被重新分配和组织，以便发送给该订阅上剩余的剩余消费者

独占和故障切换订阅模式适用消息顺序，共享订阅适用不需要保证消息顺序的队列，并可以按照任意扩展消费者数量

5、消息确认ACK
每个订阅中使用一个专门的数据结构-游标来跟踪订阅中每条消息的确认ACK状态。每当消费者在主题分区上确认
消息时，游标都会更新，确保消费者不会再次收到消息。
分为两种确认方式：单挑确认、累计确认。通过累计确认，消费者只确认它收到的最后一条消息。消费者也可单独
确认一条消息，被确认后的消息将不会被重新传递

6、消息保留
在消息被确认后，broker会更新对应的游标。当topic里面中的一条消息，被所有的订阅都确认ACK后，才能删除
这条消息。Pulsar还允许设置保留时间，将消息保留更长时间。 Pulsar还支持消息生存时间TTL。如果消息未在
配置的TTL时间段内被任何消费者使用，则消息将自动标记为已确认。

7、Broker
Broker集群在Pulsar形成无状态服务层。并不在本地存储任何消息数据。有关topic的消息，都被存储在分布式
日志存储中(BookKeeper)。 每个topic分区由Pulsar分配给某个Broker，该broker成为该主题分区的所有者。
生产者和消费者连接到主题分区的所有者broker，向所有者代理发送消息并消费消息。如果一个broker失败，
Pulsar会自动将其拥有的主题分区异动到群集中剩余的某一个可用broker中，在这个过程中，不会有任何数据
复制发生

8、BookKeeper层，持久化存储层
每个分布式日志分为segment分段，每个segment分段作为BookKeeper中一个ledger，均匀分布并存储在
BookKeeper群集中的多个Bookie（存储节点）