Apache Pulsar 消息确认（ACK）
介绍
由于分布式系统的特性，当使用分布式消息系统时，可能会发生故障。比如在消费者从消息系统中的主题消费消息的过程中，消费消息的消费者和服务于主题分区的消息代理（Broker）都可能发生错误。消息确认（ACK）的目的就是保证当发生这样的故障后，消费者能够从上一次停止的地方恢复消费，保证既不会丢失消息，也不会重复处理已经确认（ACK）的消息。
在Apache Kafka中，恢复点通常称为Offset，更新恢复点的过程称为消息确认或提交Offset。
在Apache Pulsar中，每个订阅中都使用一个专门的数据结构–游标（Cursor）来跟踪订阅中的每条消息的确认（ACK）状态。每当消费者在主题分区上确认消息时，游标都会更新。更新游标可确保消费者不会再次收到消息。
消息确认
Pulsar 提供两种消息确认方法：
- 单条确认（Individual Ack）: 单独确认一条消息。 被确认后的消息将不会被重新传递
- 累积确认（Cumulative Ack）: 通过累积确认，消费者只需要确认它收到的最后一条消息
下图说明了单条确认和累积确认的差异（灰色框中的消息被确认并且不会被重新传递）。对于累计确认，M12 之前的消息被标记为 Acked。对于单独进行 ACK，仅确认消息 M7 和 M12， 在消费者失败的情况下，除了 M7 和 M12 之外，其他所有消息将被重新传送。
Apache Pulsar可以支持消息的单条确认，也就是选择性确认。消费者可以单独确认一条消息。 被确认后的消息将不会被重新传递。
累积确认，消费者只需要确认它收到的最后一条消息。主题分区中的所有消息（包括）提供消息ID将被标记为已确认，并且不会再次传递给消费者。累积确认与Apache Kafka中的Offset更新类似。
消费模式支持
独占订阅或灾备订阅的消费者能够对消息进行单条确认和累积确认；共享订阅的消费者只允许对消息进行单条确认。
管理Ack的专门的数据结构–游标（Cursor），由Broker来管理，利用BookKeeper的Ledger提供存储
参考链接