kafka丢弃数据_20条关于Kafka集群应对高吞吐量的避坑指南

Apache Kafka是一款流行的分布式数据流平台&＃xff0c;它已经广泛地被诸如New Relic(数据智能平台)、Uber、Square(移动支付公司)等大型公司用来构建可扩展的、高吞吐量的、高可靠的实时数据流系统。

例如&＃xff0c;在New Relic的生产环境中&＃xff0c;Kafka群集每秒能够处理超过1500万条消息&＃xff0c;而且其数据聚合率接近1Tbps。可见&＃xff0c;Kafka大幅简化了对于数据流的处理&＃xff0c;因此它也获得了众多应用开发人员和数据管理专家的青睐。

然而&＃xff0c;在大型系统中Kafka的应用会比较复杂。如果你的Consumers无法跟上数据流的话&＃xff0c;各种消息往往在未被查看之前就已经消失掉了。

同时&＃xff0c;它在自动化数据保留方面的限制&＃xff0c;高流量的发布&＃43;订阅(publish-subscribe&＃xff0c;pub/sub)模式等&＃xff0c;可能都会影响到系统的性能。可以毫不夸张地说&＃xff0c;如果那些存放着数据流的系统无法按需扩容、或稳定性不可靠的话&＃xff0c;估计大家经常会寝食难安。

为了减少上述复杂性&＃xff0c;我在此分享New Relic公司为Kafka集群在应对高吞吐量方面的20项最佳实践。

我将从如下四个方面进行展开&＃xff1a;

• Partitions(分区)

• Consumers(消费者)

• Producers(生产者)

• Brokers(代理)

一、快速了解Kafka的概念与架构

Kafka是一种高效的分布式消息系统。在性能上&＃xff0c;它具有内置的数据冗余度与弹性&＃xff0c;也具有高吞吐能力和可扩展性。

在功能上&＃xff0c;它支持自动化的数据保存限制&＃xff0c;能够以“流”的方式为应用提供数据转换&＃xff0c;以及按照“键-值(key-value)”的建模关系“压缩”数据流。

要了解各种最佳实践&＃xff0c;首先需要熟悉如下关键术语&＃xff1a;

Message(消息)

Kafka中的一条记录或数据单位。每条消息都有一个键和对应的一个值&＃xff0c;有时还会有可选的消息头。

Producer(生产者)

Producer将消息发布到Kafka的topics上。Producer决定向topic分区的发布方式&＃xff0c;如&＃xff1a;轮询的随机方法、或基于消息键(key)的分区算法。

Broker(代理)

Kafka以分布式系统或集群的方式运行&＃xff0c;那么群集中的每个节点称为一个Broker。

Topic(主题)

Topic是那些被发布的数据记录或消息的一种类别。消费者通过订阅Topic来读取写给它们的数据。

Topic Partition(主题分区)

不同的Topic被分为不同的分区&＃xff0c;而每一条消息都会被分配一个Offset&＃xff0c;通常每个分区都会被复制至少一到两次。

每个分区都有一个Leader和存放在各个Follower上的一到多个副本(即&＃xff1a;数据的副本)&＃xff0c;此法可防止某个Broker的失效。

群集中的所有Broker都可以作为Leader和Follower&＃xff0c;但是一个Broker最多只能有一个Topic Partition的副本。Leader可被用来进行所有的读写操作。

Offset(偏移量)

单个分区中的每一条消息都被分配一个Offset&＃xff0c;它是一个单调递增的整型数&＃xff0c;可用来作为分区中消息的唯一标识符。

Consumer(消费者)

Consumer通过订阅Topic partition&＃xff0c;来读取Kafka的各种Topic消息。然后&＃xff0c;消费类应用处理会收到消息&＃xff0c;以完成指定的工作。

Consumer group(消费组)

Consumer可以按照Consumer group进行逻辑划分。Topic Partition被均衡地分配给组中的所有Consumers。

因此&＃xff0c;在同一个Consumer group中&＃xff0c;所有的Consumer都以负载均衡的方式运作。

换言之&＃xff0c;同一组中的每一个Consumer都能群组看到分配给他的相应分区的所有消息。如果某个Consumer处于“离线”状态的话&＃xff0c;那么该分区将会被分配给同组中的另一个Consumer。这就是所谓的“再均衡(rebalance)”。

当然&＃xff0c;如果组中的Consumer多于分区数&＃xff0c;则某些Consumer将会处于闲置的状态。

相反&＃xff0c;如果组中的Consumer少于分区数&＃xff0c;则某些Consumer会获得来自一个以上分区的消息。

Lag(延迟)

当Consumer的速度跟不上消息的产生速度时&＃xff0c;Consumer就会因为无法从分区中读取消息&＃xff0c;而产生延迟。

延迟表示为分区头后面的Offset数量。从延迟状态(到“追赶上来”)恢复正常所需要的时间&＃xff0c;取决于Consumer每秒能够应对的消息速度。

其公式如下&＃xff1a;time&＃61;messages/(consume rate per second - produce rate per second)

1针对Partitions

1)了解分区的数据速率&＃xff0c;以确保提供合适的数据保存空间

此处所谓“分区的数据速率”是指数据的生成速率。换言之&＃xff0c;它是由“平均消息大小”乘以“每秒消息数”得出的数据速率决定了在给定时间内&＃xff0c;所能保证的数据保存空间的大小(以字节为单位)。

如果你不知道数据速率的话&＃xff0c;则无法正确地计算出满足基于给定时间跨度的数据&＃xff0c;所需要保存的空间大小。

同时&＃xff0c;数据速率也能够标识出单个Consumer在不产生延时的情况下&＃xff0c;所需要支持的最低性能值。

2)除非有其他架构上的需要&＃xff0c;否则在写Topic时请使用随机分区

在进行大型操作时&＃xff0c;各个分区在数据速率上的参差不齐是非常难以管理的。

其原因来自于如下三个方面&＃xff1a;

• 首先&＃xff0c;“热”(有较高吞吐量)分区上的Consumer势必会比同组中的其他Consumer处理更多的消息&＃xff0c;因此很可能会导致出现在处理上和网络上的瓶颈。

• 其次&＃xff0c;那些为具有最高数据速率的分区&＃xff0c;所配置的最大保留空间&＃xff0c;会导致Topic中其他分区的磁盘使用量也做相应地增长。

• 第三&＃xff0c;根据分区的Leader关系所实施的最佳均衡方案&＃xff0c;比简单地将Leader关系分散到所有Broker上&＃xff0c;要更为复杂。在同一Topic中&＃xff0c;“热”分区会“承载”10倍于其他分区的权重。

有关Topic Partition的使用&＃xff0c;可以参阅《Kafka Topic Partition的各种有效策略》

参考链接&＃xff1a;

https://blog.newrelic.com/engineering/effective-strategies-kafka-topic-partitioning/

2针对Consumers

3)如果Consumers运行的是比Kafka 0.10还要旧的版本&＃xff0c;那么请马上升级

在0.8.x版中&＃xff0c;Consumer使用Apache ZooKeeper来协调Consumer group&＃xff0c;而许多已知的Bug会导致其长期处于再均衡状态&＃xff0c;或是直接导致再均衡算法的失败(我们称之为“再均衡风暴”)。

因此在再均衡期间&＃xff0c;一个或多个分区会被分配给同一组中的每个Consumer。

而在再均衡风暴中&＃xff0c;分区的所有权会持续在各个Consumers之间流转&＃xff0c;这反而阻碍了任何一个Consumer去真正获取分区的所有权。

4)调优Consumer的套接字缓冲区(socket buffers)&＃xff0c;以应对数据的高速流入

在Kafka的0.10.x版本中&＃xff0c;参数receive.buffer.bytes的默认值为64KB。而在Kafka的0.8.x版本中&＃xff0c;参数socket.receive.buffer.bytes的默认值为100KB。

这两个默认值对于高吞吐量的环境而言都太小了&＃xff0c;特别是如果Broker和Consumer之间的网络带宽延迟积(bandwidth-delay product)大于局域网(local areanetwork&＃xff0c;LAN)时。

对于延迟为1毫秒或更多的高带宽的网络(如10Gbps或更高)&＃xff0c;请考虑将套接字缓冲区设置为8或16MB。

如果内存不足&＃xff0c;也至少考虑设置为1MB。当然&＃xff0c;也可以设置为-1&＃xff0c;它会让底层操作系统根据网络的实际情况&＃xff0c;去调整缓冲区的大小。

但是&＃xff0c;对于需要启动“热”分区的Consumers来说&＃xff0c;自动调整可能不会那么快。

5)设计具有高吞吐量的Consumers&＃xff0c;以便按需实施背压(back-pressure)

通常&＃xff0c;我们应该保证系统只去处理其能力范围内的数据&＃xff0c;而不要超负荷“消费”&＃xff0c;进而导致进程中断“挂起”&＃xff0c;或出现Consume group的溢出。

如果是在Java虚拟机(JVM)中运行&＃xff0c;Consumers应当使用固定大小的缓冲区&＃xff0c;而且最好是使用堆外内存(off-heap)。

请参见Disruptor模式&＃xff1a;

http://lmax-exchange.github.io/disruptor/files/Disruptor-1.0.pdf

固定大小的缓冲区能够阻止Consumer将过多的数据拉到堆栈上&＃xff0c;以至于JVM花费掉其所有的时间去执行垃圾回收&＃xff0c;进而无法履行其处理消息的本质工作。

6)在JVM上运行各种Consumers时&＃xff0c;请警惕垃圾回收对它们可能产生的影响

例如&＃xff0c;长时间垃圾回收的停滞&＃xff0c;可能导致ZooKeeper的会话被丢弃、或Consumer group处于再均衡状态。

对于Broker来说也如此&＃xff0c;如果垃圾回收停滞的时间太长&＃xff0c;则会产生集群掉线的风险。

3针对Producers

7)配置Producer&＃xff0c;以等待各种确认

籍此Producer能够获知消息是否真正被发送到了Broker的分区上。在Kafka的0.10.x版本上&＃xff0c;其设置是Acks&＃xff1b;而在0.8.x版本上&＃xff0c;则为request.required.acks。

Kafka通过复制&＃xff0c;来提供容错功能&＃xff0c;因此单个节点的故障、或分区Leader关系的更改不会影响到系统的可用性。

如果没有用Acks来配置Producer(或称“fireand forget”)的话&＃xff0c;则消息可能会悄然丢失。

8)为各个Producer配置Retries

其默认值为3&＃xff0c;当然是非常低的。不过&＃xff0c;正确的设定值取决于你的应用程序&＃xff0c;即&＃xff1a;就那些对于数据丢失零容忍的应用而言&＃xff0c;请考虑设置为Integer.MAX_VALUE(有效且最大)。

这样将能够应对Broker的Leader分区出现无法立刻响应Produce请求的情况。

9)为高吞吐量的Producer&＃xff0c;调优缓冲区的大小

特别是buffer.memory和batch.size(以字节为单位)。由于batch.size是按照分区设定的&＃xff0c;而Producer的性能和内存的使用量&＃xff0c;都可以与Topic中的分区数量相关联。

因此&＃xff0c;此处的设定值将取决于如下几个因素&＃xff1a;

• Producer数据速率(消息的大小和数量)&＃xff1b;

• 要生成的分区数&＃xff1b;

• 可用的内存量。

请记住&＃xff0c;将缓冲区调大并不总是好事&＃xff0c;如果Producer由于某种原因而失效了(例如&＃xff0c;某个Leader的响应速度比确认还要慢)&＃xff0c;那么在堆内内存(on-heap)中的缓冲的数据量越多&＃xff0c;其需要回收的垃圾也就越多。

10)检测应用程序&＃xff0c;以跟踪诸如生成的消息数、平均消息大小、以及已使用的消息数等指标

4针对Brokers

11)在各个Brokers上&＃xff0c;请压缩Topics所需的内存和CPU资源

日志压缩需要各个Broker上的堆栈(内存)和CPU周期都能成功地配合实现&＃xff0c;而如果让那些失败的日志压缩数据持续增长的话&＃xff0c;则会给Brokers分区带来风险。

请参见&＃xff1a;

https://kafka.apache.org/documentation/#compaction

你可以在Broker上调整log.cleaner.dedupe.buffer.size和log.cleaner.threads这两个参数&＃xff0c;但是请记住&＃xff0c;这两个值都会影响到各个Brokers上的堆栈使用。

如果某个Broker抛出OutOfMemoryError异常&＃xff0c;那么它将会被关闭、并可能造成数据的丢失。

而缓冲区的大小和线程的计数&＃xff0c;则取决于需要被清除的Topic Partition数量、以及这些分区中消息的数据速率与密钥的大小。

对于Kafka的0.10.2.1版本而言&＃xff0c;通过ERROR条目来监控日志清理程序的日志文件&＃xff0c;是检测其线程可能出现问题的最可靠方法。

12)通过网络吞吐量来监控Brokers

请监控发向(transmit&＃xff0c;TX)和收向(receive&＃xff0c;RX)的流量&＃xff0c;以及磁盘的I/O、磁盘的空间和CPU的使用率&＃xff0c;而且容量规划是维护群集整体性能的关键步骤。

13)在群集的各个Brokers之间分配分区的Leader关系

Leader通常会需要大量的网络I/O资源。例如&＃xff0c;当我们将复制因子(replication factor)配置为3、并运行起来时。

Leader必须首先获取分区的数据&＃xff0c;然后将两套副本发送给另两个Followers&＃xff0c;进而再传输到多个需要该数据的Consumers上。

因此在该例子中&＃xff0c;单个Leader所使用的网络I/O&＃xff0c;至少是Follower的四倍。而且&＃xff0c;Leader还可能需要对磁盘进行读操作&＃xff0c;而Follower只需进行写操作。

14)不要忽略监控Brokers的in-sync replica(ISR)shrinks、under-replicatedpartitions和unpreferred leaders

这些都是集群中潜在问题的迹象。例如&＃xff0c;单个分区频繁出现ISR收缩&＃xff0c;则暗示着该分区的数据速率超过了Leader的能力&＃xff0c;已无法为Consumer和其他副本线程提供服务了。

15)按需修改Apache Log4j的各种属性

详细内容可以参考&＃xff1a;

https://github.com/apache/kafka/blob/trunk/config/log4j.properties

Kafka的Broker日志记录会耗费大量的磁盘空间&＃xff0c;但是我们却不能完全关闭它。

因为有时在发生事故之后&＃xff0c;需要重建事件序列&＃xff0c;那么Broker日志就会是我们最好的、甚至是唯一的方法。

16)禁用Topic的自动创建&＃xff0c;或针对那些未被使用的Topics建立清除策略

例如&＃xff0c;在设定的x天内&＃xff0c;如果未出现新的消息&＃xff0c;你应该考虑该Topic是否已经失效&＃xff0c;并将其从群集中予以删除。此举可避免花时间去管理群集中被额外创建的元数据。

17)对于那些具有持续高吞吐量的Brokers&＃xff0c;请提供足够的内存&＃xff0c;以避免它们从磁盘子系统中进行读操作

我们应尽可能地直接从操作系统的缓存中直接获取分区的数据。然而&＃xff0c;这就意味着你必须确保自己的Consumers能够跟得上“节奏”&＃xff0c;而对于那些延迟的Consumer就只能强制Broker从磁盘中读取了。

18)对于具有高吞吐量服务级别目标(service level objectives&＃xff0c;SLOs)的大型群集&＃xff0c;请考虑为Brokers的子集隔离出不同的Topic

至于如何确定需要隔离的Topics&＃xff0c;则完全取决于自己的业务需要。例如&＃xff0c;你有一些使用相同群集的联机事务处理(multipleonline transaction processing&＃xff0c;OLTP)系统。

那么将每个系统的Topics隔离到不同Brokers子集中&＃xff0c;则能够有助于限制潜在事件的影响半径。

19)在旧的客户端上使用新的Topic消息格式。应当代替客户端&＃xff0c;在各个Brokers上加载额外的格式转换服务

当然&＃xff0c;最好还是要尽量避免这种情况的发生。

20)不要错误地认为在本地主机上测试好Broker&＃xff0c;就能代表生产环境中的真实性能了

要知道&＃xff0c;如果使用复制因子为1&＃xff0c;并在环回接口上对分区所做的测试&＃xff0c;是与大多数生产环境截然不同的。

在环回接口上网络延迟几乎可以被忽略的&＃xff0c;而在不涉及到复制的情况下&＃xff0c;接收Leader确认所需的时间则同样会出现巨大的差异。

二、总结

希望上述各项建议能够有助于大家更有效地去使用Kafka。如果你想提高自己在Kafka方面的专业知识&＃xff0c;请进一步查阅Kafka配套文档中的“操作”部分&＃xff0c;其中包含了有关操作群集等实用信息。

作者&＃xff1a;陈峻编译

来源&＃xff1a;51CTO技术栈(ID&＃xff1a;blog51cto)

dbaplus社群欢迎广大技术人员投稿&＃xff0c;投稿邮箱&＃xff1a;editor&＃64;dbaplus.cn

- 近期活动 -

2018 Gdevops全球敏捷运维峰会广州站

• 聚焦AIOps&＃xff1a;BAT、360、美图等名企大佬齐聚&＃xff0c;携最新智能运维实践亮相&＃xff1b;

• 运维多面观&＃xff1a;覆盖银行、证券等传统行业的DevOps、可视化、安全建设等&＃xff1b;

• 数据库专场&＃xff1a;腾讯、蚂蚁金服、美团点评、PingCAP、巨杉、润乾等一线专家畅谈数据库管理、优化与改造&＃xff1b;

• 沉浸式学习&＃xff1a;深度课程系统教学&＃xff0c;玩转DevOps工具栈&＃xff1b;

• 年度颁奖礼&＃xff1a;共同见证2018年度十大MVP、最佳产品奖的隆重揭晓&＃xff01;