1. 什么是purgatory

Broker的一项主要工作就是接收并处理网络上发来的Request。这些Request其中有一些是可以立即答复的,那很自然这些Request会被直接回复。另外还有一部分是没办法或者Request自发的要求延时答复(例如发送和接收的Batch),Broker会把这种Request放入Paurgatory当中,同时每一个加入Purgatory当中的Request还会额外的加入到两个监控对队列:

  1. WatcherFor队列:用于检查Request是否被满足
  2. DelayedQueue队列:用于检测Request是否超时

加入purgatory的request主要分为两类,分别来自producer的发送请求,或者来自broker的fetch请求。因此purgatory队列也分为两类

  1. producer purgatory
  2. fetch purgatory

2. pugatory上的坑

目前版本的Purgatory设计上是存在一定缺陷的。Request状态转变为Complete后,并没能立即从Purgatory中移除,而是继续占用资源,因此占用内存累积最终会引发OOM。这种情况一般只会在topic流量较少的情况下触发。更详细的资料可以查阅扩展阅读,在此不做展开。

在实际使用中我也是踩了这个坑过来的,当时的情况是集群新上了一个topic,初期该topic数据很少(Low volume topic),导致那段时间在凌晨3,4点左右会随机有Broker因为OOM挂掉。定位原因后把*.purgatory.purge.interval.requests的配置调整小至100就解决了这个问题。

Kafka的研发团队已经开始着手重新设计Purgatory,力求能够让Request在Complete时立即从Purgatory中移除。

参考资料:

  1. kafka性能参数和压力测试揭秘
  2. 官方文档:Request Purgatory (0.8) 扩展阅读: 1.Request Purgatory潜在引发OOM的问题 2.Purgatory Redesign