Easysearch 新特性：写入限流功能介绍

作者：极限实验室

2024-07-17
北京
本文字数：1977 字
阅读完需：约 6 分钟

背景

在 Easysearch 的各种使用场景中，高写入吞吐量的场景占了很大一部分，由此也带来了一些使用上的问题，很多用户由于使用经验不足，对集群的写入压测进行的不够充分，不能很好的规划集群的写入量。

导致经常发生以下问题：

写入吞吐量过大对内存影响巨大，引发节点 OOM，节点掉线问题。
对 CPU 和内存的占用严重影响了其他的查询业务的响应。
以及磁盘 IO 负载增加，挤占集群的网络带宽等问题。

之前就有某金融保险类客户遇到了因业务端写入量突然猛增导致数据节点不停的 Full GC，进而掉入了不停的掉线，上线，又掉线的恶性循环中。当时只能建议用户增加一个类似“挡板”的服务，在数据进入到集群之前进行拦截，对客户端写入进行干预限流：

这样做虽然有效，但是也增加了整个系统的部署复杂性，提高了运维成本。

根据客户的实际场景，Easysearch 从 1.8.0 版本开始引入了节点和 Shard 级别的限流功能，不用依赖第三方就可以限制写入压力，并在 1.8.2 版本增加了索引级别的写入限流。注意：所有写入限流都是针对各数据节点的 Primary Shard 写入进行限流的，算上副本的话吞吐量要乘以 2。

限流示意图：

下面是限流前后相同数据节点的吞吐量和 CPU 对比：

测试环境：

ip       name   http          port version role master10.0.0.3 node-3 10.0.0.3:9209 9303 1.8.0   dimr -10.0.0.3 node-4 10.0.0.3:9210 9304 1.8.0   im   -10.0.0.3 node-2 10.0.0.3:9208 9302 1.8.0   dimr -10.0.0.3 node-1 10.0.0.3:9207 9301 1.8.0   dimr *

复制代码

测试索引配置：

PUT test_0{  "settings": {    "number_of_replicas": 1,    "number_of_shards": 3  }}

复制代码

压测工具：采用极限科技的 INFINI Loadgen 压测，这款压测工具使用简单，可以方便对任何支持 Rest 接口的库进行压测。

压测命令：

 ./loadgen-linux-amd64 -d 180 -c 10 -config loadgen-easy-1.8.yml

复制代码

压测 180 秒，10 个并发，每个 bulk 请求 5000 条。

节点级别限流

通过 INFINI Console 监控指标可以看到，限流之前的某个数据节点，CPU 占用 10%，每秒写入 40000 条左右：

在 Cluster Settings 里配置，启用节点级别限流，限制每个节点的每秒最大写入 10000 条，并在默认的 1 秒间隔内进行重试，超过默认间隔后直接拒绝。

PUT _cluster/settings{  "transient": {    "cluster.throttle.node.write": true,    "cluster.throttle.node.write.max_requests": 10000,    "cluster.throttle.node.write.action": "retry"  }}

复制代码

限流后，CPU 占用降低了约 50%，算上副本一共 20000 条每秒：

Shard 级别限流

设置每个分片最大写入条数为 2000 条每秒

PUT _cluster/settings{  "transient": {    "cluster.throttle.shard.write": true,    "cluster.throttle.shard.write.max_requests": 2000,    "cluster.throttle.shard.write.action": "retry"  }}

复制代码

集群级别的监控，同样是只针对主 Shard。

从 Console 的监控指标可以看出，索引 test_0 的 Primary indexing 维持在 6000 左右，正好是 3 个主分片限制的 2000 的写入之和。

再看下数据节点监控，Total Shards 表示主分片和副本分片的写入总和即 4000，单看主分片的话，正好是 2000.

索引级别限流

有时，集群中可能某个索引的写入吞吐过大而影响了其他业务，也可以针对特定的索引配置写入限制。可以在索引的 Settings 里设置当前索引每秒写入最大条数为 6000：

PUT test_0{  "settings": {    "number_of_replicas": 1,    "number_of_shards": 3,    "index.throttle.write.max_requests": 6000,    "index.throttle.write.action": "retry",    "index.throttle.write.enable": true  }}

复制代码

下图索引的 Primary indexing 在 6000 左右，表示索引的所有主分片的写入速度限制在了 6000。

总结

通过本次测试对比，可以看出限流的好处：

有效控制写入压力：写入限流功能能够有效限制每个节点和每个 Shard 的写入吞吐量，防止因写入量过大而导致系统资源被过度消耗的问题。
降低系统资源占用：在限流前，某数据节点的 CPU 占用率约为 10%。限流后，CPU 占用率显著降低至约 5%，减少了约 50%。这表明在高并发写入场景下，写入限流功能显著降低了系统的 CPU 负载。
提高系统稳定性：通过控制写入吞吐量，避免了频繁的 Full GC 和节点掉线问题，从而提升了系统的整体稳定性和可靠性。
保障查询业务性能：写入限流功能减少了写入操作对 CPU 和内存的占用，确保其他查询业务的响应性能不受影响。

综上所述，写入限流功能在高并发写入场景下表现出色，不仅有效控制了写入压力，还显著降低了系统资源占用，从而提高了系统的稳定性和查询业务的性能。