网站开发形式选择,自学网站建设看什么书,烟台服装定制,大邑县建设银行网站调优目标 在做调优之前#xff0c;我们必须明确优化 Kafka 的目标是什么。通常来说#xff0c;调优是为了满足系统 常见的非功能性需求。在众多的非功能性需求中#xff0c;性能绝对是我们最关心的那一个。不同的 系统对性能有不同的诉求#xff0c;比如对于数据库用户而言…调优目标 在做调优之前我们必须明确优化 Kafka 的目标是什么。通常来说调优是为了满足系统 常见的非功能性需求。在众多的非功能性需求中性能绝对是我们最关心的那一个。不同的 系统对性能有不同的诉求比如对于数据库用户而言性能意味着请求的响应时间用户总 是希望查询或更新请求能够被更快地处理完并返回。
对 Kafka 而言性能一般是指吞吐量和延时。 吞吐量也就是 TPS是指 Broker 端进程或 Client 端应用程序每秒能处理的字节数或消 息数这个值自然是越大越好。 延时和我们刚才说的响应时间类似它表示从 Producer 端发送消息到 Broker 端持久化完 成之间的时间间隔。这个指标也可以代表端到端的延时End-to-EndE2E也就是从 Producer 发送消息到 Consumer 成功消费该消息的总时长。和 TPS 相反我们通常希望 延时越短越好。 总之高吞吐量、低延时是我们调优 Kafka 集群的主要目标一会儿我们会详细讨论如何 达成这些目标。在此之前我想先谈一谈优化漏斗的问题 调优吞吐量 首先是调优吞吐量。很多人对吞吐量和延时之间的关系似乎有些误解。比如有这样一种提法 还挺流行的假设 Kafka 每发送一条消息需要花费 2ms那么延时就是 2ms。显然吞吐 量就应该是 500 条 / 秒因为 1 秒可以发送 1 / 0.002 500 条消息。因此吞吐量和延 时的关系可以用公式来表示TPS 1000 / Latency(ms)。但实际上吞吐量和延时的关 系远不是这么简单。 我们以 Kafka Producer 为例。假设它以 2ms 的延时来发送消息如果每次只是发送一条 消息那么 TPS 自然就是 500 条 / 秒。但如果 Producer 不是每次发送一条消息而是在 发送前等待一段时间然后统一发送 一批 消息比如 Producer 每次发送前先等待 8ms 8ms 之后Producer 共缓存了 1000 条消息此时总延时就累加到 10ms即 2ms 8ms了而 TPS 等于 1000 / 0.01 100,000 条 / 秒。由此可见虽然延时增加了 4 倍但 TPS 却增加了将近 200 倍。这其实也是批次化batching或微批次化micro batching目前会很流行的原因。 在实际环境中用户似乎总是愿意用较小的延时增加的代价去换取 TPS 的显著提升。毕 竟从 2ms 到 10ms 的延时增加通常是可以忍受的。事实上Kafka Producer 就是采取 了这样的设计思想。 当然你可能会问发送一条消息需要 2ms那么等待 8ms 就能累积 1000 条消息吗答 案是可以的Producer 累积消息时一般仅仅是将消息发送到内存中的缓冲区而发送消 息却需要涉及网络 I/O 传输。内存操作和 I/O 操作的时间量级是不同的前者通常是几百 纳秒级别而后者则是从毫秒到秒级别不等因此Producer 等待 8ms 积攒出的消息 数可能远远多于同等时间内 Producer 能够发送的消息数。 推荐阅读 Spring中观察者模式的应用-CSDN博客 180Wtps超高并发、大流量生产案例 字节钱包 架构与落地方案
