关于后端:高效稳定的通用增量-Checkpoint-详解之二性能分析评估

作者：雷颜菲、夏瑞、俞航翔、梅源 |阿里云 Flink 存储引擎团队

摘要：咱们在“Flink 1.15 新性能架构解析：高效稳固的通用增量 Checkpoint”【1】一文介绍了通用增量 Checkpoint 的原理和背地的思考以及执行性能、空间放大等方面的初步测试后果。该性能在 Flink 1.16 中通过优化，已达到生产可用状态。本文将从实践和试验两个局部具体阐述通用增量 Checkpoint 的收益与开销，并剖析其实用场景。

在进行具体的性能剖析之前，咱们简略回顾一下通用增量 Checkpoint 的设计思考。Flink Checkpoint 过程包含同步刷盘和异步上传文件两个局部，一个算子的 Checkpoint 须要算子的所有并发实现异步过程并确认胜利后才算实现。因而，在大规模作业中，Checkpoint 异步耗时通常是影响 Checkpoint 稳定性和提早的瓶颈点。异步上传文件耗时局部有两个不确定性因素：

异步上传的文件大小依赖于状态存储的具体实现

异步过程须要等到同步过程完结能力开始

第一个问题，以 RocksDB 为例，尽管 Flink 对 RocksDB 也反对增量 Checkpoint，然而异步上传文件的数据量会受到 RocksDB Compaction 影响，因为在 Compaction 产生后可能会导致大量绝对较大的新文件须要从新上传。目前，RocksDB Compaction 触发不具备确定性，大规模作业在每次 Checkpoint 时，会经常出现局部节点异步耗时过长而影响 Checkpoint 的实现速度。

第二个问题，是因为在原先的 Checkpoint 架构下，同步快照完结前是没法筹备好须要上传的文件的，因而异步过程须要等到同步过程完结后能力开始。这种状况下，两个 Checkpoint 距离之间很大一部分工夫占比就被节约了。如果须要上传的状态比拟大，会在很短时间内对 CPU 和网络产生较大的压力。

通用增量 Checkpoint 通过引入 State Changelog（状态变动日志）实现了在架构上 Checkpoint 执行过程与状态存储快照的解耦，很好的解决了上述两个问题。在新架构下，状态更新不仅会更新状态表，而且会记录状态的变动日志。状态表会周期性长久化到远端存储，称为物化过程（Materialization）。这个过长通常周期比拟长（比方 10 分钟），并独立于 Flink 引擎的 Checkpoint 过程。另一方面，状态的变动日志也会继续上传到远端长久存储，并且在执行 Checkpoint 时 Flush 残余全副日志【1】。

这样的设计就比拟好的解决了后面提到的两个问题：通过将 Checkpoint 过程和物化过程解耦，能够让异步上传的文件大小变得稳固；同时因为状态变动更新是继续的，所以咱们能够在触发 Checkpoint 之前就始终继续的上传增量的更新日志，所以在 Flush 当前咱们理论须要上传的数据量就变得很小。

因而，应用通用增量 Checkpoint 能够 更稳固疾速地实现 Checkpoint；从而达到更稳固更低的端到端提早、更少的数据回追和更安稳的资源耗费；与此同时在开销方面，通用增量 Checkpoint 带来的极限性能降落简直能够疏忽，所带来的额定资源耗费也是可预估并且可控的。本文将从这几个方面详细分析通用增量 Checkpoint 的劣势和代价，并分享相应的试验论断。

端到端提早是 Flink 流解决零碎十分重要的性能指标。端到端提早是指开始解决输出数据到输入该数据产生的后果所需的工夫，而更低的端到端提早则意味着上游零碎能够更快的失去更新后果。Flink 基于 Checkpoint 机制能够提供 Exactly-once 语义保障，当 Source 反对重放、Sink 反对事务后，能够进一步提供端到端的 Exactly-once 语义保障。如图 1 所示，Checkpoint 实现后，事务型 Sink 才能够更新提交位点。因而，Checkpoint 执行的速度越快、距离越短，事务型 Sink 就能够更频繁地提交，从而为作业提供更低的端到端提早。

图 1：事务型 Sink 的端到端提早示意图

通用增量 Checkpoint 能够带来更稳固更低的端到端提早。如前所述，通用增量 Checkpoint 机制通过将状态存储快照与 Flink 引擎 Checkpoint 执行过程解耦，能够解决不同状态存储实现（例如 RocksDB Compaction）在 Checkpoint 期间异步状态上传量对 Checkpoint 异步耗时的影响。同时因为能够继续上传 State Changelog，极大升高了 Checkpoint 触发后须要上传的数据量，Checkpoint 触发后只须要上传大量增量日志即可，从而大幅晋升了 Checkpoint 实现的稳定性和速度，升高作业端到端提早，并且让提早稳固在肯定范畴内。

在没有应用 Exactly-once Sink 的状况下，数据回追会导致反复输入。如果上游不反对齐全去重，会在肯定水平上影响数据正确性。因而，如何保障流计算零碎在故障复原后回追更少的数据，尽快恢复到故障前的状态是流计算零碎设计须要思考的问题。Flink 在从故障复原时，首先会定位到最新的残缺可用的 Checkpoint，每个算子节点基于这个 Checkpoint 重建本地状态后，从该 Checkpoint 保留的输出位点开始回追数据。须要回追的数据越少，数据反复输入也少，复原也越快。

图 2：以 RocksDB 状态存储为例，作业失败后，数据回追示意图（Checkpoint 简写为 CHK）。

通用增量 Checkpoint 能够缩小作业复原时的重放数据量。如图 2 所示，数据回追量是作业失败工夫点到最近一次 Checkpoint 位点的数据量。因为通用增量 Checkpoint 能够放慢 Checkpoint 的实现速度，因而能够将 Checkpoint 做得更高频，须要回追的数据也会变得更少，缩小数据反复输入，放慢复原。这对于对数据反复度有较高要求的业务来说是很要害的晋升。

Flink 快照过程会引起 Flink 作业 CPU 和网络资源应用呈现尖刺，这点对资源量耗费多的大状态作业尤为显著。咱们仍以 RocksDB 作为状态存储为例，Flink Checkpoint 过程会间接地触发 RocksDB Compaction 的执行条件，使 CPU 使用量在短时间内激增，造成尖刺（Compaction 是 RocksDB 状态存储次要的 CPU 耗费起源之一）。另外，Checkpoint 触发快照制作之后，作业中全副算子并发的状态存储会集中在这个时间段外向远端存储上传数据，导致网络资源使用量在短时间内也呈现激增，很容易达到网络带宽下限。如图 3 所示，Checkpoint 触发之后，所有算子中的 RocksDB 状态存储简直同时向远端存储上传状态。对于大状态作业来说，CPU 尖刺会使得资源预留估算和理论应用呈现较大偏差，影响作业失常运行。尽管当初集群部署都采纳容器化，但出于资源利用率的思考，很多资源还是会共享的（比方 CPU 和网络），因而 CPU 和网络尖刺会影响集群内其余作业的失常运行，进一步影响整个集群的稳定性。

图 3：RocksDB 增量 Checkpoint 的 RocksDB 状态存储上传过程

通用增量 Checkpoint 能够无效升高作业的 CPU 和网络流量的耗费，晋升 Checkpoint 稳定性，平滑集群 CPU 和网络资源应用。一方面，通用增量 Checkpoint 通过将增量状态变动日志（State Changelog）继续上传到远端长久化存储，能够将网络流量的耗费均摊在整个 Checkpoint 过程中；另一方面 Checkpoint 过程与存储后端快照过程解耦能够使得 RocksDB 低频、错峰执行物化过程，解决 RocksDB 频繁执行 Compaction 操作和集中向远端存储上传数据的问题，从而升高 CPU 和网络资源使用量和波动性。如图 4 所示，不同算子的 RocksDB 文件上传过程平均打散到物化距离内，使得 RocksDB 的物化过程能够低频、错峰。

图 4：通用增量 Checkpoint 的 RocksDB 状态存储上传过程

状态双写对性能影响很小（2～3%）

通用增量 Checkpoint 须要双写状态数据（写状态存储和 State Changelog），因而有额定的性能耗费。如图 5 所示，通用增量 Checkpoint 引入 Durable Short-term Log（DSTL，短存 Log）治理 State Changelog，状态变动日志须要同时写入状态存储和 DSTL 中。实测中，在网络带宽不是瓶颈的状况下，其对极限吞吐量（作业能达到的最高 TPS）仅有很小（2～3%）的影响。状态变动日志以 log append 的模式程序写入攒批上传，影响微不足道。

图 5：以 RocksDB 状态存储为例，通用增量 Checkpoint 状态双写示意图

额定的存储和网络流量费用可控且可估算

存储空间方面，引入通用增量 Checkpoint 后，Checkpoint 由两局部组成：状态存储的物化局部和 DSTL 中的增量状态变动日志。DSTL 在状态存储后端实现物化且 Checkpoint 过期（subsume）后能够删除 State Changelog 对应的局部。因而实践上来说，在状态存储行将实现物化、清理 State Changelog 之前，DSTL 占用的远端额定存储空间最大。在作业稳固运行的状况下，算子的读写模式根本固定，因而能够估算出在一个物化距离中写入 DSTL 的 State Changelog 数据规模，并通过参数调整其大小。例如，通过减小物化距离，能够升高 DSTL 占用远端存储的最大值。如图 6 所示，在相邻的两个物化触发点之间，Checkpoint 中状态存储的物化局部放弃不变，而 State Changelog 局部继续减少。因而，State Changelog 累积最大值呈现在清理 State Changelog 前。图 6 中，CHK-7 是 MID-1 之后、MID-2 之前的最初一个 Checkpoint，蕴含了 t₁ 至 t₇ 之间全副的 State Changelog，此时 State Changelog 累积值最大。

图 6：通用增量 Checkpoint 中，算子 - 1 的全量 Checkpoint 大小变动示意图

另外值得一提的是远端存储的费用占流式作业计费中的比例很小。以阿里云 OSS 服务为例，其 1 GB 存储空间的每月费用是 0.12 RMB 左右【2】。单算子须要的 Checkpoint 存储规模通常在 10 GB 以内，一个月折算 1.2 RMB，远低于算子的计算资源费用。

网络流量方面，State Changelog 会有额定的网络流量开销，但这个局部因为状态存储后端快照频率（物化过程）升高会有肯定的对消，并且个别 Checkpoint 应用的是内网流量，费用简直能够忽略不计。

得益于 Checkpoint 实现耗时的缩短，作业能够达到更低的端到端提早，同时回追更少的数据，放慢作业复原；得益于 Checkpoint 实现的更稳固，整个集群的资源耗费能够更安稳；得益于 通用增量 Checkpoint 机制的轻量可控，其对极限吞吐量和空间资源的开销是咱们能够预估且承受的。

因而，咱们分成六组试验验证通用增量 Checkpoint 机制的收益与开销。

测试基于 Flink 1.16 版本，应用 K8s application 部署模式，state backend 抉择 RocksDB（FRocksDB 6.20.3 版本）并开启 state backend 层面的增量 Checkpoint，远端存储应用阿里云 OSS 规范存储。Flink TM 和 JM 的配置应用 1 Core 4 GB RAM。测试作业默认并发度为 50。不便起见，下文将通用增量 Checkpoint（General Incremental Checkpoint）简写为 GIC。

为了测量极致状况下 Checkpoint 实现的速度和稳定性，Checkpoint 距离设置为 1 秒，从而端到端提早和生效后的数据回追量可降为秒级。通用增量 Checkpoint 的物化距离设置为 3 分钟，该设置与 RocksDB 增量 Checkpoint 的罕用 Checkpoint 距离对齐。

测试作业涵盖了理论利用中常见的两类有状态作业，别离是指标聚合型和明细型作业。

指标聚合型作业的特色是蕴含有聚合函数，例如，min、max、count 等。本测试抉择 WordCount 作业作为典型的指标聚合型作业。咱们将 WordCount 的单并发状态规模管制在 500 MB 左右（中等状态大小），每一个 Word 的长度设置为 200 Bytes（聚合类型作业 Key 的长度）。

明细记录型作业的特色是须要保留一段残缺的原始数据流，例如，join、window。本测试抉择 Sliding window 作业（简写为 Window）作为典型的明细记录型作业。咱们将 Window 的单并发状态规模管制在 2 GB 左右，Window 中每一个 record 的大小设置为 100 Bytes。

本试验应用 Checkpoint 实现数量和实现工夫来掂量 Checkpoint 制作速度。

从表 1 中能够看到，开启通用增量 Checkpoint，作业能够更高频地实现 Checkpoint。在开启 GIC 之后，WordCount 作业的 Checkpoint 实现数量晋升了 4.23 倍，Sliding Window 作业的 Checkpoint 实现数量晋升了近 40 倍。

从表 2 中能够看到，开启通用增量 Checkpoint 能够极大减速 Checkpoint 的实现。WordCount 和 Window 作业的 Checkpoint 均匀实现工夫别离降落 89.7% 和 98.8%。在状态规模较大的 Window 测试作业中，开启 GIC，Checkpoint 实现工夫能够从分钟级降为秒级。

表 1：12 小时内胜利实现 Checkpoint 数量

表 2：开启 / 敞开通用增量 Checkpoint，Checkpoint 实现工夫比照

Checkpoint 速度晋升的次要起因是快照制作过程中异步上传到远端存储的数据量大幅升高。从图 7 和图 8 中能够看到，开启通用增量 Checkpoint，增量快照的大小能够升高超过 95%。这是因为 State Changelog 会继续写入到 DSTL 中。在触发 Checkpoint 的时候，通用增量 Checkpoint 只须要把以后还未上传的 State Changelog（小于 5MB）写入到远端存储，因而通用增量 Checkpoint 在 Checkpoint 期间异步上传远端存储的数据量非常少，大幅晋升了 Checkpoint 的制作速度。更疾速的 Checkpoint 能够反对更短的 Checkpoint 距离，从而升高作业运行时的端到端时延。为了保障数据处理的 Exactly-once 语义，事务性 Sink 算子须要在 Checkpoint 实现之后才能够触发事务提交。因而，通用增量 Checkpoint 能够将事务性算子的端到端时延从分钟级降至秒级。

图 7：WordCount 运行时增量 Checkpoint 大小

图 8：Window 运行时增量 Checkpoint 大小

本试验应用 Checkpoint 实现工夫的稳定范畴来掂量 Checkpoint 制作的稳定性。

从图 9 和图 10 中能够看到，开启通用增量 Checkpoint，Wordcount 和 Window 作业的 Checkpoint 实现工夫可能稳固在 1 – 5 秒内。相同没有 GIC 时，RocksDB 增量快照的实现工夫稳定范畴大很多。在 Sliding Window 的状况，稳定范畴超过 100 秒，极其状况下会超过 400 秒。

图 9：WordCount 作业 Checkpoint 实现工夫

图 10：Window 作业 Checkpoint 实现工夫

Checkpoint 稳定性晋升的次要起因是 Checkpoint 执行过程与存储后端快照解耦。针对本试验应用的 RocksDB 存储后端，RocksDB 增量 Checkpoint 依赖于 RocksDB 的快照机制，而 RocksDB 外部的 Compaction 会影响 RocksDB 快照产生的增量快照大小。而 RocksDB Compaction 触发受到多种因素影响，具备随机性，这可能会导致 RocksDB 增量快照大小稳定范畴很大。在开启通用增量 Checkpoint 之后，Checkpoint 期间只需上传增量 State Changelog，无效躲避了 RocksDB Compaction 对增量快照制作的负面影响。

本测试应用 Window 作业，并应用 Kafka Source 复原后的业务延时【3】来掂量数据回追量。在作业运行时，通过向 Kafka 注入指定的 record，触发作业生效。如图 11 所示，开启通用增量 Checkpoint，数据回追工夫从 180 秒缩小到 105 秒，缩小 41.7%（状态下载工夫因为开启了 local recovery 能够疏忽）。数据回追量降落的次要起因是 Checkpoint 做得更快让 Checkpoint Interval 能够设得更短。

图 11：Window 作业中 Kafka Source 的业务提早

值得一提的是 Source 的提早和作业复原速度也有关系，表 3 展现了 Window 作业在复原中各个阶段的 P99 耗时。通用增量 Checkpoint 复原 State Changelog 须要额定应用 16 秒左右。因为开启了 local recovery，无需从远端存储下载状态文件，所以下载局部工夫能够疏忽。对于 Window 作业，依据 3.2 节中的数据后果，Checkpoint 距离能够从分钟级升高到秒级。因而，综合思考上述两个方面，通用增量 Checkpoint 以减少渺小的额定复原工夫为代价（16 秒），将重放数据量从分钟级降到秒级，因而整体上有更快的复原速度。

表 3：Window 作业复原的各个阶段 P99 耗时

本测试应用 WordCount 作业，单并发状态大小设置在 2GB 左右，比照测试整个作业的 CPU 使用量和网络流量实时变动状况。通过调整 Checkpoint 距离和通用增量 Checkpoint 的开关设置三个试验：

敞开 GIC，距离 10min：以 10min 为 Checkpoint 距离，敞开通用增量 Checkpoint

敞开 GIC，距离 10s：以 10s 为 Checkpoint 距离，敞开通用增量 Checkpoint

开启 GIC，距离 10s：以 10s 为 Checkpoint 距离，开启通用增量 Checkpoint

图 12：作业的全副 TM CPU 总使用率

图 13：作业的网络流量

联合图 14 比照三个试验在 CPU 和网络流量上的数据，能够发现：

敞开 GIC，距离 10min 的作业，其 CPU 使用率和网络流量有非常明显的尖峰，每次的峰值数据相比平均值有数十倍的增长，且该稳定具备肯定周期性。周期性稳定次要是因为所有节点在 Checkpoint 同步阶段会触发 RocksDB 强制 Flush，进而可能导致多个并发节点同时 Compaction，造成 CPU 和网络流量明显增加。这种周期性会影响整个集群作业的稳定性，也让集群资源的估算变得艰难，导致资源节约。

敞开 GIC，距离 10s 的作业，其 CPU 使用率和网络流量的峰值绝对敞开 GIC，距离 10min 的作业降落了 37.8% 和 34.9%，但其均值晋升了 128.9% 和 730.2%，且其波动性仍然较大。峰值降落是因为 Checkpoint 距离变短，在一个 Checkpoint 距离期间生产的数据量也随之变少，因而每次 Checkpoint 时参加 Compaction 的数据量也变少，要上传的数据量也随之变少；均值晋升是因为 Compaction 的频次会随着 Checkpoint 距离的缩小而减少。

开启 GIC，距离 10s 的作业，其 CPU 使用率和网络流量绝对另外两者显著稳固和缩小很多，其峰值绝对敞开 GIC，距离 10min 的作业降落了 62.2% 和 69.4%，绝对敞开 GIC，距离 10s 的作业降落了 39.3% 和 53.0%；其均值绝对敞开 GIC，距离 10s 的作业降落了 46.8% 和 67.7%。峰值和均值降落次要来源于 Checkpoint 距离缩小和前文提到的错峰的物化过程、运行时的继续上传。

图 14：三个试验的峰值 / 均值比照后果

如 1.3 节所述，通用增量 Checkpoint 通过低频、错峰的 Checkpoint 个性，让集群的资源应用变得十分安稳。在升高 Checkpoint 距离的同时开启通用增量 Checkpoint，能够在升高 Flink 作业的 CPU 和网络流量的耗费的同时，晋升 Flink 作业的 CPU 利用率和网络流量的稳定性。对单个作业来说，通用增量 Checkpoint 能够无效升高计算和流量老本，同时在资源受限的云原生环境下，其更稳固的 CPU 利用率和网络流量也能够让作业的 TPS 更加稳固；对整个 Flink 集群来说，稳固的 CPU 利用率和网络流量也使得作业间的资源竞争更加可控，进一步晋升 Flink 集群的稳定性，同时也更易于估算集群资源，防止资源节约。

本测试应用 WordCount 作业，加大 Source 的流量，在作业达到反压的状况下，比照测试不同 Key Length 和 State Size 下开启 / 敞开通用增量 Checkpoint 后单个算子的 极限吞吐量。

值得注意的是，Flink 1.16 的通用增量 Checkpoint 在 序列化 上有额定的开销，通过 FLINK-30345【4】的优化后，由表 4 能够看到 ，算子的极限吞吐量差别稳固在 3% 以内。 进一步当开启 Local Recovery 后，从表 5 中能够看到，算子的极限吞吐量差别在 5% 以内。

因而，开启通用增量 Checkpoint 后，双写（state changelog）和三写（local recovery）对极限性能的影响都很小，绝对其余方面的晋升，根本能够忽略不计。

表 4：Flink 1.16 优化后开启 / 敞开通用增量 Checkpoint 后极限吞吐量比照

表 5：Flink-1.16 优化后开启 Local Recovery 下开启 / 敞开通用增量 Checkpoint 极限吞吐量比照

在开启通用增量 Checkpoint 后，Flink Checkpoint 包含物化的状态表局部加上增量的 State Changelog，因而须要额定的远端存储空间来存储 State Changelog。【1】中“Benchmark 测试后果剖析”一节有试验失去的具体数据，这里咱们将从实践动手，依据作业的解决逻辑和参数，对减少的远端存储空间进行剖析和估算。

减少的空间次要来自 State Changelog。后面剖析过，在状态存储行将实现物化、清理 State Changelog 之前，DSTL 占用的远端额定存储空间最大。因而 DSTL 的最大值近似为相邻物化之间的 State Changelog 总量，计算公式如下：

1 全量 Checkpoint 增加量最大值 ≈ Changelog 写操作速率 × 单次写大小 × 物化距离

咱们应用 Sliding Window 作业验证上述计算公式，Window 大小和滑动长度的比值设置为 10 和 5。依据 Sliding Window 算子（Jave Flink 实现【5】）的执行逻辑，其全量 Checkpoint 增加量的预估值为：

1 全量 Checkpoint 增加量 ≈ 
2 (Window + Timer 写操作速率) × (Window + Timer 单次写大小) × 物化距离

如图 15 和图 16 所示，理论作业的全量 Checkpoint 增加量和上述公式计算的预估增量基本一致。同时，能够发现 Window 作业的全量 Checkpoint 增加量具备以下特点：当“Window 大小 / 滑动长度”固定的时候，全量 Checkpoint 增加量根本放弃不变。在比例为 10 的状况下，增加量约为 1.74 GB；在比例为 5 的时候，增加量约为 887.4 MB。这是因为“Window 大小 / 滑动长度”决定了公式中的“写操作速率”，同时，该作业的单次写大小和物化距离也是固定的，因而全量 Checkpoint 增加量也是固定的。

图 15：Window 大小 / 滑动长度 = 10，全量 Checkpoint 大小

图 16：Window 大小 / 滑动长度 = 5，全量 Checkpoint 大小

全量 Checkpoint 减少使得作业须要应用更多的远端存储空间，但在理论中对作业整体计费影响很小。以阿里云 OSS 服务为例，存储计费是 0.12 RMB/GB，单算子须要的 Checkpoint 存储规模通常在 10 GB 以内，一个月折算 1.2 RMB，远低于算子的计算资源费用。

开启通用增量 Checkpoint 能够显著进步 Checkpoint 的实现速度和稳定性，并以可控的性能与资源开销为作业提供更低的端到端提早、更少的数据回追和更安稳的资源耗费。

在 Flink 1.16 后，通用增量 Checkpoint 曾经达到了生产可用的状态。后续版本中，在实现机制上，咱们将重点关注其余可用的 DSTL 存储组件，如 Apache Bookkeeper，来实现更短的提早；在实际落地上，咱们将重点关注与其余技术，如 Unaligned Checkpoint、Buffer Debloating 的联合，打造一整套残缺高效稳固的 Checkpoint 流程。

【1】Flink 1.15 新性能架构解析：高效稳固的通用增量 Checkpoint

【2】阿里云 oss 官网售价

【3】Flink Kafka Source 的业务提早指标

【4】Flink-30345 Improve the serializer performance of state change of changelog

【5】Sliding Window 算子的 Java Flink 实现

点击查看更多技术内容

流动举荐

阿里云基于 Apache Flink 构建的企业级产品 - 实时计算 Flink 版现开启流动：
99 元试用实时计算 Flink 版（包年包月、10CU）即有机会取得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！
理解流动详情：https://www.aliyun.com/product/bigdata/sc

关于后端:高效稳定的通用增量-Checkpoint-详解之二性能分析评估

一、概述

二、收益与开销

2.1 更稳固更低的端到端提早

2.2 更少的数据回追

2.3 更安稳的资源耗费

2.4 可控的性能与资源开销

三、收益与开销试验后果与剖析

3.1 测试环境与配置

3.2 更疾速的 Checkpoint 制作

3.3 更稳固的 Checkpoint 制作

3.4 更少的数据回追

3.5 更安稳的资源耗费

3.6 渺小的极限吞吐量影响

3.7 可预估的远端存储空间开销

四、总结

参考

更多内容