技术大佬问我，kafka为什么这么的快？（2）

技术大佬 ：（幸运上次到饭点，否则就尬死了，这个佩琪问题真多，没办法还需要继续装下去）

技术大佬 ： 批量拉取：是指 消费端拉取broker消息时，不是每次获取单条消息，而是在从broker端获取消息时，尽量一次网络IO获取尽量多消息（默认最大上限为500条）。这也是kafka 使用“批量”这个提升系统吞吐量优化手段之一的体现；这里的消费端批量拉取和生产端使用的批量方式，有相似的效果，都是为了尽可能节约资源，把主要精力放到真正的消息处理里。

技术大佬 ： 你不觉得 kafka把“批量”这个优化手段用到了极致吗？生产端批量发送消息；broker端也是把消息先写入pagecache暂存，然后通过定时刷新page cache里消息，顺序批量的把消息写入磁盘；消费者端也是批量的拉取消息到本地后进行消费**。**

佩琪： 好像还真是哦。 对了，大佬，为什么kafka要采用这种主动拉取消息的方式了，在我们 固有的认知里，不是应该broker 感知到了有消息后，主动推送消息到消费者端，这种更快的消息通知方式吗？

技术大佬 ： 这个从kafka官方文档里，可推测一二；采用生产者推消息，消费者拉消息模式，主要是参考了业界其它消息系统采用的方式，即参考了前辈和友商的经验。

技术大佬 ： 有个推和拉的对比，你要不学习下？

	推模型	拉模型
数据及时性上	快。有数据立刻推送给消费者，速度在毫秒级	慢一个数量级。快慢取决于本地轮训时间间隔
数据延迟性上	低延迟	数据延迟，取决于本地轮训时间间隔
高负载性	消费者可能不可控：如果生产者产生数据的速率远远快于消费者处理数据速率；消费者有可能会被压到，导致数据丢失，或者处理端性能下降	消费者完全自主可控：允许消费者完全控制拉取数据的频率和数据量；在面对流量洪峰，也能适应其处理能力和需求
资源利用率上	高效：有数据才和消费者网络通信	较低效：即使没有消息也需要不断轮训broker端
网络兼容性上	低 ：网络出现问题，需要频繁的推送	高：在不可靠的网络中更具优势，可以等待数据就绪后在进行拉取
消费者实现复杂度上	比拉模型简单，只需要被动接受数据	稍显复杂；需要定时拉取
broker端实现复杂度上	复杂，需要实现推送和数据传输机制，增加broker端复杂度	简单，被动接受查询；实现比推模型简单
数据处理速率上	处理效率低下：无批量处理，来一条推一条消息	高效：消费者可批量拉取数据，批量处理数据，提高了数据处理效率

佩琪： 对了大佬，你还说了最后一点 批量消息压缩是啥意思？

技术大佬 ： 上次咱们不是说了，kafka 生产端是批量发送消息的；这个压缩，是指把这个批量消息作为一个整体进行压缩，然后通过一次网络IO发送给broker端。这种方式比不压缩，节约了网络带宽；并且在broker端存储的时候，也不会对消息进行解压，还节约了磁盘存储空间；另外压缩后的消息，直到消费者从broker端获取后，才会在消费者端进行解压缩。

这样就带来了，消息从生产端到broker端，再从broker端到消费者端的网络传输里，都是经过压缩的消息，从整体上节约了网络带宽和网络层传输的效率。

佩琪： 这好像看起来没啥了不起的，我们在业务层也可以进行单条消息压缩，最后批量发送出去，效果也是一样的呀

技术大佬 ： 理论上和实际操作上都可行，但你不觉得这种方式的压缩比有点低吗？这种方式，可能会导致许多冗余是由于相同类型的消息之间的重复引起的。比如（ JSON 中的字段名称、Web 日志中的用户代理或常见字符串值）；本来这些在多个消息中可能重复的值，在单个消息里就有可能不会被压缩了。

佩琪： 摸摸猪头，原来如此，那还是先用kafka自带的压缩方式吧。

总结

联系上篇文章，下次再问我 kafka 这么快的原因，我会总结似的回答如下：

1. 生产端：

   • 采用了异步提交消息的方式，加快了上层业务调用端的返回
   • 底层采用了 批量发送的方式，减少网络IO的次数。

2. broker端

   • 写数据时，使用了同步写磁盘缓存+ 异步刷新数据到磁盘文件系统，提高了消息数据落到文件系统的速度；
   • 在读取消息时，使用零拷贝技术，减少磁盘IO读取次数，加快读消息过程
   • 利用broker天生的分布式能力，通过扩展硬件机器，带来消息发送和处理速度的提升。

3. 消费端

   • 采用了批量拉取方式，一次IO拉取多条消息，加快消息传输和消息处理过程

4. 端到端的批量压缩

   • 减少了消息在网络中给个节点的传输量，提升了网络层传输效率

   • 减少了broker端pagecache和磁盘的存储空间，提升了内存和磁盘的利用率

参考资料：

kafka 官方文档： kafka.apache.org/documentati…