面试官问：为什么kafka这么快，又能保证消息不丢失？

小菜鸡最近在疯狂面试中，就是为了能拿到一份满意的offer，这不上周又去头条受虐了。

面试过程中，由于小菜鸡的充分准备（letcode各种刷），各种算法题不在话下，顺利的通过的头条变态的算法面试。

面试官：我看你项目中用到了kafka，你觉得你这个场景一定需要kafka吗，有没有其它替代方案？

小菜鸡一听，很紧张啊，早知道简历上不写kafka了，原因你懂得，就好像redis只会put和get，kafka只会生产和消费，领导说用什么，就用什么。

小菜鸡挠挠头：当时接手这个项目的时候，设计方案已经定型了，如果要采用其它方案实现的话，改造成本比较大，不太实际，所以也就一直没对这块逻辑进行架构上的调整。

小菜鸡回答完，好想给自己的机智点赞。

面试官似乎还想在kafka上为难小菜鸡：那你知道为什么kafka这么快，又能保证消息不丢失？

小菜鸡实在没有过多的接触过kafka，只能投降了。

要回答上述问题，需要对kafka有较深入的理解。

通过 ACK 机制保证消息送达。Kafka 采用的是至少一次（At least once），消息不会丢，但是可能会重复传输。

为了得到更好的性能，Kafka 支持在生产者一侧进行本地buffer，也就是累积到一定的条数才发送，如果这里设置不当是会丢消息的。

生产者端设置 producer.type=async, sync，默认是 sync。

当设置为 async，会大幅提升性能，因为生产者会在本地缓冲消息，并适时批量发送。

如果对可靠性要求高，那么这里可以设置为 sync 同步发送。

如果更注重可靠性，则需要显示提交 Offset，也就是当所有业务都处理完成的时候，再提交 Offset。这样会导致重复消费，需要提供幂等性接口。

顺序写磁盘的性能是随机写入的性能的6000倍的提升，媲美内存随机访问的性能，磁盘不再是瓶颈点。

为了优化读写性能，Kafka利用了操作系统本身的Page Cache，就是利用操作系统自身的内存而不是JVM空间内存。通过操作系统的Page Cache，Kafka的读写操作基本上是基于内存的，读写速度得到了极大的提升。

零拷贝技术，可以有效的减少上下文切换和拷贝次数。

kafka的设计实现，涉及到很多的底层技术，为了能够把它吃透，需要花大量的时间，大量的精力。