持久存储：让数据越过断电边界
打开文档时，文件从存储设备进入主存；编辑时，处理器主要访问主存中的内容；保存时，修改又需要写回持久存储。H10 讨论过存储层次，H11 说明了主存的作用与边界。本课继续沿着数据的去向，认识机械硬盘、固态盘以及建立在存储系统之上的云盘。学习目标不是记住某个型号，而是能够解释设备为什么有快慢差异，并把业务请求翻译成可核对的存储需求。
通常所说的硬盘可能泛指持久存储设备，也可能专指机械硬盘。为避免混淆，本课用 HDD 表示机械硬盘，用 SSD 表示固态盘。HDD 主要把数据记录在旋转盘片的磁性介质上，SSD 主要把数据记录在闪存单元中。它们都能在正常断电后保留已经可靠写入的数据，但实现机制不同，适合的访问方式也不同。云盘则是云平台提供的块存储服务，其底层可能由多台设备共同完成请求，不能直接等同于某块物理盘。
持久存储首先回答的是“数据能否在正常断电后保留”，而不是“每次写入是否立即安全”。应用调用保存函数、操作系统接受写入、设备收到请求、数据达到规定的持久化边界，是不同阶段。系统可能在主存中缓存尚未落盘的数据。掉电保护、刷新请求以及云服务的写入确认规则，都会影响故障时能保住什么。这里先建立边界意识，文件系统如何组织和提交数据留到 S5 展开。
保存成功也不等于数据永远不会丢失。设备可能损坏，用户可能误删，软件可能写错内容。冗余副本能够降低部分设备故障的影响，却可能把误删同步传播。备份则需要保留可以恢复的历史状态，并实际检验恢复过程。选购性能更高的 SSD 不能替代备份，购买容量更大的云盘也不会自动形成完整的恢复方案。
读者可以把持久存储看成主存之外的长期工作区。容量决定能够放多少内容，性能决定请求完成得多快，耐久性约束介质能够承受多少写入，可靠性与恢复设计决定出问题以后怎么办。这些维度彼此有关，却不能互相替代。下面从 HDD 的机械动作开始，逐步建立读规格所需的判断依据。
HDD：等待磁头，也等待盘片
HDD 内部的盘片持续旋转，磁头移动到目标位置附近，才能读写相应区域。理解读取过程，可以先拆成寻道、旋转等待与数据传输。寻道是磁头移动到目标磁道附近的过程；旋转等待是等待目标扇区转到磁头下方；传输则是数据经过磁头、控制电路与接口进入主机的过程。实际设备还有命令处理与缓存等开销，这个拆分主要用于解释机械等待从何而来。
假设盘片转速为 7200 rpm，即每分钟旋转 7200 圈。每圈需要 60÷7200 秒，约为 8.33 ms。若请求到达时目标位置相对于磁头近似均匀分布，平均旋转等待约为半圈，即 4.17 ms。这个数字尚未包含寻道和传输，所以不能直接当作整次请求的平均延迟；它只是说明，即使数据很小，机械动作也可能占据大量时间。
随机读取与顺序读取的差异由此变得直观。随机请求可能不断切换位置，每次只取 4 KiB，却反复承担定位成本。顺序请求连续访问相邻区域，定位之后能够持续传输更多数据，机械成本被分摊到更大的数据量上。所谓随机或顺序，描述的是访问地址的关系，不是文件名是否整齐，也不是程序是否按照固定时间间隔发出请求。
在简化例子中，假设某类小随机请求的完整平均服务时间为 10 ms，而且任意时刻只有 1 个请求正在处理，那么每秒约能完成 100 次请求。每次传输 4 KiB，对应的数据量约为 400 KiB/s。这个数值远低于某些 HDD 的顺序传输能力并不矛盾：前者主要被等待限制，后者主要观察持续搬运数据的能力。例子用于计算方法，不代表所有 HDD 的实测值。
多个请求同时到达时，设备可能调整处理顺序，减少磁头往返。这样做可以提高整体效率，却不保证每个请求都更早完成。排队、缓存和请求合并都会改变观测结果，因此不能把“某次读到了缓存中的数据”当成整个机械介质的能力。对备份归档、大文件顺序读取等任务，HDD 仍可能提供合适的容量成本；对大量细小且分散的交互请求，机械等待往往更难隐藏。
HDD 的磁道记录方式也会影响持续写入。有些设备采用叠瓦式磁记录，即 SMR，让相邻磁道部分重叠以提高记录密度。读取目标区域仍可单独进行，但改写某条磁道时，较宽的写入区域可能影响相邻磁道，因此设备需要按更大的区域组织更新。由设备自行管理的 SMR 盘可以先接收写入，再在后台整理；连续追加大文件与反复覆盖分散的小数据，可能呈现不同的性能。
例如，归档任务初次连续写入一批视频时速度正常，随后在接近满盘的状态下反复替换许多小文件，却出现长时间写入停顿。原因可能包含缓存耗尽及记录区域重整，不能仅凭接口带宽判断盘已损坏。选用 HDD 时，应核对记录方式及其适用负载，尤其关注阵列重建等需要长时间写入的场景。
机械盘也会因难以读取某些扇区而反复重试。此时平均吞吐量下降，少量请求耗时明显增加，表现可能类似普通排队。设备报告的待处理扇区、重映射计数与读取错误可以提供线索，但单个计数不能独自判定故障原因。若慢请求伴随介质错误增长，应优先保护已有数据，并结合系统错误记录判断更换时机；用更长的超时等待不能修复磁性介质。
SSD：按页读写，按块擦除
SSD 没有依靠磁头移动与盘片旋转完成访问，因此避免了 HDD 的机械定位等待。它依然存在访问延迟：请求需要经过接口、控制器、闪存以及设备内部的处理过程。SSD 的优势不能简化成“任何操作都瞬间完成”。读取、写入、擦除是不同动作，设备繁忙程度和内部整理也会影响请求完成时间。
理解闪存时，先记住页和擦除块。页是理解闪存读写组织的基本单位，擦除块包含多个页。实际设备的页大小、块大小以及主机请求如何映射，取决于产品实现。本课不假定固定尺寸，也不把主机发出的 4 KiB 请求直接等同于某个物理页。图中的少量页只是结构示意，不表示真实设备只有这些空间。
闪存通常不能像主存那样，随意把已经写过的位置直接改成任意新内容。已有数据要更新时，SSD 常把新版本写到可用位置，再更新地址对应关系，让后续读取找到新版本。旧位置的数据随后失效，但失效不意味着该位置立刻可以重新写入。回收空间时，设备需要以擦除块为单位完成整理和擦除。
假设某个擦除块中仍混有有效页和失效页。为了释放整个块，设备可能先把有效数据搬到其他位置，再擦除原块，最后获得可供后续写入的空间。这个过程通常称为垃圾回收。它并不检查文件是否“有用”，而是根据设备内部的有效性信息管理闪存空间。因此，应用更新少量数据，也可能间接带来额外的数据搬运和擦除。
设备怎样维护地址对应关系，不需要在这里展开到固件或主控源码。对选型更有用的结论是：SSD 的主机写入量与内部实际写入量可能不同，空闲空间和工作负载会影响整理成本，持续写入的表现也可能与刚开始写入时不同。某些产品借助写入缓存吸收突发流量，缓存耗尽后可能进入另一种持续写入状态，读取规格时需要确认测试条件。
删除文件与擦除闪存也不是同一件事。操作系统可以通过 TRIM 等机制告知设备某些逻辑地址不再需要保留，设备据此获得更多整理机会，但执行时机由实现决定。文件删除、空间回收与安全销毁具有不同目标，不能仅凭删除操作判断旧数据已经不可恢复。此处只需理解释放逻辑空间为何有助于设备管理，不继续展开数据销毁流程。
IOPS、吞吐量与延迟：分别回答什么
容量之外，最常见的性能指标是 IOPS、吞吐量和延迟。IOPS 表示每秒完成的输入输出操作次数，单位通常写为次/秒；吞吐量表示每秒传输的数据量，常见单位是 MB/s 或 MiB/s；延迟表示某个请求从选定起点到完成所经历的时间，常见单位是 ms 或 μs。比较之前必须统一统计边界，否则应用观察到的耗时与设备内部服务时间可能被错误地放在一起。
在请求大小相同、统计口径一致时，吞吐量约等于 IOPS 乘以每次请求的数据量。若每秒完成 10000 次请求，每次为 4 KiB，吞吐量约为 39.06 MiB/s。若请求改成 256 KiB，假设仍能保持 10000 IOPS，计算值会达到约 2441.41 MiB/s；但设备、接口或服务可能更早触及带宽上限，因此不能默认 IOPS 保持不变。公式表达的是关系，不是性能随请求变大而无限增长的承诺。
单位也需要核对。1 KiB 等于 1024 B，1 MiB 等于 1024 KiB；十进制的 1 MB 等于 1000000 B。厂商容量、系统显示容量与性能表可能采用不同单位。先看清字母和口径，再比较数值，能够避免把换算差异当成容量短缺或性能异常。本课计算统一明确写出 KiB 与 MiB，不把 KB 的含义留给猜测。
请求大小影响系统更容易先遇到哪种限制。大量 4 KiB 请求需要频繁完成命令处理，容易先碰到 IOPS 上限；较大的连续请求每次搬运更多数据，容易先碰到吞吐量上限。因此，数据库索引查询与大文件导出即使传输相同总量，也可能需要不同的存储性能组合。只看某个最大带宽数字，无法判断小随机请求能否满足业务要求。
延迟与并发还需要单独理解。队列深度可以理解为观察范围内尚未完成的请求数量；具体工具可能按设备、线程或任务报告，使用时应确认口径。在长期稳定、边界一致的条件下，平均在途请求数约等于完成速率乘以平均响应时间。例如平均有 8 个请求在途，每秒完成 4000 次请求，则平均响应时间约为 2 ms。这是稳态统计关系，不适合直接解释启动瞬间或不断积压的队列。
当只有 1 个请求在途时，程序往往需要等它完成才发下个请求，延迟会直接限制完成速率。增加并发可以让 SSD 内部的多个资源同时工作，提高总 IOPS；但设备接近饱和后，继续提交请求往往主要增加排队。高 IOPS 和低延迟必须同时看测试时的并发条件。不能用高队列深度下的峰值 IOPS，证明低并发业务也能获得相同结果。
平均延迟还可能掩盖少量慢请求。p99 延迟表示在指定样本和统计口径下，约 99% 的请求延迟不高于该数值。它不是最大值，也不保证每个短时间窗口都符合相同比例。用户请求如果需要等待多次存储访问，偶发慢请求可能放大为可见卡顿。因此，交互业务除了观察平均值，还应记录高分位延迟，并检查慢请求是否集中在写入高峰、空间不足或后台任务期间。
寿命与写放大：写了多少，还要看怎样写
闪存的擦写承受能力有限，但 SSD 寿命不是简单的倒计时。设备可以把写入分散到不同区域，通过空间管理与纠错等机制维持可用性。温度、负载、介质特性和设备实现都会影响表现。对使用者而言，与其猜测某个单元还能写多少次，不如先读懂产品给出的写入耐久性指标，再结合业务写入量进行估算。
TBW 通常表示设备在规定条件下支持的累计写入数据量，产品也可能用 DWPD 表达耐久性。DWPD 表示在规定期间内，每天允许写入相当于多少个整盘容量。它们往往与质保条款关联，具体计量单位、期间和适用条件应以规格为准。达到指标不意味着设备必定立刻损坏，尚未达到指标也不能保证不会发生其他故障。耐久性额度和故障概率不是同一个概念。
设某设备容量按规格计为 1 TB，标称 1 DWPD，考察期间按 5 年、每年 365 天简化计算，则对应主机写入预算约为 1825 TB。这个换算只能在指标口径一致时使用。实际评估还要检查业务每天写入是否稳定，日志保留策略是否改变，数据库压缩与备份是否产生额外写入，以及维护期间是否出现集中重写。平均每天写得不多，并不代表短时写入性能一定够用。
写放大描述设备内部写入量与主机写入量的比值。例如主机写入 10 GiB，而闪存内部累计写入 25 GiB，在统计边界一致时，写放大为 2.5。有效数据搬迁、空间回收等动作会增加内部写入。不同访问模式会改变这个比例，因此不能把某次测试得出的写放大常数永久套用到所有负载。
需要特别区分设备内部写放大与应用层重复写入。数据库可能为了日志、索引和数据文件，把同一份业务变更写入多个位置。这些内容到达设备时，已经计入主机写入量；设备内部还可能继续产生额外搬运。估算寿命时，先测量相应统计边界的写入量。若 TBW 本来就是主机写入口径，就不应再把内部写放大乘上去与 TBW 直接比较，否则容易重复计算。
保留合理余量有助于设备管理空间，但“剩余多少就必定安全”没有通用阈值。应用可用空间、文件系统空闲空间以及 SSD 内部预留空间也不能直接画等号。应遵循产品与系统建议，持续观察空间占用和稳定负载下的延迟变化。对云盘而言，底层介质维护通常由服务商负责，使用者仍需关注公开的性能规则、服务限制、备份和恢复能力。
云盘规格：读出上限背后的条件
云盘把块设备能力通过服务提供给云主机。应用看到的是可以交给文件系统或数据库使用的逻辑块地址，背后可能经过网络、存储节点与多副本机制。因而“底层用了 SSD”只说明部分实现特征，不能独自解释端到端延迟、可用性和性能上限。判断云盘是否合适，应从公开规格和实际使用路径出发。
先看容量范围及扩容规则，再看 IOPS 与吞吐量是固定额度、随容量增长，还是能够单独配置。部分服务设置基础性能与突发性能，突发可能受额度积累、持续时间或其他条件约束。短时间测试如果恰好消耗突发额度，就可能高估长期能力。对连续运行的业务，应区分能够长期维持的水平与有条件出现的峰值。
其次看读写类型、请求大小和队列深度。规格中的随机读 IOPS、随机写 IOPS、混合读写表现并不必然相同，顺序吞吐量也需要明确测量条件。若只看到“最高”字样，应继续查找达到该值所需的容量、主机配置、并发和负载条件。缺少这些条件的数字可以帮助筛选产品，却不足以支撑最终容量与性能承诺。
还要检查云主机侧的总限制。某块云盘允许 20000 IOPS，不代表挂到任意主机都能达到。假设主机对该存储路径总共只允许 12000 IOPS，即使只挂这块盘，整条路径也会受到主机额度约束。若多块盘共享同一主机总额度，简单增加盘数仍可能没有收益。吞吐量也存在类似关系，而且 IOPS 与吞吐量必须分别核对，不能只取某张表中较醒目的数字。
可以用示例检查规格是否自洽。若云盘上限为 10000 IOPS、吞吐量上限为 250 MiB/s，那么 4 KiB 请求在 IOPS 上限处只传输约 39.06 MiB/s；64 KiB 请求则可能先达到带宽上限，此时理论完成速率约为 4000 IOPS。真实服务还可能规定请求拆分、计费操作尺寸或最大请求大小，示例只用于说明同时满足多个约束的方法。
最后读取持久性、可用性、快照、加密与计费规则。持久性关注数据丢失的风险，可用性关注服务能否在需要时访问；快照的创建、保留和恢复条件则决定恢复方案能否落地。承诺范围和使用前提需要明确。按容量付费、按配置性能付费或收取额外操作费用，会改变长期成本，不能只比较每 GB 的价格。物理盘与云盘的故障责任边界不同，方案应分别说明。
常见坑：把容量当成完整规格
另1个常见问题是用单次文件复制代表全部负载。复制大文件通常偏向顺序吞吐量，缓存还可能让短时速度高于介质持续能力。数据库中的 4 KiB 随机写、日志追加和批量扫描具有不同特征，不能用同一复制数字统一预测。测试报告应说明请求大小、读写比例、地址分布、并发、测试时长、数据集大小以及缓存和持久化条件，读者才能判断结果能否迁移。
缓存带来的提升是真实的，但它属于特定路径。数据命中主存缓存时，测到的延迟可能主要反映主存和软件；写入被缓存接受时，测到的也可能是接收速度。对需要确认持久化的业务，应检验完成条件是否与要求一致。为了得到漂亮数字而忽略刷新要求，会让测试回答不同的问题。这里不要求动手执行任何破坏性写盘测试，重点是能够辨认报告的边界。
还应避免把 SSD 寿命数字直接换算成业务可运行年数后就停止评估。设备故障、软件错误与恢复时间仍需要独立考虑。相似地，多副本并不免除备份，快照存在也不保证恢复时间满足目标。正确的读法是把性能、耐久性、可靠性和成本分别列出，再检查它们在同一业务场景中是否同时成立。
案例：小随机写为什么拖慢订单服务
设某订单服务把更新、日志和索引写入同一块云盘。业务高峰每秒产生 6000 次主机写请求，每次按 4 KiB 估算，另有约 2000 次相同大小的读取。平均总量约为 31.25 MiB/s。团队看到云盘标称 250 MiB/s，认为仍有大量余量，却发现写入确认越来越慢。这个判断忽略了每秒请求次数，也没有核对读写混合条件。
进一步检查发现，当前容量档位的持续性能只有 5000 IOPS，短时可以突发到更高水平。高峰到达速率约为 8000 次/秒，长期超过能够完成的速率，请求会持续积压。只要这个差距维持，排队就无法靠“再等片刻”自行消失。若每秒多积压约 3000 次请求，业务超时与重试还可能继续增加负载；真实系统的限流和超时会改变具体曲线。
分析应先统一观测边界。应用记录的是订单提交耗时，数据库记录的是日志与数据写入行为，操作系统记录的是块设备请求。它们的次数并不相同。团队需要确认每笔订单产生多少主机 I/O，读取是否命中缓存，写入完成是否要求持久化，并查看设备完成 IOPS、队列长度及 p99 延迟。这样才能区分盘的限制、主机总额度、软件串行等待和其他路径问题。
在该例中，若证据确认主要受云盘持续 IOPS 限制，可以选择提供足够持续 IOPS 的配置，并核对主机总额度。也可以评估合并写入、减少重复索引维护或调整日志路径，但这些改变必须保持事务与持久化要求。增加并发在设备已经饱和时不会创造额外能力；把写入确认改成更弱的语义虽然可能降低可见延迟，却改变了业务承诺，不能当成等价优化。
调整以后，应使用与高峰相符的读写混合负载持续观察，覆盖突发额度消耗、缓存变化及后台维护。验收既看完成速率是否跟上到达速率，也看队列是否稳定、p99 延迟是否满足目标，并检查故障后的恢复要求。这个案例的关键并非“SSD 必然够快”，而是从请求形态出发，找到实际约束，再验证改动是否解除了约束。
放进方案里
随后分别给出容量、持续 IOPS、持续吞吐量与延迟目标，并明确平均值和高分位值的统计窗口。容量预算应计入日志、索引、临时文件及维护余量；性能预算应覆盖高峰和必要的后台任务。不要用某个峰值指标代替全部约束。对于云盘，写明容量档位、性能配置和云主机总额度；对于物理 SSD，补充接口条件、耐久性口径以及持续写入的适用条件。
可靠性部分说明写入何时算成功、哪些故障由副本承受、哪些错误依靠备份恢复，以及允许丢失多少近期数据、能够接受多久恢复。把备份保留与恢复验证写入计划，并明确执行责任。若设备提供 TBW 或 DWPD，用相同统计口径的主机写入量估算余量，同时保留业务增长与维护任务带来的不确定性，不把耐久性额度写成绝对寿命保证。
验收部分选择与业务相近的请求大小、并发和读写组合，持续运行到足以观察稳定状态，记录完成速率、队列、平均与高分位延迟。写清缓存、突发额度和持久化条件，让结果可以解释。最后把费用、扩容方式和触发条件连接起来，例如持续高峰逼近性能预算或恢复时间超标时启动复评。这样形成的方案既能解释当前选择，也能支持业务变化后的调整。
把订单高峰写成可测数字再选盘：若高峰 40 笔订单/秒，每笔触发 3 次小随机写（约 4 KiB），主机侧约 120 IOPS；再加上每秒 20 次索引更新，合计约 140 IOPS。云盘标称“最高 3000 IOPS”若绑定突发桶，持续 10 分钟后可能掉到基线 300 IOPS——此时 140 IOPS 仍安全，但若活动价把写放大到 3×，有效写入接近 420 IOPS，就会顶穿基线。方案应写明：验收用 4 KiB 随机写跑满 15 分钟，记录第 1 分钟与第 15 分钟的完成速率，并核对实例总带宽上限。
小结：把设备机制带到 S5 与 H14
HDD 的小随机访问容易受寻道与旋转等待影响，顺序访问能够分摊机械定位成本。SSD 避免机械等待，却需要面对页读写、块擦除以及空间回收带来的内部工作。由此可以理解，访问模式改变时，同一块设备可能表现得很不一样；读写混合、空闲空间与持续运行条件，都可能影响最终看到的延迟和完成速率。
读规格时，把容量、IOPS、吞吐量、延迟与耐久性放在各自的位置。用请求大小连接 IOPS 和吞吐量，用稳定状态下的并发关系检查延迟是否合理，用 TBW 或 DWPD 理解规定条件下的写入预算。对云盘还要沿路径核对服务和主机的多层限制，避免把某个局部峰值当成整条路径的保证。
学完后，应能够解释为什么 4 KiB 随机写在带宽尚有余量时依然可能排队，为什么增加并发有时提高 IOPS、有时只增加延迟，以及为什么删除文件不等于立即擦除闪存。进入 S5 时，可以进一步追踪文件和目录怎样组织在块设备之上；进入 H14 时，则继续把本课建立的请求路径、单位与限制意识用于后续硬件分析。
本课采用公开存储规格中的通用概念，所有计算例子均为教学假设。实际采购和部署应核对目标产品当前的单位、测试条件、性能额度、耐久性及服务条款，并用符合业务路径的观测结果验证。
下一课转向 H14 PC 与服务器硬件：把本章验收过的结论带进后续主题，写成可检查的方案约束。