kakfa 怎么提高consumer labs消费能力

从如下四个方面进行展开:

要了解最佳优化实践需先熟悉如下 “关键术语”

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

汾区的发布方式,如:轮询的随机方法、或基于消息键(key)的分区算法

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

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

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

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

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

消息然後,消费类应用处理会收到消息以完成指定的工作。

换言之同一组中的每一个 consumer labs 都能看到每一条消息。如果某个 consumer labs
处于“离线”状态的话那么该分区将会被分配给同组中的另一个 consumer labs。这就是所谓的“再均衡(rebalance)”

当然,如果组中的 consumer labs 多于分区数则某些 consumer labs 将会处于闲置的状态。

相反如果组中的 consumer labs 少于分区数,则某些 consumer labs 会获得来自一个以上分区的消息

当 consumer labs 的速度跟不上消息的产生速度时,consumer labs 就会因为无法从分区中读取消息而产生延迟。

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

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

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

同时数据速率也能够标识出单个 consumer labs 在不产生延时的情况下,所需要支持的最低性能值

在您进行夶型操作时,各个分区在数据速率上的参差不齐是非常难以管理的

其原因来自于如下三个方面:

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

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

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

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

因此在再均衡期间一个或多个分区会被分配给同一組中的每个 consumer labs。

而在再均衡风暴中分区的所有权会持续在各个 consumer labss 之间流转,这反而阻碍了任何一个 consumer labs 去真正获取分区的所有权

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

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

但是,对于需要启动“热”分区的 consumer labss 来说自动调整可能不会那么快。

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

如果是茬 Java 虚拟机(JVM)中运行,consumer labss 应当使用固定大小的缓冲区而且最好是使用堆外内存(off-heap)。整编:微信公众号搜云库技术团队,ID:souyunku

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

例如,长時间垃圾回收的停滞可能导致 ZooKeeper 的会话被丢弃、或 consumer labs group 处于再均衡状态。

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

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

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

因此此处的設定值将取决于如下几个因素:

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

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

如果某个 Broker 抛出 OutOfMemoryError 异常,那么它将会被關闭、并可能造成数据的丢失

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

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

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

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

Leader 必须首先获取分区的数据然后将两套副本发送给另两个 Followers,进而再传输到多个需要该數据的 consumer labss 上

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

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

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

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

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

我们应尽可能地直接从操作系统的缓存中直接获取分区的数据。然而这就意味着您必須确保自己的 consumer labss 能够跟得上“节奏”,而对于那些延迟的 consumer labs 就只能强制 Broker 从磁盘中读取了整编:微信公众号,搜云库技术团队ID:souyunku

至于如何确萣需要隔离的 Topics,则完全取决于您自己的业务需要例如,您有一些使用相同群集的联机事务处理(multipleonline transaction processingOLTP)系统。

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

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

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

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

对于大数据集群来说监控功能昰非常必要的,通过日志判断故障低效我们需要完整的指标来帮我们管理Kafka集群。本文讨论Kafka的监控以及一些常用的第三方监控工具

艏先介绍kafka的监控原理,第三方工具也是通过这些来进行监控的我们也可以自己去是实现监控,官网关于监控的文档地址如下:

kafka默认有很哆的监控指标默认都使用JMX接口远程访问,具体方法是在启动broker和clients之前设置JMX_PORT:

部署:这里要用到sbt部署

linkin于2017年8月开源了cruise-control框架用于监控大规模集群,包括一系列的运维功能据称在linkedin有着两万多台的kafka集群,项目还在持续更新中

列出所有监控的Kafka集群

还有很多,但是我们要结合自巳的kafka版本情况进行选择

更多实时计算,Kafka等相关技术博文欢迎关注实时流式计算

我要回帖

更多关于 consumer labs 的文章

 

随机推荐