网站备案最快多久,自己做图片的网站链接,数据中台是什么意思,怎样制作免费的网站导语
本文主要介绍了 CKafka 在跨洋场景中遇到的一个地域间数据同步延时大的问题#xff0c;跨地域延时问题比较典型#xff0c;所以详细记录下来做个总结。
一. 背景
为了满足客户跨地域容灾、冷备的诉求#xff0c;消息队列 CKafka 通过连接器功能#xff0c;提供了跨…导语
本文主要介绍了 CKafka 在跨洋场景中遇到的一个地域间数据同步延时大的问题跨地域延时问题比较典型所以详细记录下来做个总结。
一. 背景
为了满足客户跨地域容灾、冷备的诉求消息队列 CKafka 通过连接器功能提供了跨地域数据同步的能力支持跨地域秒级准实时数据同步。
整体的架构图 如上图所示CKafka 跨地域数据同步能力底层基于 Kafka Connect 集群实现并通过Vpcgw Privatelink 打通云上环境。
数据同步主要流程如下
1. Connect 集群初始化 Connect Task每个 Task 会新建多个 Worker ConsumerClient具体多少取决于源实例的分区数从源 CKafka 实例拉取数据。
2. Connect 集群从源实例拉取数据后会启动 Producer 发送数据到目标 CKafka 实例。
在某个客户业务场景中客户希望通过跨地域同步能力把香港 CKafka 实例的数据同步到美东 CKafka 实例在使用过程中引发了一个跨地域延时的诡异问题
二. 问题现象
客户在使用跨地域同步能力的时候发现数据从香港-美东同步数据的延时非常大并且能明显的看到 Connect 作为 Consumer 去源实例香港消费拉取数据的消息堆积非常大。
消息堆积 根据过往的经验我们国内地域的同步不会出现这么大的延时为什么这次的跨地域会有这么大的延时呢
三. 问题分析
消息堆积常见的原因
Kafka 在生产消费过程中出现消息堆积常见的原因主要有以下几点
● Broker 集群负载过高包括 CPU 高、内存高、磁盘 IO 高导致消费吞吐慢。
● 消费者处理能力不足如果消费者的处理能力不足无法及时消费消息就会导致消息堆积。可以通过增加消费者的数量或者优化消费者的处理逻辑来解决该问题。
● 消费者异常退出如果消费者异常退出就会导致消息无法及时消费从而在 Broker 中积累大量未消费的消息。可以通过监控消费者的状态和健康状况及时发现并处理异常情况。
● 消费者提交偏移量失败如果消费者提交偏移量失败就会导致消息重复消费或者消息丢失从而在 Broker 中积累大量未消费的消息。可以通过优化消费者的偏移量提交逻辑或者使用 Kafka 的事务机制来保证偏移量的原子性和一致性。
● 网络故障或者 Broker 故障如果网络故障或者 Broker 故障就会导致消息无法及时传输或者存储从而在 Broker 中积累大量未消费的消息。可以通过优化网络的稳定性和可靠性或者增加 Broker 的数量和容错能力来解决该问题。
● 生产者发送消息速度过快如果生产者发送消息速度过快超过了消费者的处理能力就会导致消息堆积。可以通过调整生产者的发送速度或者增加消费者的数量来解决该问题。
基于以上原因我们首先排查了 Connect 集群所有节点和源目标 CKafka 实例所有节点的负载发现各项监控指标都很健康、集群负载很低ConnectConsumer 消费能力也没有出现异常和性能瓶颈。 但是单次拉取消息的速率却很低平均消费速度325KB/s这个是不符合预期的。 (注上图中的 bytes-consumed-rate 指标代表每秒消费的字节数)
既然集群负载没有问题于是我们进行了更深层的排查分析
第一阶段分析排查网络速率
消息延时大我们首先想到的就是网络问题所以立刻着手压测网络。通过 Iperf3 、Wget 探测网络速率。
Iperf3 压测速度在225Mbps 。
Wget 在 Connect 集群直连香港下载速度在20MB/s。 这两个测试说明在同样环境下网络传输速率并不低可以达到20MB/s。那既然网络带宽没问题问题又会出在哪呢
第二阶段分析内核调参数
网络没有问题那会不会是 Kafka 网络相关的应用程序参数、以及内核网络相关的参数设置的不合理呢
1、我们首先进行了内核调参跟网络相关的内核参数主要有
系统默认值
net.core.rmem_max212992
net.core.wmem_max212992
net.core.rmem_default212992
net.core.wmem_default212992
net.ipv4.tcp_rmem4096 87380 67108864
net.ipv4.tcp_wmem4096 65536 67108864---------------------------------------------------------
调整内核参数
sysctl -w net.core.rmem_max51200000
sysctl -w net.core.wmem_max51200000
sysctl -w net.core.rmem_default2097152
sysctl -w net.core.wmem_default2097152
sysctl -w net.ipv4.tcp_rmem40960 873800 671088640
sysctl -w net.ipv4.tcp_wmem40960 655360 671088640调整TCP的拥塞算法为bbr:
sysctl -w net.ipv4.tcp_congestion_controlbbr整体内核参数的值我们都调大了尽管我们认为系统内核默认值也不小同时我们还调整了TCP 的拥塞算法。
这里解释一下为什么要调整 TCP 的拥塞算法。
(参考资料[[译] [论文] BBR基于拥塞而非丢包的拥塞控制ACM, 2017]([译] [论文] BBR基于拥塞而非丢包的拥塞控制ACM, 2017))
因为这个延时发生在跨地域间且跨洋了使用 BBR可以获得显著的网络吞吐量的提升和延迟的降低。吞吐量的改善在远距离路径上尤为明显比如跨太平洋的文件或者大数据的传输尤其是在有轻微丢包的网络条件下。延迟的改善主要体现在最后一公里的路径上而这一路径经常受到缓冲膨胀Bufferbloat的影响。所谓“缓冲膨胀”指的是网络设备或者系统不必要地设计了过大的缓冲区。当网络链路拥塞时就会发生缓冲膨胀从而导致数据包在这些超大缓冲区中长时间排队。在先进先出队列系统中过大的缓冲区会导致更长的队列和更高的延迟并且不会提高网络吞吐量。由于 BBR 并不会试图填满缓冲区所以在避免缓冲区膨胀方面往往会有更好的表现。
经过内核参数调整后验证发现延时并没有很大的改善。 2、在云产品技术服务专家大佬的提醒下确认连接的 Receive Buffer 设置过小调内核参数才没有生效怀疑是应用层进行了设置。
于是我们调整了 Kafka 应用程序网络参数 Socket.Send.Buffer、Socket.Recevie.Buffer 的参数值
1把源目标 CKafka 实例 Broker 的 Socket.Send.Buffer.Bytes 参数从默认64KB调整为使用系统的 Socket Send Buffer。
Kafka 内核关于 Socket Send Buffer 的代码 【Tips】:
在 Kafka 中TCP 发送缓冲区的大小由应用程序和操作系统共同决定。应用程序可以通过设置 Socket.Send.Buffer.Bytes 参数来控制 TCP 发送缓冲区的大小操作系统也可以通过设置 TCP/IP 协议栈的参数来控制 TCP 发送缓冲区的大小。
应用程序设置的 Socket.Send.Buffer.Bytes 参数会影响 TCP 发送缓冲区的大小但是操作系统也会对 TCP 发送缓冲区的大小进行限制。如果应用程序设置的 Socket.Send.Buffer.Bytes 参数超过了操作系统的限制那么 TCP 发送缓冲区的大小就会被限制在操作系统的限制范围内。如果应用程序设置的 Socket.Send.Buffer.Bytes-1 那么 TCP 发送缓冲区的大小就会默认使用操作系统的 TCP 发送缓冲区的大小。需要注意的是TCP 发送缓冲区的大小会影响网络的吞吐量和延迟时间。如果 TCP 发送缓冲区的大小过小会导致网络的吞吐量和性能下降如果 TCP 发送缓冲区的大小过大会导致网络的延迟时间增加。因此需要根据实际情况进行调整以达到最优的性能和可靠性。
2把客户端 Connect Consumer 的 Receive.Buffer.Bytes 参数从默认64KB调整为使用系统的Socket Receive Buffer。把客户端 Max.Partition.Fetch.Bytes 这个分区最大拉取大小调整到了5MB。
调整后我们迅速和客户协调时间重启集群验证这个调参。调整完后的效果明显单连接的平均速度从300KB/s提升到了2MB/s以上 可以看到调大 Kafka 的 Socket 接收、发送参数后效果确实很明显同步数率上来了。当我们以为延时问题解决了的时候问题又出现了
第三阶段分析深挖根因
上面第二阶段的 Kafka 调参应用到客户集群观察一天后客户反馈集群整体延时有所好转但是部分分区延时还是很大。我们也观测到大概一半分区的同步速率依然很低。 (注上图中的 Bytes-Consumed-Rate 指标 代表每秒消费的字节数)
1为什么部分连接速度还是很低
我们首先通过运营后台确定了消费速率低的 Partition 对应的 ConsumerGroupID通过这个ConsumerGroupID 抓包定位对应的慢速 TCP 连接。
定位连接后进行抓包分析 从上可以看到 Server 发送一段数据之后会暂停一段时间大约一个 RTT 再继续发送。统计每个发送间隔之间的数据包的总大小大概64KB。这基本能说明 TCP 的发送窗口被限制在64KB。但是通过抓包其他速度正常的连接发现并没有这种限制。一般来说TCP 发送窗口的实际大小是跟 Window Scale 有关的这个只能在连接建立的时候确认。
【Tips】TCP Window Scale, TCP 的窗口缩放因子。(参考资料How to determine TCP initial window size and scaling option? Which factors affect the determination? - Red Hat Customer Portal)
在传统的 TCP 协议中TCP 窗口大小的最大值只能达到 64KB这限制了 TCP 协议的传输速度和效率。为了解决这个问题TCP Window Scale 机制被引入到 TCP 协议中。
TCP 窗口大小 (接收端窗口大小) * (2 ^ TCP Window Scale 选项的值)
需要注意的是TCP Window Scale 机制需要在 TCP 三次握手连接建立时进行协商以确定 TCP 窗口大小的扩展方式和参数。
为了抓取建连的情况我们尝试重启单个 Partition 的消费任务但是发现只要一重启消费的速度就能恢复窗口的大小就不会出现瓶颈。
2为什么发送窗口被限制
为了复现问题我们模拟构造了客户的使用场景进行了整体的场景复现。最终确认只有在任务全量重启的时候才会出现这个问题。 在任务重启过程中我们进行了服务端的整体抓包。定位到了正常连接和异常连接对比了建连的过程最终确认了慢速的连接中 Window Scale 确实没有生效
正常连接建连过程 慢速连接建连过程 从上图可以看出慢速连接中Server 在返回 Syn/Ack 包的时候没有WS2说明并没有开启 Window Scale 选项进而导致整个连接的发送窗口被限制在了64KB吞吐就上不去了。Client 返回最后一个 Ack 的时候也明确显示了no window scaling used。 3为什么Window Scale 概率性不生效
到这一步我们就需要解释为什么 Server 端发送 Syn/Ack 的时候会概率性地不开 Window Scale 呢 这里计算组大佬给出了一个相似的 Case 提供我们学习kubernetes - 深度复盘-重启 etcd 引发的异常 - 个人文章 - SegmentFault 思否 从中可以得到一个信息 看起来是 SYN Cookie 生效的情况下对方没有传递 Timestamp 选项过来实际上按照 SYN Cookie 的原理发送给对端的回包中会保存有编码进 Tsval 字段低 6 位的选项信息就会调用 Tcp_Clear_Options 清空窗口放大因子等选项。 我们从系统日志里面我们也能观察到在任务整体重启的时候确实触发了 SYN Flood。 4为什么服务端没收到 Tsval (TCP 的 Timestamp Value) 呢
上面有介绍过我们的数据同步时经过了公司内部的一个 VPCGW我们分别在 Client 和 Server 上分别抓包最终确认是 VPCGW 把 Client 发出的 Tsval 吞了。同时也跟 VPCGW 的研发同学确认在 NAT 环境下不转发 Timestamp 是预期行为主要为了解决特殊情况下的丢包问题NAT环境下tcp_timestamps问题_centos nat tcp_timestamps_清风徐来918的博客-CSDN博客。不过这个问题在新内核中已经不存在所以可以排期提供开放 Timestamp 的能力。
根因定位
一路分析深挖下来至此问题的根因就清晰了
Connect Consumer 批量启动触发了大量新建 TCP 连接短时间的大量新建连接触发了 SYN Cookie 保护检查逻辑。但是因为客户端没有发送 Timestamp 选项传过来造成了服务端把窗口放大因子清除最终造成连接的发送窗口最大64KB在大延迟的场景下影响了传输性能。
四. 我们的解决方案
问题的根因找到了解决方案就清晰明朗了。
● 规避方案我们调整了 Connect Woker 初始化的并发度降低 TCP 初始化建连的速度保证不会触发 SYN Cookie 来保证后续数据同步的性能。
● 最终方案推动 VPCGW 打开 TCP Timestamp 的能力。
五. 总结
问题表面是跨地域数据同步请求慢的问题但是一路深挖下来确实一个非常底层的网络问题。
这个问题的发生比较罕见因为这个问题发生的条件比较复杂主要是跨地域存在网络延时、同时大量的 TCP 建连、加上 VPCGW 路由传输过程中吃掉了 TCP Timestamp参数 叠加起来导致了这个问题。
我们面对问题需要保持敬畏之心深挖到底
