Kafka 应对场景：消息持久化、吞吐量是第一要求、状态由客户端维护、必须是分布式的。Kafka 认为 broker 不应该阻塞生产者，高效的磁盘顺序读写能够和网络 IO 一样快，同时依赖现代 OS 文件系统特性，写入持久化文件时并不调用 flush，仅写入 OS pagecache，后续由 OS flush。
这些特性决定了 Kafka 没有做“确认机制”，而是直接将生产消息顺序写入文件、消息消费后不删除（避免文件更新），该实现充分利用了磁盘 IO，能够达到较高的吞吐量。代价是消费者要依赖 Zookeeper 记录队列消费位置、处理同步问题。没有消费确认机制，还导致了 Kafka 无法了解消费者速度，不能采用 push 模型以合理的速度向消费者推送数据，只能利用 pull 模型由消费者来拉消息（消费者承担额外的轮询开销）。
如果在 Kafka 中引入消费者确认机制，就需要 broker 维护消息消费状态，要做到高可靠就需要写文件持久化并与生产消息同步，这将急剧降低 Kafka 的性能，这种设计也极类似 RabbitMQ。如果不改变 Kafka 的实现，而是在 Kafka 和消费者之间做一层封装，还是需要实现一套类似 RabbitMQ 的消费确认和持久化机制。