4. S3存储性能优化
S3 的性能问题很少来自“磁盘慢”，绝大多数来自请求路径：请求速率被分区限制、单连接吞吐上不去、上传方式不适合大对象、或者为了省钱选了检索代价很高的存储类。理解 S3 的性能，本质是理解“请求如何被路由到分区、数据如何穿过网络、以及不同存储类的检索成本”。
一、请求速率：按前缀分区，而不是按桶
S3 的请求速率限制作用在分区（partition）上，而分区是按前缀切分的。每个前缀默认可支撑约 3500 次 PUT/COPY/POST/DELETE 和 5500 次 GET/HEAD 请求每秒。这意味着：如果所有对象都写在同一个前缀下（例如 logs/2024-06-01.log 全部落在 logs/ 下），高并发写入会集中打到同一个分区，触发 503 SlowDown。
关键认知是：桶名不参与分区切分，前缀才参与。因此优化请求速率的核心动作是“把请求打散到多个前缀”。传统做法是用哈希前缀，例如把对象键设计成 a1b2/logs/...、c3d4/logs/...；而现代 S3 已经能自动按前缀扩展分区，对于顺序前缀（如时间戳）也能自动分摊，因此不必再手工加随机哈希前缀。真正需要关注的是：单个前缀的瞬时并发是否超过分区上限。
一个可操作的判断方法是：如果业务峰值写入是 20000 PUT/s，且全部落在同一前缀，就应主动拆成至少 6 个前缀（20000 / 3500 ≈ 5.7）。拆分维度可以按业务实体（租户 ID、设备 ID）或时间分片，而不是无意义地随机哈希。
二、前缀设计：兼顾请求速率与生命周期
前缀设计不只是性能问题，还直接影响生命周期规则和成本。常见模式有：
- 按时间分层：
year=2024/month=06/day=01/hour=13/，便于按时间过期和归档，但同一小时内的写入会集中在一个前缀。 - 按业务实体分层：
tenant=acme/device=001/，天然分散，适合多租户高并发写入。 - 混合分层：
tenant=acme/year=2024/month=06/，既分散又便于生命周期管理。
需要避免的是“所有对象都放在桶根目录”或“所有对象都放在同一个固定前缀下”。如果业务无法改变键结构，可以在写入端做一层轻量分片，例如在键前加 shard-01/ 到 shard-16/，由写入端轮询选择。
三、传输加速与多部分上传：解决吞吐瓶颈
当客户端跨地域访问 S3 时，公网长距离传输会带来高延迟和丢包，单连接吞吐往往只有几 MB/s。此时应启用 S3 Transfer Acceleration，它让客户端就近接入 AWS 边缘节点，再通过 AWS 骨干网回源到桶所在区域。对于跨洲上传，实测通常能提升数倍吞吐；但如果客户端本来就在桶同区域，加速收益很小，反而增加费用。
对于大对象（通常建议大于 100 MB），应使用 Multipart Upload。它把对象切成多个分片并行上传，最后合并。关键参数是分片大小和并发数：分片太小会产生大量请求，分片太大则单分片失败重传成本高。经验值是分片 8–64 MB、并发 4–16。例如一个 10 GB 文件，按 64 MB 分片约 160 片，8 并发上传，可显著缩短总耗时，并且单片失败只需重传该片。
aws s3 cp large.bin s3://bucket/key \
--expected-size 10737418240 \
--cli-write-timeout 0 \
--only-show-errors
# AWS CLI 默认对大于 8 MB 的文件自动启用 multipart
# 可通过 s3.max_concurrent_requests 调整并发注意：多部分上传的分片在完成前会占用存储并计费，未完成的上传应通过生命周期规则自动清理，否则会持续产生存储费用。
四、S3 Select 与 Glacier Deep Archive 的取舍
S3 Select 允许用 SQL 表达式在服务端过滤 CSV、JSON、Parquet 数据，只返回匹配行，从而减少传输量和客户端解析成本。它适合“从大文件中取少量行”的场景，例如从 1 GB CSV 中筛选某几列。但如果需要扫描大部分数据，S3 Select 的额外计算开销可能不如直接下载后本地处理。它的性能收益主要来自减少网络传输，而不是加速存储读取。
Glacier Deep Archive 是成本最低的存储类，但检索代价极高：标准检索通常需要 12 小时，批量检索约 48 小时，且检索请求本身按 GB 计费。它适合“几乎不访问、但必须保留”的合规归档数据。如果业务需要分钟级恢复，就不应选 Deep Archive，而应考虑 Glacier Flexible Retrieval 或 S3 Intelligent-Tiering。
取舍的核心是访问频率与恢复时间目标（RTO）：访问越少、RTO 越宽松，越适合 Deep Archive；一旦需要频繁读取或快速恢复，节省的存储费会被检索费和等待时间抵消。
五、把优化落到可执行的检查项
在实际项目中，可以按下面的顺序排查和优化：
- 看请求速率：CloudWatch 的
5xxErrors和SlowDown是否集中在某个前缀？如果是，拆分前缀或调整写入并发。 - 看单连接吞吐：跨地域上传是否只有几 MB/s？启用 Transfer Acceleration，并确认桶已开启加速。
- 看大对象上传方式：大于 100 MB 的对象是否使用 multipart？分片大小和并发是否合理？
- 看存储类与访问模式：是否把频繁访问的数据放进了 Deep Archive？是否用 S3 Intelligent-Tiering 自动分层？
- 看 S3 Select 使用场景：是否只取少量行？如果每次都要扫描大部分数据，直接下载可能更划算。
总结来说，S3 性能优化的主线是：请求打散到多前缀、大对象多部分并行、跨地域开传输加速、冷数据按 RTO 选存储类。S3 Select 是减少传输的工具，不是加速存储读取的万能药；Deep Archive 是成本工具，不是性能工具。把这几条边界分清，就能在性能与成本之间做出合理取舍。