网站制作需要的材料,iis两个网站做ssl,蓝牙app开发软件,书画院网站建设01 引言
单分区写入在一些需要全局顺序消息的场景中具备重要应用价值。在一些严格保序场景下#xff0c;需要将分区数设置为 1#xff0c;并且只用单个生产者来发送数据#xff0c;从而确保消费者可以按照原始顺序读取所有数据。此时#xff0c;Kafka 的单分区写入性能将会…01 引言
单分区写入在一些需要全局顺序消息的场景中具备重要应用价值。在一些严格保序场景下需要将分区数设置为 1并且只用单个生产者来发送数据从而确保消费者可以按照原始顺序读取所有数据。此时Kafka 的单分区写入性能将会决定整个系统的吞吐上限。在我们的实践中发现Kafka 由于其本身线程模型实现上的制约并没有将单分区写入性能的极限发挥出来。本文今天将具体解读 Kafka 线程模型的不足以及 AutoMQ 如何对其进行改进优化从而实现更好的单分区写入性能。
02 Apache Kafka 串行处理模型解析
Apache Kafka 的串行处理模型网络框架主要由 5 个类组成
1. SocketServer网络框架的核心类包含 Acceptor 和 Processor 部分
Acceptor监听端口处理新建连接请求并将连接分发给 ProcessorProcessor网络线程通过num.network.threads 配置数量。单个 TCP 连接有且只有一个 Processor 负责Processor#run 方法驱动连接后续的生命周期管理从网络解析请求和将响应写入到网络
2. KafkaChannel单个 TCP 连接的抽象维护了连接的状态信息被Processor持有
3. RequestChannelProcessor 从网络解析完请求后将请求放到到单队列 RequestChannel 中再由 KafkaRequestHandler 拉走多线程并发处理
4. KafkaRequestHandler业务逻辑处理 / IO 线程通过 num.io.threads配置数量从 RequestChannel 获取到请求后调用 KafkaApis 进行业务逻辑处理
5. KafkaApis具体的业务逻辑处理类会根据请求类型分发到不同的处理方法网络框架核心类和类之间的交互对应到 Apache Kafka 的线程模型如下图 可以看到 Kafka 的线程模型和我们使用 Netty 开发的服务端程序类似
ꔷ kafka-socket-listener 对应到 Boss EventLoopGroup负责接受客户端连接。当一个新的连接到来时Boss EventLoopGroup 会接受连接并将接受的连接注册到 Worker EventLoopGroup
ꔷ kafka-network-thread 对应到 Worker EventLoopGroup处理连接的所有 I/O 事件包括读取数据写入数据以及处理连接的生命周期事件
ꔷ kafka-request-handler为了防止业务逻辑阻塞网络线程通常会将业务逻辑剥离到单独的线程池异步执行
那为什么称 Apache Kafka 是串行处理模型呢这就和它的 KafkaChannel mute 状态机有关了状态机如下图所示 ꔷ 接收请求当 Processor 从网络里解析出一个完整的请求首先会将请求添加到 RequestChannel 中然后调用 #mute 方法将 KafkaChannel 从 NOT_MUTE 状态变成 MUTE 状态并且发送 REQUEST_RECEIVED 事件将状态变更为 MUTE_AND_RESPONSE_PENDING 状态。注意直到这个请求收到对应的响应之前Processor 都不会再尝试 NOT_MUTE 状态的连接里面读取更多的请求Processor#processCompletedReceives
ꔷ 返回响应当 KafkaApis 将请求处理完毕将响应返回给 KafkaChannel首先发送 RESPONSE_SENT 事件将状态从MUTE_AND_RESPONSE_PENDING 变更为 MUTE 状态然后再调用 #unmute 方法将状态变更为 NOT_MUTE这时候 Processor 才会从该连接里面解析更多的请求Processor#processNewResponses
ꔷ Qutota 限制Quota 限制导致的流控流程就不在本文提及了感兴趣的小伙伴可以深入研究一下 Processor 类
Apache Kafka 通过 KafkaChannel 的状态机可以保障对于单个连接这个连接有且只有一个请求在被处理等上个请求处理完成响应后才会继续处理下一个请求。这也是为什么称 Apache Kafka 是串行处理模型。
在消息生产请求场景假设一个 1MB 消息生产请求的网络解析、校验定序和持久化ISR 同步/ 刷盘总共需要 5ms那么一个连接的处理能力上限为 200 请求/每秒单生产者单分区的吞吐上限也就为 200MB/s。
以下图为例即使客户端设置 max.in.flight.requests.per.connection 5MSG1 MSG4 “同时” 到达服务端MSG4 也要等待前面 3 个请求都处理完成响应后才能开始处理最终 MSG4 的发送耗时为 4T。 既然串行处理模型不是那么高效为什么 Apache Kafka 要这么设计
其中一个核心的原因通过串行处理模型Apache Kafka 能够较为简单就可以实现单连接请求处理的顺序性。例如在事务中发送多条消息的时候消息会携带序列号来标识顺序Broker 会检验持久化消息前会检查请求的序列号是否是依次递增的如果不是依次递增的话则返回 OUT_OF_ORDER_SEQUENCE_NUMBER 错误。如果从网络中解析完后并行处理这些请求就可能导致消息乱序问题。
03 AutoMQ 流水线处理模型
那么有没有既能保证请求处理的顺序性又能高效的方式呢
首先来看顺序性Apache Kafka 的顺序性要求体现在 3 个阶段
1. 网络解析Kafka 协议是基于 TCP 协议的那么网络解析必然是顺序 串行的从网络中读取完上个请求的数据才能读取下一个请求
2. 校验 定序单连接的请求必须要顺序的进行校验 定序要不然就会出现消息乱序问题
3. 持久化消息存储在磁盘的顺序必须和消息发送的顺序保持一致
顺序性总结出来等价于网络解析串行处理、校验 定序串行处理和保序持久化。聪明的读者会发现“3 个阶段内串行处理”并不等价于“3 个阶段间串行处理”。
那么高效的秘诀就在于如何将这 3 个阶段间进行并行化加速。
因此 AutoMQ 参照 CPU 的流水线将 Kafka 的处理模型优化成流水线模式兼顾了顺序性和高效两方面
1. 顺序性TCP 连接与线程绑定对于同一个 TCP 连接有且只有一个网络线程在解析请求并且有且只有一个 RequestHandler 线程在进行业务逻辑处理
2. 高效
不同阶段流水线化网络线程解析完 MSG1 后就可以立马解析 MSG2无需等待 MSG1 持久化完成。同理 RequestHandler 对 MSG1 进行完校验 定序后立马就可以开始处理 MSG2 同时为了进一步提高持久化的效率AutoMQ 还会将数据攒批进行刷盘持久化
在相同的场景下原来 Apache Kafka 完成 4 批消息的处理耗时需要 4T在 AutoMQ 的流水线处理模型下处理耗时缩短到 1.x T。 接下来再来从实现层面探索一下 AutoMQ 是如何实现流水线处理模型的。
首先是 KafkaChannel 的 mute 状态机做了简化状态机只保留了两个状态 MUTE 和 NOT_MUTE。相比原来收到请求后不再 #mute 对应的连接不再全链路串行处理请求这样就可以充分利用网络解析层的能力“源源不断”的从连接中解析新的请求。同时为了支持 Quota 能力和防止过载场景过多 Inflight 的请求导致内存 OOM新增了 Flag 来标记当前 MUTE 状态的原因有且仅有 Flag 被清空时连接才会变回 NOT_MUTE 可读状态。 优化完网络层处理效率的问题再来看看 3 阶段并行化后在业务逻辑层如何做到顺序处理。AutoMQ 将 RequestChannel 进行了多队列改造
ꔷ 队列和 KafkaRequestHandler 一一映射数量保持一致
ꔷ Processor 解析完请求后根据 hash(channelId) % N 来决定路由到特定的队列通过多队列模式可以做到对于相同连接的请求都被放入相同一个队列并且只被特定的 KafkaRequestHandler 进行业务逻辑处理保障了检验 定序阶段内部的顺序处理。 同时为了进一步提高持久化的效率AutoMQ 还会将数据攒批进行刷盘持久化
ꔷ 在处理消息生产请求时KafkaRequestHandler 在进行校验定序后无需等待数据持久化即可继续处理下一个请求提高了业务逻辑处理线程的利用率
ꔷ AutoMQ 后台存储线程会根据攒批大小和攒批时间触发刷盘并且持久化成功后再异步返回给网络层响应提升了持久化的效率
04 优化效果测试
4.1 测试环境准备
为了确保选择合适的 ECS 和 EBS 规格保证计算和存储本身不会成为瓶颈本次测试选择了如下的机型和云盘
ꔷ r6i.8xlarge32C256G、EBS 吞吐基线 1250 MB/s
ꔷ 系统盘 EBS 卷5000 IOPS、吞吐基线 1000 MB/sBroker 配置采用log.flush.interval.messages1 在硬件规格相同得情况下通过强制刷盘模拟 Apache Kafka ISR 多 AZ 副本同步延迟同时对齐 Apache Kafka 和 AutoMQ 的持久化等级
测试使用的 Kafka 和 AutoMQ 版本如下
ꔷ AutoMQ1.1.0 https://github.com/AutoMQ/automq/releases/tag/1.1.0-rc0
ꔷ Apache Kafka3.7.0 https://downloads.apache.org/kafka/3.7.0/kafka\_2.13-3.7.0.tgz
4.2 压测脚本
使用 Kafka 自带的工具脚本模拟测试负载
# 压测目标吞吐 350MB/s
bin/kafka-producer-perf-test.sh --topic perf --num-records480000 --throughput 6000 --record-size 65536 --producer-props bootstrap.serverslocalhost:9092 batch.size1048576 linger.ms1# 压测目标吞吐 150 MB/s
bin/kafka-producer-perf-test.sh --topic perf --num-records480000 --throughput 2400 --record-size 65536 --producer-props bootstrap.serverslocalhost:9092 batch.size1048576 linger.ms1
4.3 测试结果分析
单生产者单分区极限吞吐性能测试对比如下。从测试的结果列表中我们可以看到
ꔷ AutoMQ 的极限吞吐是 Apache Kafka 的 2 倍达到了 350MB/s
ꔷ AutoMQ 在极限吞吐下的 P99 延时是 Apache Kafka 的 1 / 15仅为 11ms 05 结语
AutoMQ 通过网络处理模型的优化将 Apache Kafka 的串行处理模型优化成了流水线处理模型使得单分区的写入性能获得了成倍的性能提升从而让单分区全局顺序消息可以满足更多场景的性能要求。尽管 AutoMQ 通过流水线处理模型极大得提升了极限吞吐和降低了延迟但仍旧建议业务尽可能找到合理的数据分区的方式避免单生产者单分区的场景并且尽可能避免分区热点。单分区的能力始终是有上限的一味的堆高单分区的吞吐不仅集群弹性粒度变大导致弹性的经济性下降而且单分区高吞吐对下游的消费者的无法横向扩展的单机处理性能也提出了挑战。
关于我们
我们是来自 Apache RocketMQ 和 Linux LVS 项目的核心团队曾经见证并应对过消息队列基础设施在大型互联网公司和云计算公司的挑战。现在我们基于对象存储优先、存算分离、多云原生等技术理念重新设计并实现了 Apache Kafka 和 Apache RocketMQ带来高达 10 倍的成本优势和百倍的弹性效率提升。 GitHub 地址https://github.com/AutoMQ/automq 官网https://www.automq.com B站AutoMQ官方账号 视频号AutoMQ
