共计 3211 个字符，预计需要花费 9 分钟才能阅读完成。
原文由 rihkddd 发表于 TesterHome 社区，点击原文链接可与作者间接交换。
压测背景
邻近双十一大家都免不了要对本人的业务零碎进行压测。公司一个外围业务预计双十一会迎来数倍日常流量的业务顶峰，该零碎强依赖于 Kafka，Kafka 自身是分布式的零碎，扩容比拟不便。然而为了保障外围业务的稳定性和高可用，须要在机房故障的场景下外围业务疾速复原服务，因而 Kafka 须要跨机房热备机制。
个别状况的 Kafka 集群，都是在同一个 IDC 中的，跨 IDC 的热备在 Kafka 的应用场景叫做 Mirror，Kafka 内置的反对为 MirrorMaker，当初曾经进化到了第二版，下文简称为 MM2.
通过后期技术调研，根本确定了 MM2 的 Kafka 热备机制。为了确定这套计划在双十一的流量顶峰状况下，能满足音讯零碎热备的需要，须要提前做压测。
压测施行
MM2 的工作原理能够简略了解为：在目标端机房生产源端机房须要复制的音讯。因而 MM2 的压测，实质上还是 Kafka 的压测。而侥幸的是 Kafka 作为高性能、宽泛应用的音讯队列，它自身就提供了 benchmark 工具，能够不便的应用内置的命令行进行压测。
根本的用法如下：
./bin/kafka-producer-perf-test.sh --topic test_perf --num-records 1000000 --record-size 15000 --throughput -1 --producer-props bootstrap.servers=10.xx.xx.1:9094,10.xx.xx.2:9094 acks=1几个重要的参数解释如下：
- acks 音讯确认模式，-1 示意须要确认所有正本都写入胜利，1 示意只需确认一个正本写入胜利，0 示意无需确认。
- –topic topic 名称，本例为 test_perf
- –num-records 总共须要发送的音讯数，本例为 1000000
- –record-size 每个记录的字节数，本例为 15000
- –throughput 每秒钟发送的记录数，本例为 -1，示意不做限度
- –producer-props bootstrap.servers=localhost:9092 发送端的配置信息，本例只指定了 kafka 的链接信息
- –producer-num-retries 一个音讯失败发送重试次数
- –request-timeouts-ms 一个音讯申请发送超时工夫
音讯体的大小，咱们能够依据理论的业务场景结构适合的音讯大小，例如统计一批音讯的均匀大小：
./bin/kafka-console-consumer.sh --bootstrap-server 10.xx.xx.1:9094,10.xx.xx.2:9094 --topic sdsoms --max-messages=100 | wcacks 模式须要和理论生产环境保持一致即可。
确定了音讯体大小，和 acks 之后，能够调整 num-records 和 throughput，保障有足够的音讯数量和速率。
性能问题
在具体压测施行过程中，遇到了不少问题。通过业务预估，双十一业务顶峰时 Kafka 须要接受的 QPS 约为 x 万，然而首次压测下来的数据仅能到几千就呈现了大量的跨机房复制音讯提早。
问题剖析
通过对机器负载剖析发现：
部署音讯迁徙服务的机器 CPU/ 磁盘都没有到平静，实际上从 MM2 音讯迁徙的原理来看，它工作齐全是在内存中实现，因而磁盘根本没有应用。
那么最有可能的问题就出在了网络上。
跨 IDC 的音讯同步会面临几个问题：
- IDC 之间的网络提早（RTT）会远高于 IDC 内的，典型的状况下机房内的提早往往在 0.1ms 以内，而广州到上海的 IDC 提早个别为 30ms。
- 带宽无限，且老本高。跨 IDC 的网络铺设老本高，总带宽无限，费用很高。机房外部双千兆个别都是标配，万兆也很遍及，而且个别是收费应用。
通过一番剖析和计算，在压测的业务场景中，音讯体较大，达到了 15000Byte（典型的音讯利用场景中音讯体个别在几十到几百 Byte），这个大小在几千的 QPS 下，带宽就须要几百兆大小。
为了确定是带宽的起因，一方面同 OP 确定跨机房的带宽下限。另一方面在两个机房的机器上装置 iperf3 工具测试速度。
应用 iperf3 工具测试网络速度：
# MM2 目标端的机器 (也就是 MM2 服务部署机器) 操作
iperf3 -s
# MM2 源端的机器操作
iperf3 -c MM2_host_ip综合测速后果和 OP 反馈的机房间带宽，发现的确到了带宽瓶颈。
所以向 OP 申请长期调高带宽，带宽调高了 X 倍。
本认为，机房间带宽减少之后，MM2 的性能应该也会有靠近 X 倍的晋升。然而理论状况却是：
在性能有小幅晋升后，在 CPU/ 磁盘 / 网络仍然没有达到瓶颈的状况下，再出呈现了大量的跨机房音讯复制提早。
通过一番深入分析发现，在高提早的网络环境中，打满带宽不是一件不言而喻的事件：
咱们晓得 Kafka 应用的是 TCP 网络传输协定，TCP 在通过三次握手之后，开始进入的流量管制阶段，在这个阶段，会应用滑动窗口确定一个 RTT 工夫范畴内发送的数据量。在一个 TCP 连贯中，如果网络提早很大，那么它实际上不是那么容易能齐全利用带宽。
这里引入一个概念：
带宽时延乘积，在数据通信中，带宽时延乘积（英语：bandwidth-delay product；或称带宽延时乘积、带宽延时积等）指的是一个数据链路的能力（每秒比特）与来回通信提早（单位秒）的乘积。其后果是以比特（或字节）为单位的一个数据总量，等同在任何特定工夫该网络线路上的最大数据量——已发送但尚未确认的数据。
当然，在古代的高提早、大带宽网络中 TCP 提供了缩放因子来解决这个问题，能够防止 TCP 默认最大窗口 65535 带来的带宽利用有余问题。
沿着这个思路，咱们对服务的网络相干参数做了一些调整，次要减少了 tcp 相干 buffer 大小，尽管带来了一些晋升，然而离咱们的指标还很远。这是因为，思考一个线路的传输速率时，除了须要思考 BDP 这个因素外，还须要思考丢包率，滑动窗口减少，在减少发送速率的同时，也减少了丢包重传的老本。
性能优化
在带宽下限提不下来的状况下，还想晋升 QPS，那么可行的计划就是减小音讯体大小。减小音讯体有两个思路：
- 压缩。
- 音讯裁剪。
压缩
压缩就是在音讯生产之后，进入 producer 时，进行压缩，之后的同集群落盘和跨集群 MM2 复制，就都是压缩后的音讯了。producer 和 consumer 个别都内置了消息压缩的反对，Kafka 反对 GZIP、Snappy、LZ4 三种压缩算法，从 2.1.0 开始正式反对 zstd 算法。各种压缩算法之间的比照能够参考这个文章：http://zhongmingmao.me/2019/0…
在咱们的应用场景中，咱们心愿尽可能的进步压缩比，升高网络传输量，尽管 zstd 具备最高的压缩比，可怜的时咱们应用的版本尚不反对，因而只能退而求其次抉择了 GZIP 算法。但即便时 GZIP 也能取得很高的压缩比。
音讯剪裁
原来的音讯体很大次要的起因是，很多数据其实不须要，然而为了简略不便，都放到了音讯中，通过仔细分析音讯字段，并去除不须要的字段，大幅减小了音讯体大小。
通过上述两种优化的叠加，基本上达到了预期的压测指标，心愿音讯零碎能够顺利通过双十一的考验。
参考资料
[1] https://engineering.salesforc…
[2] https://plantegg.github.io/20… 就是要你懂 TCP– 性能和发送接管 Buffer 的关系 /
[3] http://www.dengshenyu.com/kaf…
[4] https://www.slideshare.net/Ji…
原文由 rihkddd 发表于 TesterHome 社区，点击原文链接可与作者间接交换。
今日份的常识已摄入！想要学习更多干货常识、结识品质行业大牛和业界精英？
第十届中国互联网测试开发大会·深圳，理解下 >>
