云技术博客这个问题其实有点“陷阱”性质，因为 S3（Simple Storage Service）是 AWS 的专有协议和服务名称，并不是一个通用的标准协议。国内主流云厂商（阿里云、腾讯云、华为云等）虽然都推出了兼容 S3 协议的 OSS/COS/OBS 服务，但它们的底层实现、架构设计和性能表现并不完全一样。
所以，讨论“通用型 S3 云服务的读写性能”，我们需要拆解为两个层面：
- 基于 S3 协议的对象存储（OSS/COS/OBS）在典型场景下的理论性能上限和实际瓶颈。
- 不同云厂商在具体产品上的差异和优化手段。
一、先澄清概念：S3 ≠ 文件系统
很多人误以为 S3 就像一块网络硬盘，可以像本地磁盘一样随机读写小文件。这是最大的误区。
S3 本质上是对象存储（Object Storage），不是块存储（Block Storage）或文件存储（File Storage）。
- 设计初衷：高吞吐、高持久性、海量非结构化数据（图片、视频、备份、日志）。
- 核心特性：最终一致性（早期）、强一致性（近年多数已支持）、不可变版本控制。
- 性能特点：
- 读性能：通常很高，尤其是顺序读和大文件下载。
- 写性能：受限于元数据操作和网络延迟，小文件写入效率低，大文件上传可通过分片提升吞吐量。
二、读写性能详解
1. 读性能（Read Performance）
对于大多数应用场景，读性能不是瓶颈。
- 单次 GET 请求：
- 理论延迟：通常在 几十毫秒到几百毫秒 之间，取决于客户端与数据中心之间的网络距离。
- 实际体验：如果配合 CDN 提速，全球用户访问静态资源时，延迟可降至 10ms 以内。
- 并发读取：
- S3 的设计允许极高的并行度。单个桶（Bucket）的 PUT/GET 请求速率理论上可达 每秒数千甚至上万次，具体取决于实例类型和网络带宽。
- 如果使用
Range Get（断点续传或部分读取），性能依然优秀，但需注意元数据开销。
✅ 结论：读性能极高，适合做内容分发、静态网站托管、大数据集扫描（如 Athena、Spark）。
2. 写性能（Write Performance）
写性能是 S3 的主要痛点，尤其是 小文件写入 和 频繁元数据更新。
- 小文件写入（< 1MB）：
- 每次 PUT 都是一个独立的 HTTP 请求，涉及认证、签名、元数据处理、分布式协调。
- 单个客户端的 PUT 速率限制：AWS S3 默认单账户单 Region 的 PUT 速率约为 3,500 PUT 秒（无配额限制时可申请提升）。
- 实际测试中，普通云服务器直连 S3，小文件写入延迟可能在 100ms~500ms 不等，且容易触发限流。
- 大文件上传（> 5GB）：
- 必须使用 Multipart Upload（分片上传）。
- 每个分片可并行上传，充分利用带宽。
- 吞吐量主要受限于 出网带宽 和 CPU 压缩能力。
- 例如：一台 c5.xlarge 实例（最高 10Gbps 带宽），理论上最大上传速度可达 ~800MB/s（考虑 TCP 开销和协议头）。
⚠️ 注意：S3 不支持“原地修改”。任何修改都是新版本的创建 + 旧版本删除。因此，高频小文件写入会导致大量 DELETE 操作，进一步加剧性能压力。
三、国内云厂商的差异与优化
虽然都叫“兼容 S3 协议”，但各家做了大量优化：
| 厂商 | 产品名 | 关键优化点 |
|---|---|---|
| 阿里云 | OSS | – 支持 CDN 回源智能调度 – 提供 传输提速（基于全球提速节点） – 小文件优化：支持 合并写（部分 SDK 层优化） – 带宽峰值更高，企业级套餐可定制 QPS |
| 腾讯云 | COS | – 深度集成微信生态，移动端优化好 – 支持 CBR（跨域复制） 自动同步 – 提供 COSFS（挂载为文件系统），但性能较差，不推荐生产环境 – 小文件缓存机制较好 |
| 华为云 | OBS | – 强调 安全合规，加密性能损耗可控 – 支持 OBS Browser+ 工具链优化 – 与 ModelArts 等 AI 平台无缝对接，适合训练数据集加载 |
特别提示：关于“通用性”的坑
如果你声称你的应用要“通用”，即同时支持 AWS S3、阿里云 OSS、腾讯云 COS，那么你必须接受以下现实：
- API 差异：虽然基础 CRUD 一致，但高级功能（如生命周期规则、事件通知、跨区域复制）的实现细节不同。
- 性能波动：同一代码在不同云厂商上表现可能相差 2~5 倍，尤其在高峰期。
- SDK 封装建议：不要直接调用原生 S3 SDK，建议使用抽象层（如 MinIO Client、AWS SDK v2 的 Endpoint 替换、或自研适配层）。
四、如何提升 S3 读写性能？（实战建议）
1. 读性能优化
- 必装 CDN：静态资源务必走 CDN，否则直接回源会浪费大量带宽成本且增加延迟。
- 使用预签名 URL：避免后端XX转发，让客户端直连 S3 下载，减轻服务器压力。
- 并行下载：前端使用多线程或多连接下载大文件。
2. 写性能优化
- 合并小文件：将多个小文件打包成一个大文件（如 .tar.gz、Parquet、ORC），再上传。这是最有效的手段！
- 启用 Multipart Upload：所有 > 5GB 的文件必须分片上传。
- 异步上传：使用后台线程池进行上传，避免阻塞主业务逻辑。
- 选择靠近用户的 Region：减少网络 RTT。
- 使用专用带宽包：如果流量巨大，购买固定带宽包比按量付费更稳定且便宜。
3. 架构级优化
- 冷热分离：频繁访问的数据放标准存储，低频数据归档到 Glacier/Archive 类存储，降低成本并提升热点数据响应速度。
- 边缘计算：利用 Cloudflare Workers、阿里云 EdgeRoutine 等在边缘节点处理简单逻辑，减少对中心 S3 的请求次数。
五、总结
S3 类对象存储的读写性能：
- 读：极快，尤其配合 CDN 后，可满足亿级 PV 的静态资源分发需求。
- 写：中等偏下，不适合高频小文件写入场景。若需高性能写入，应转为 批量上传 + 分片 + 合并。
- 关键指标：QPS（每秒请求数）和 Throughput（吞吐量）是两个独立维度。小文件看 QPS，大文件看 Throughput。
- 国内实践：阿里云 OSS 和腾讯云 COS 在国内网络环境下表现优于 AWS S3（因物理距离近），但需注意各家的 API 细微差别和限流策略。
最后提醒：如果你的业务需要类似数据库的随机读写、事务支持、低延迟键值查询，请放弃 S3，改用 Redis、DynamoDB、TiKV 或 MySQL。S3 是为“大数据湖”和“内容分发”而生的，不是为“实时交易”设计的。