小菜鸡最近在疯狂面试中,就是为了能拿到一份满意的offer,这不上周又去头条受虐了。
面试过程中,由于小菜鸡的充分准备(letcode各种刷),各种算法题不在话下,顺利的通过的头条变态的算法面试。
面试官: 我看你项目中用到了kafka,你觉得你这个场景一定需要kafka吗,有没有其它替代方案?
小菜鸡一听,很紧张啊,早知道简历上不写kafka了,原因你懂得,就好像redis只会put和get,kafka只会生产和消费,领导说用什么,就用什么。
小菜鸡挠挠头: 当时接手这个项目的时候,设计方案已经定型了,如果要采用其它方案实现的话,改造成本比较大,不太实际,所以也就一直没对这块逻辑进行架构上的调整。
小菜鸡回答完,好想给自己的机智点赞。
面试官似乎还想在kafka上为难小菜鸡: 那你知道为什么kafka这么快,又能保证消息不丢失?
小菜鸡实在没有过多的接触过kafka,只能投降了。
要回答上述问题,需要对kafka有较深入的理解。
如何做到消息不丢失
ACK 机制
通过 ACK 机制保证消息送达。Kafka 采用的是至少一次(At least once),消息不会丢,但是可能会重复传输。
发送消息
为了得到更好的性能,Kafka 支持在生产者一侧进行本地buffer,也就是累积到一定的条数才发送,如果这里设置不当是会丢消息的。
生产者端设置 producer.type=async, sync,默认是 sync。
当设置为 async,会大幅提升性能,因为生产者会在本地缓冲消息,并适时批量发送。
如果对可靠性要求高,那么这里可以设置为 sync 同步发送。
消费消息
如果更注重可靠性,则需要显示提交 Offset,也就是当所有业务都处理完成的时候,再提交 Offset。这样会导致重复消费,需要提供幂等性接口。
为什么 Kafka 性能高?
顺序写磁盘
顺序写磁盘的性能是随机写入的性能的6000倍的提升,媲美内存随机访问的性能,磁盘不再是瓶颈点。
Page Cache
为了优化读写性能,Kafka利用了操作系统本身的Page Cache,就是利用操作系统自身的内存而不是JVM空间内存。通过操作系统的Page Cache,Kafka的读写操作基本上是基于内存的,读写速度得到了极大的提升。
零拷贝技术
零拷贝技术,可以有效的减少上下文切换和拷贝次数。
kafka的设计实现,涉及到很多的底层技术,为了能够把它吃透,需要花大量的时间,大量的精力。