3、选型核心指标：性能、成本、可用性与一致性
做云存储选型，说白了就是一场「戴着镣铐跳舞」的游戏。你得在性能、成本、可靠性和数据一致性之间找到那个微妙的平衡点。我见过太多团队，上来就盯着IOPS猛看，结果月底账单出来傻了眼。也见过为了省几毛钱存储费，选了弱一致性模型，最后线上数据对不上，加班加到头秃。
今天咱们就把这四个核心指标掰开揉碎，一个个讲清楚。嗯，这里要注意，每个指标都不是孤立的，它们之间会互相拉扯。
3.1 性能三剑客：IOPS、吞吐量、延迟
性能指标，我习惯把它分成三个维度来看。你想想看，就像评价一辆车，你不能只看最高时速，还得看加速能力、载重能力和刹车距离。云存储也是这个道理。
3.1.1 IOPS（每秒输入输出操作数）
IOPS 衡量的是存储系统处理「小文件、高并发」请求的能力。单位是次/秒。
- 典型场景：数据库事务日志、消息队列、小文件读写。
- 影响因素：磁盘类型（SSD vs HDD）、网络延迟、协议开销。
- 我的经验：我在项目中遇到过，一个日志系统用了 HDD 后端，IOPS 只有几百，业务高峰期直接打满。后来切到 SSD 后，IOPS 飙到几万，问题瞬间解决。但代价是存储费涨了 3 倍。
避坑指南：我曾经被厂商的「最大 IOPS」宣传坑过。那个数字通常是在 4KB 随机读、队列深度 32 的条件下测出来的。你实际业务如果是 8KB 随机写，IOPS 可能直接腰斩。一定要看「典型负载」下的性能数据。
3.1.2 吞吐量（Throughput）
吞吐量看的是「大文件、顺序读写」的能力。单位是 MB/s 或 GB/s。
- 典型场景：视频转码、大数据分析、备份恢复。
- 影响因素：网络带宽、磁盘带宽、存储节点数量。
- 个人建议：我建议你区分「读吞吐」和「写吞吐」。很多云厂商读吞吐能到 10GB/s，写吞吐可能只有 2GB/s。如果你的业务是写多读少，比如日志归档，那就要重点看写吞吐。
3.1.3 延迟（Latency）
延迟是「单个请求从发出到收到响应的时间」。单位是毫秒（ms）。
- 典型场景：在线交易、实时推荐、游戏排行榜。
- 影响因素：网络距离、存储介质、缓存命中率。
- 为什么重要？延迟每增加 100ms，用户流失率可能上升 1%。我做过一个电商项目，把对象存储的延迟从 50ms 优化到 10ms，转化率直接提升了 2 个百分点。
性能调优小技巧：不要只看平均延迟，要看 P99（99% 分位延迟）。平均延迟 10ms 的系统，P99 可能高达 500ms。那些「慢请求」才是真正影响用户体验的元凶。
3.2 成本三驾马车：存储费、请求费、流量费
成本这块，我见过太多人只盯着「存储费」看。其实云存储的账单是个「组合拳」，少看一个都可能让你月底哭出来。
3.2.1 存储费
这是最直观的费用，按「存储容量 × 单价」计算。但要注意：
- 存储层级：标准型、低频型、归档型，价格差 10 倍以上。
- 冗余策略：多副本（3副本） vs 纠删码（EC），EC 能省 30%-50% 的存储费。
- 我的经验：我建议你把「冷数据」和「热数据」分开存储。比如 30 天前的日志，自动迁移到低频存储，能省 60% 的费用。
3.2.2 请求费
这个坑很多人踩过。请求费是按「API 调用次数」收费的，包括 PUT、GET、DELETE、LIST 等操作。
- 典型陷阱：有些厂商存储费很便宜，但请求费贵得离谱。比如你存了 1PB 数据，每天做全量 LIST 操作，请求费可能比存储费还高。
- 避坑指南：我曾经帮一个客户优化过，他们每天凌晨跑一个全量扫描任务，LIST 请求量上亿次。后来改成增量扫描，请求费直接降了 90%。
3.2.3 流量费
流量费包括「内网流量」和「外网流量」。内网通常免费，外网按量计费。
- 关键点：外网下行流量（从云存储到客户端）通常很贵，0.5-1 元/GB。
- 优化策略：使用 CDN 加速，把流量费从存储侧转移到 CDN 侧，通常能省 30%-50%。
- 个人建议：我建议你在设计架构时，尽量让「计算」和「存储」在同一个可用区，避免跨 AZ 流量费。
成本对比表（以某云厂商为例）
| 存储类型 | 存储费（元/GB/月） | 请求费（元/万次） | 外网流量费（元/GB） |
|---|---|---|---|
| 标准型 | 0.12 | 0.01 | 0.50 |
| 低频型 | 0.08 | 0.05 | 0.50 |
| 归档型 | 0.02 | 0.10 | 0.50 |
你看，归档型存储费便宜，但请求费贵了 10 倍。如果你频繁读取归档数据，总成本可能反而更高。
3.3 可用性：SLA 不是万能药
SLA（服务等级协议）是云厂商给你的承诺。常见的 SLA 有：
- 99.9%：每年最多宕机 8.76 小时。
- 99.99%：每年最多宕机 52.56 分钟。
- 99.999%：每年最多宕机 5.26 分钟。
但我要泼一盆冷水：SLA 只是「赔偿条款」，不是「保证条款」。你想想看，就算厂商承诺 99.99%，真宕机了，赔给你的那点钱，能弥补业务损失吗？
重要提醒：我曾经遇到过一个案例，某厂商 SLA 写的是 99.99%，但实际可用性只有 99.9%。客户去索赔，厂商说「我们的 SLA 是按月度计算的，你这个月刚好没达到」。嗯，这里要注意，SLA 的计算周期、排除条款（如计划内维护、不可抗力）都要仔细看。
我的建议是：不要完全依赖 SLA。自己做好「多 AZ 部署」和「跨区域容灾」。比如用两个可用区的对象存储，配合 DNS 切换，可用性可以做到 99.999% 以上。
3.4 一致性模型：强一致 vs 最终一致
一致性模型，说白了就是「你写完数据后，别人多久能看到」。这个选择直接影响你的业务逻辑复杂度。
3.4.1 强一致性
- 特点：写入成功后，所有后续读取都能看到最新数据。
- 代价：写入延迟高（需要多副本同步确认），可用性可能降低（CAP 理论）。
- 适用场景：金融交易、库存扣减、用户余额。
3.4.2 最终一致性
- 特点：写入成功后，读取可能看到旧数据，但最终会一致（通常几毫秒到几秒）。
- 优势：写入延迟低，可用性高。
- 适用场景：社交动态、日志存储、静态资源。
3.4.3 如何选择？
我个人的经验是：
- 如果你的业务「读后写」很频繁（比如先查余额再扣款），必须用强一致性。
- 如果你的业务「写后读」有容忍度（比如发个朋友圈，别人晚几秒看到也没事），用最终一致性更划算。
- 有些云存储提供「读后写一致性」的折中方案，比如写入后 1 秒内保证一致，可以关注一下。
避坑指南：我曾经在一个项目中，用了最终一致性的对象存储来存「订单状态」。结果用户支付成功后，页面还显示「待支付」，因为读取到了旧数据。后来我们加了一个「写入后强制刷新缓存」的逻辑，才解决了这个问题。嗯，这个坑踩得值。
3.5 四个指标的权衡之道
最后，我总结一个「选型决策矩阵」，帮你快速定位：
| 业务类型 | 核心指标 | 推荐方案 |
|---|---|---|
| 在线交易 | 低延迟 + 强一致 | 本地 SSD + 强一致存储 |
| 大数据分析 | 高吞吐 + 低成本 | HDD + 纠删码 + 最终一致 |
| 静态资源托管 | 低成本 + 高可用 | 对象存储 + CDN + 最终一致 |
| 日志归档 | 极低成本 + 高吞吐 | 归档存储 + 低频访问 |
你想想看，没有「最好」的存储，只有「最合适」的存储。选型时，先把业务场景画清楚，再拿这四个指标去套，基本不会跑偏。
下一章，我会带你实战「如何用压测工具验证这些指标」，到时候咱们拿数据说话。