化妆品设计网站wordpress开发人力资源

  近期，我们线上遇到了一个性能问题，几乎快引起线上故障，后来仅仅是修改了一行代码，性能就提升了几十倍。一行代码几十倍，数据听起来很夸张，不过这是真实的数据，线上错误的配置的确有可能导致性能有数量级上的差异，等我说完我们这个性能问题你就清楚了。

  我们线上是对接了腾讯云的IOT平台，任何iot设备的上传事件都是通过腾讯云的ckafka传递给我们的，随着设备量以及事件数据量的增加，我们消费腾讯云ckafka出现了性能瓶颈，数据高峰期会有数据拥堵，从而因数据处理延迟导致业务的问题。解决最简单的方案就是扩partition和consumer，实际上半年前我们发生性能问题的时候就是这么做的，扩了一倍的partition提升了一倍的性能，然而半年后的今天又到了瓶颈。

  经过排查发现，单条kafka消息处理需要6ms，拆分所有执行逻辑后发现这6ms的延迟主要是向腾讯云发送ack的时间，我们机房到腾讯云的rtt恰好就是6ms左右，所以几乎所有的事件都耗费在消息的网络传输上面了。然而这个是受物理距离所限制，无法减减少的。后来偶然发现我们在代码中使用了spring-kafka的AckMode中的MANUAL_IMMEDIATE，这个模式下kafka的consumer会向服务端手动确认每一条消息，后来我们将这个配置调整成了AckMode.MANUAL，单条消息的处理时长从原来的6ms降低到不到0.2ms，提升了30多倍，这下即便不扩容我们的性能冗余也足够支持很多年了。 为什么简简单单改个配置就会有如此的提升？ 是否还有其他的配置类型？

  实际上在spring-kafka中并不是只提供了MANUAL和MANUAL_IMMEDIATE两种ack模式，而是有以下七种，每种都有各种的作用和适合的场景。

• RECORD：每处理一条记录后就立即进行确认。
• BATCH：每次调用poll()方法后，只确认返回的最后一条记录。
• TIME：每次过了设定的时间间隔后，确认最后一条在这段时间内处理的记录。
• COUNT：每处理设定数量的记录后，确认最后一条处理的记录。
• COUNT_TIME：组合了TIME和COUNT，即满足任意一个条件时，确认最后一条处理的记录。
• MANUAL：用户需要手动调用acknowledgement.acknowledge()批量来确认消息。
• MANUAL_IMMEDIATE：用户需要手动调用acknowledgement.acknowledge()来确认消息，每条消息都会确认一次。

  以上7种模式如果分类的话可以分成2中，手动确认和自动确认，其中MANUAL和MANUAL_IMMEDIATE是手动确认，其余的都是自动确认。手动确认和自动确定的核心区别就在于你是否需要在代码中显示调用Acknowledgment.acknowledge()，我们挨个来看下。

手动确认

MANUAL：

  在此模式下，消费者需要在处理完消息后手动调用Acknowledgment.acknowledge()方法来确认消息。确认操作会被批量进行，即确认操作被延迟到一批消息都处理完毕后再发送给Kafka。这种模式的优点是可以提高效率，因为减少了与Kafka服务器的交互次数。但缺点是如果一批消息消费了一半，consumer突然异常宕机，因为数据没有及时向kafka服务端确认，下次就会重复拉取到消息，导致部分数据被重复消费。

MANUAL_IMMEDIATE：

  在此模式下，消费者需要在处理完消息后手动调用Acknowledgment.acknowledge()方法来确认消息。不过，与MANUAL模式不同的是，一旦调用了acknowledge()方法，确认信息会立即发送给Kafka，而不是等待一批消息都处理完毕后再发送。这种模式可能会增加与Kafka服务器的交互次数，在网络延迟较大的情况下会出现显著的性能消费瓶颈，但可以尽快将确认信息发送给Kafka，即便是consumer异常宕机，也只是会导致单条消息被重复消费。

  手动确认的优势在于consumer可以在代码逻辑中自行判断数据是否消费成功，未消费成功的数据不确认，这样可以保证数据不丢失，手动模式可以保证数据的完整性，也就是分布式数据系统中所说的at least once。而这两种模式的核心差异就是单条确认和批量确认，批量的方式可以显著提升性能， 我在上个月的博客IO密集型服务提升性能的三种方法详细介绍过，有兴趣可以看下。

自动确认

  RECORD、BATCH、TIME、COUNT、TIME_COUNT这5种都是属于自动确认，也就是你不需要在代码中显式调用Acknowledgment.acknowledge()，只要consumer拉到消息就是自动确认，才不管是否真的消费成功，所以自动确认的模式可能会导致数据丢失，但要注意相对于手动确认，自动确认即可能导致数据丢失，也可能导致数据重复，所以它也不是at most once语义级别的。 虽然同为自动确认，但其实这5种模式还有自己的差异。

RECORD和BATCH

  首先我们先来看下RECORD、BATCH，这两种模式其实就是上文中MANUAL和MANUAL_IMMEDIATE对应的自动版本。RECORD是一条就确认一次，同样如果是在网络延迟较大的情况下也会出现性能问题。BATCH是批量确认，每次poll()后会确认这一批的消息，同样的如果consumer异常宕机也会导致未成功确认消息，从而导致消息被重复拉取到。当然如果是consumer因其他原因导致数据处理失败，但正常确认了，这种情况下会丢失消息。

TIME

  TIME模式是定时确认，比如你设置了确认时间间隔为5S，consumer就会每5s向kafka确认这5s内消费完的消息，这里有个问题是如果是高频数据流且时间间隔设置较大，可能导致堆积大量消息未被确认，然后异常宕机后重复拉取到这些消息，我们接下来要说的COUNT模式可以避免这种情况。

COUNT

  COUNT模式确认的时机是由消费数据条数触发的，比如每消费100条就确认一次，完美的避免了堆积大量未确认数据的情况。但是，如果是极低频的数据流，比如几分钟才一条数据，攒够100条得好几个小时，数据消费后长时间得不到确认，甚至可能导致kafka认为数据消费超时失败，从而导致数据被重复消费。

TIME_COUNT

  针对于TIME和COUNT的优缺点，TIME_COUNT结合了两者的特点，只要是时间间隔或者消息条数满足其一就确认，具有更强的适应性，所以当你想从TIME、COUT、TIME_COUNT三者中选一个的话，我个人觉得可以盲选TIME_COUNT，除非你特别清楚你数据的特征，知道那种更合适。

总结

  简单总结下以上几种模式，如果是不能容忍数据丢失那一定要选手动模式，如果是网络延时比较高，可以选MANUAL(批处理)的模式，但是注意即便是手动模式它也不能保证数据不重复，要想做到完全幂等还得依赖其他的方式，比如数据库事务。 如果可以接受部分数据丢失(例：监控数据)，那就可以考虑自动模式了，但我个人还是不推荐RECORD模式，因为这种模式会在高网络延迟的情况下啊产生比较严重的性能问题，剩下的几种模式可以根据自己的数据量、网络情况选取，不同的情况用不同的模式可能会有明显的性能差异。