【译】Kafka Producer Sticky Partitioner

最近事情多有点犯懒,依然带来一篇译文:Apache Kafka Producer Improvements with the Sticky Partitioner


消息在系统中流转的时间对于Kafka的性能来说至关重要。具体到Producer而言,Producer端的延时(Latency)通常被定义为:Producer发送消息到Kafka响应消息之间的时间间隔。俗话说得好,时间就是金钱。我们总是希望尽可能多地降低延时,让系统跑的更快。如果Producer发送消息的速度加快,整个系统都能受益。

每个Kafka topic包括若干个分区。当Producer给一个主题发送消息时,它首先需要确认这条消息要发送到哪个分区上。如果我们同时给同一个分区发送多条消息,那么Producer可以将这些消息打包成批(batch)发送。处理batch是有额外开销的。在这其中,batch中的每条消息都会贡献自己的“力量”。如果batch很小,那么batch中消息贡献的开销就越大。通常来说,小batch会导致Producer端产生更多的请求,造成更严重的队列积压效果(queueing),从而整体上推高了延时。

当batch大小达到了阈值(batch.size)或batch积累消息的时间超过了linger.ms时batch被视为“已完成”或“准备就绪”。batch.size和linger.ms都是Producer端的参数。batch.size默认值是16KB,而linger.ms默认值是0毫秒。一旦达到了batch.size值或越过了linger.ms时间,系统就会立即发送batch。

乍看上去,设置linger.ms=0似乎只会导致batch中只包含一条消息。但其实不是这样的。即使linger.ms=0,Producer依然会将多条消息打包进一个batch,只要它们是在很短的时间内被生产出来且都是发往同一个分区的。这是因为系统需要一定的时间来处理每个PRODUCE请求,而一旦系统无法及时处理所有消息,它就会将它们放入到一个batch里面。

决定batch如何形成的一个因素是分区策略(partitioning strategy)。如果多条消息不是被发送到相同的分区,它们就不能被放入到一个batch中。幸运的是,Kafka允许用户通过设置Partitioner实现类的方式来选择合适的分区策略。Partitioner接口负责为每条消息分配一个分区。默认的策略是对消息的Key进行哈希计算以获取目标分区,但是很多时候消息是没有指定Key的(或者说Key为null)。此时,Apache Kafka 2.4之前的默认策略是循环使用主题的所有分区,将消息以轮询的方式发送到每一个分区上。不幸的是,这种策略打包效果很差,在实际使用中会增加延时。

鉴于小batch可能导致延时增加,之前对于无Key消息的分区策略效率很低。社区于2.4版本引入了黏性分区策略(Sticky Partitioning Strategy)。该策略是一种全新的策略,能够显著地降低给消息指定分区过程中的延时。

黏性分区策略

黏性分区器(Sticky Partitioner)解决无Key消息分散到小batch问题的主要思路是选择单个分区发送所有的无Key消息。一旦这个分区的batch已满或处于“已完成”状态,黏性分区器会随机地选择另一个分区并会尽可能地坚持使用该分区——即所谓的粘住这个分区。这样,一旦我们拉长整个运行时间,消息还是能均匀地发布到各个分区上,避免出现分区倾斜,同时Producer还能降低延时,因为这个分配过程中始终能确保形成较大的batch,而非小batch。简单来说,整个过程如下图所示:

 

为了实现这个黏性分区器,Kafka 2.4版本为Partitioner接口新增了一个名为onNewBatch的方法。该方法会在新batch被创建前辈调用,也就是Producer要变更黏性分区(Sticky Partition)的时候。Producer默认分区器DefaultPartitioner实现了这个功能。

基础测试:Producer端延时

任何性能提升都必须要量化其效果。Kafka提供了一个名为Trogdor的测试框架(译者:官网几乎不见Trogdor的描述,有时间我写一篇blog介绍下)用于运行多种基础测试,这其中就包含测试Producer端延时。我使用了一个名为Castle的测试套件来执行ProduceBench测试。这些测试运行在一个3 Broker组成的集群上,配以1~3个Producer程序。

大多数的测试都使用如下的参数配置。你可以修改Castle配置,替换掉默认的任务参数配置。有些测试中设置稍有不同,后面会显式提及。

Duration of test 12 minutes
Number of brokers 3
Number of producers 1–3
Replication factor 3
Topics 4
linger.ms 0
acks all
keyGenerator {"type":"null"}
useConfiguredPartitioner true
No flushing on throttle (skipFlush) true

为了获得最好的测试效果,我们必须要设置useConfiguredPartitioner和skipFlush为true。这将确保Producer使用DefaultPartitioner执行分区策略,同时是否发送batch以batch.size和linger.ms参数来决定。当然了,你肯定要将keyGenerator设置成null,令消息无Key。

在与未修改前DefaultPartitioner的比较重,大多数测试表现出来的延时均低于之前版本。特别是在比较99百分位延时数值这一项时,3个Producer以每秒1000条消息的速度向16分区主题发送消息,测试结果表明使用新黏性分区器的Producer的延时是之前的一半。测试结果如下:

随着分区数的增加,延时下降的效果更加明显。这和我们之前的推测是吻合的:构造少量的大batch要比构造大量的小batch性能好。在我们的测试中分区数达到16时这种差异就已经很明显了。

接下来的测试保持Producer端的负载不变但增加了分区数。下图分别展示了16个、64个和128个分区的测试结果,结果表明之前分区策略的延时随着分区数的增加恶化得很快。即使是16个分区,平均的99百分位延时值依然是黏性分区器的1.5倍。

linger.ms测试以及不同Key消息的性能

如前所述,等待linger.ms会人为地增加延时。黏性分区器的目标就是要阻止这种延时,具体办法是把所有消息都发送到一个batch中,更快地填充batch。在一个相对吞吐量很低的环境中使用黏性分区器配以一个大于0的linger.ms值能够显著降低延时。我们的测试启动了一个Producer程序,每秒发送1000条消息,同时linger.ms=1000,结果表明之前分区策略的99百分位延时值提高了5倍。下图展示了ProduceBench测试的结果:

 如果Producer发送的是无Key消息,那么黏性分区器能够有效提升客户端的性能。如果Producer同时发送无Key消息和有Key消息,那么性能会是如何呢?我们运行了一个测试,随机为消息生成Key同时混以一些无Key的消息,结果表明在延时这个指标上无明显区别。

在这个测试场景下,我检查了有Key和无Key的混合消息。看上去这样的打包效果更好,但是因为Key值会忽略黏性分区器,因而收益并不明显。下图展示了三次运行结果的99百分位延时值的中位数值。从测试结果来看,延时并无显著变化,因此,该中位数能够有效地表征一次典型的测试运行结果。

第二个测试场景是在高吞吐量下随机生产Key。由于实现黏性分区器需要稍微变更代码,因此我们要确保新增加的逻辑不会影响延时。鉴于这里并没有任何打包或需要黏性行为出现,看上去延时和之前的差不多也是正常的结果。随机Key测试的中位数结果如下图所示。

最后,我测试了一个我认为最不适合使用黏性分区器的场景——顺序Key + 超多分区的场景。因为新增逻辑主要发生在新batch被创建,而这个场景下差不多为每条消息都创建一个batch,因此我们必须要检查这不会推高延时。结果显示延时没有明显差异,如下图所示:

测试过程中的CPU使用率

在测试过程中,我们注意到衡量黏性分区器能够降低CPU使用率。

举例来说,当3个Producer程序以每秒1万条消息的速度向16个分区发送消息时,我们观测到CPU使用率有明显下降。下两图中的每一行都表示节点的CPU使用率。每个节点既运行Producer程序也运行Broker进程。所有节点的线重叠在一起。在分区数增加和吞吐量下降的测试场景中我们也观测到了CPU的下降。

总结

黏性分区器的主要目标是为了增加每个batch中的消息数以减少总的batch数,从而消除不必要的queueing时间。一旦batch中消息变多,batch数变少,每条消息的成本就降低了。使用黏性分区策略能够更快地发送消息。测试数据已经证明该策略确实能够为无Key消息降低延时,并且当分区数增加时提升的效果更加明显。另外,使用黏性分区策略通常还能降低CPU使用。通过将Producer“黏在”一个分区并发送更少的大batch的方式,Producer能够有效地提升发送性能。

同时,最酷的是:这个黏性分区器默认集成在2.4版本,无需额外配置,开箱即用!

 

posted @ 2020-03-21 17:54  huxihx  阅读(420)  评论(0编辑  收藏