CTO问我Pulsar替代Kafka的实际意义是什么
最近一年，Pulsar可谓出尽了风头。社区中一直在鼓吹Pulsar就是用来取代Apache Kafka的主宰地位的。Pulsar提供了一套兼容Kafka的API，让大数据工程师很丝滑不费力的从Kafka切换到Pulsar。
最近CTO也找到我，“听说你最近在研究Pulsar，也做过了很多实验。你能不能跟我说是Pulsar到底好在哪？我们现在用Kafka用得很好，为什么我看见很多公司都在换技术栈，在往Pulsar上迁移，你帮我写个文案，找个时间跟我汇报一下，我们看看切换的价值有多大？”。
一 Pulsar的消息确认（ACK）
我们知道，在Kafka中，恢复点通常被称为offset，更新恢复点的过程叫做消息确认或者提交offset。
而在Pulsar的每个订阅中，都是通过游标（Cursor）来跟踪每条消息的确认状态（ACK），每当消费者在确认消息的时候，都会更新游标信息。更新游标就是为了让消费者不再重复消费数据。
1.1 Pulsar的两种确认消息方式
1.1.1 累积确认
累积确认就是消费者只需要确认他收到的最后一条消息即可，累积确认与Kafka中的offset类似。
1.1.2 单条确认
Pulsar还支持消息的单条确认，也就是选择性确认，这就是Pulsar独到之处一。如下图，显示了单独进行确认的消息4和消息7，在消费失败重试的时候，除了4和7，其他消息都会重新消费。如果在消费每条消息都非常耗时的前提下，这种单条确认的方式就非常好。
注意：独占订阅或故障切换订阅的消费者能够对消息进行单条确认和累积确认；共享订阅的消费者只允许对消息进行单条确认。
1.2 Pulsar的消息保留（Retention）
下图说明了消息保留的方式，11之前的消息都应确认过，消息1-5已经超过了保留周期，就会被删除。消息12-20都没有被确认，同时消息16-20已经超过了消息保留期，会被删除；但是消息12-15就不会被删除。
1.3 在消息确认方面和Kafka的比对小结
通过以上几个方面，我们对 Pulsar 和 Kafka 在消息模型方面的不同点进行小结。
1.3.1 模型概念
- Kafka： Producer - topic - consumer group - consumer
- Pulsar：Producer - topic - subscription - consumer
1.3.2 消费模式
- Kafka：流（Stream）模式，对单个 partition 是独占消费，没有共享（Queue）的消费模式。
- Pulsar：供了统一的消息模型和 API。流（Stream）模式——独占和故障切换订阅方式；队列（Queue）模式——共享订阅的方式。
1.3.3 消息确认
- Kafka： 使用Offset来确认消息；
- Pulsar：使用专门的 Cursor 管理。累积确认和 Kafka 效果一样；提供单条或选择性确认。
1.3.4 消息保留
- Kafka：根据设置的保留期来删除消息。有可能消息没被消费，过期后被删除。 不支持 TTL。
- Pulsar：消息只有被所有订阅消费后才会删除，不会丢失数据。也允许设置保留期，保留被消费的数据。支持 TTL。
二 存储方式比对
Apache Pulsar 和 Apache Kafka 之间的根本区别在于 Apache Kafka 是以分区为存储中心，而 Apache Pulsar 是以 Segment 为存储中心。
2.1 Kafka 基于分区进行存储
在消息传递系统中使用基于分区的策略时，该主题被划分为固定数量的相等大小的分组，称为分区。发布到主题的数据均匀分布在分区中，如下图所示，每个分区接收发布到主题的消息的3分之1。现在，该主题的总存储容量等于该主题中的分区数乘以每个分区的大小。一旦达到此限制，无论向系统添加了多少节点，都无法将更多数据添加到主题中。
我们在创建主题的时候，预先确定分区的数量有一些意想不到的副作用，包括：
- 分区只能存储在单个节点上，因此其大小仅限于该节点上的可用磁盘空间量。
- 由于数据在所有分区中均匀分布，因此每个分区仅限于主题中最小分区的大小。例如，如果一个主题分别分布在具有4tb，2TB和1TB可用磁盘的3个节点上，则第三个节点上的分区的大小只能增长到1tb，这反过来意味着主题中的所有分区也只能增长到1tb。
- 尽管并非严格要求，但通常会将每个分区多次复制到不同的节点，以确保数据冗余。因此，最大分区大小进一步限制为最小副本的大小。
如果遇到这些容量限制之一，唯一的补救措施是增加主题中的分区数量。但是，这种容量扩展过程需要重新平衡整个主题，如下图所示。在此再平衡过程中，现有主题数据将在所有主题分区中重新分配，以释放现有节点上的磁盘空间。因此，当您将第四个分区添加到现有主题时，一旦重新平衡过程完成，每个分区应具有大约25% 的总消息。
这种数据重组成本高且容易出错，因为它消耗的网络带宽和磁盘I/O与主题大小成正比。例如，重新平衡10TB主题将导致10TB的数据从磁盘读取，通过网络传输并写入目标代理的磁盘。只有在重新平衡过程完成后，才能删除以前存在的数据，并且该主题才能恢复为客户端服务。因此，明智地选择分区大小是明智的，因为重新平衡的成本不容易被忽略。
2.2 Pulsar基于Segment进行存储
在以segment为中心的存储架构 (例如Apache Pulsar使用的架构) 中，每个主题都由托管ledger支持，它进一步细分为基于预先配置的时间或大小限制而滚动的段。然后，这些段分布在存储层中称为bookies 的多个节点上，以实现冗余和扩展。在任何给定时间，这些部分中只有一个可用于写，而其余部分则关闭，仅用于为读服务。
从上图可以看到，这些段可以放置在具有足够磁盘容量的存储层的任何位置。当存储层中没有足够的存储容量用于新段时，可以轻松地添加新节点并立即用于存储数据。这种存储架构的主要好处之一是真正的水平可扩展性，因为段可以无限期地创建并存储在任何地方。
总之，Apache Pulsar 这种独特的基于分布式日志存储的以 Segment 为中心的发布 / 订阅消息系统可以提供许多优势，例如可靠的流式系统，包括无限制的日志存储，无需分区重新平衡的即时扩展，快速复制修复以及通过最大化数据放置实现高写入和读取可用性选项。
但是，具体需不需要从Kafka升级为Pulsar，主要是看公司的业务场景，有没有那么大的数据量，如果数据量没有太多，更换技术栈不是给自己找麻烦吗？