Apache Pulsar in Action第二章读书笔记
订阅(subscription)
每个订阅都有描述它的元数据，存放在Pulsar的Zookeeper中，包括但不限于：
- 此订阅的所有消费者的http地址
- 游标(cursor)，代表了此订阅下，最后一个被消费且被确认了的消息的位置
订阅模式
以一家股票数据分析公司为例
exclusive
独占模式，订阅的消息只能由一个消费者消费，多余的消费者想要订阅到此topic，会报错。适用场景：有序，且每个消息只能被一个消费者消费一次：
failover
故障转移模式，高可用版的exclusive，一个挂了，备份顶上，继续消费：
shared
每个订阅都有消息的副本，而订阅使用轮询模式投递给订阅下的消费者，适用于实现工作队列，因为顺序不重要，可以扩展消费者个数以提高消费能力：
key-shared
相当于SQL中的GROUP BY，对消息以某个key作为分组依据，进行分组，然后投递给不同的消费者，如下图所示，Oracle的股票数据让Consumer-C处理，Microsoft的股票数据让Consumer-A处理，Amazon的股票数据让Consumer-B处理，这里的分组依据就是股票代码：
消息保留与过期策略
broker级别的消息保留策略
消息默认的保留策略是：所有topic的消费者都确认了这条消息，那这条消息就会被删除。保留策略可由defaultRetentionTimeInMinutes和defaultRetentionSizeInMB参数控制，这两个参数都是broker级别的，在broker的配置文件中配置，默认都是0，代表一旦消息被确认，就会被删除。
namespace级别的消息保留策略
Pulsar支持在namespace级别覆盖broker级别的消息保留策略：
消息积压策略
消息积压就是消费者的消费速度跟不上生产者的生产速度，造成了积压：
Pulsar默认会一直保留未被确认的消息，但是可以在namespace级别改变这一设置，消息积压策略和上一节的消息保留策略类似，只不过前者配置的是未确认消息的保留策略，后者是已确认消息的保留策略。积压策略有三种：
producer_request_hold策略，给生产者发送异常，提示生产者应该暂停发送。适用于生产者显式捕获异常并稍后重试的场景producer_exception策略，强制断开生产者连接。适用于资源敏感的场景，比如某些内存有限的设备上，及时断开连接，节省资源consumer_backlog_eviction策略，此策略不影响生产者，旧的未被确认的消息将被删除，这会造成消息丢失
消息过期策略
消息过期策略在消费者更关心最新数据的情况下经常用到，比如坐网约车，乘客更关心司机的最新位置，而不是5分钟前的位置，如下所示，将E-payments/payments namespace下的消息存活时间设置为120秒：
消息保留策略、消息过期策略、消息积压策略的关系
消息保留策略针对已被确认的消息，消息积压策略针对未被确认的消息，其中，存活时间超过了TTL的消息将被删：
消息保留策略可以结合下面要讲的层级存储来实现无限容量的存储。