做存储这行时间久了会慢慢发现一个规律绝大多数存储出问题的现场故障本身并不复杂复杂的是大家对同一套概念用了不同的理解。有人拿着一块标称 8TB 的硬盘问为什么只有 7.28TB有人把数据库文件丢到网络共享目录里然后抱怨写入慢十倍也有人把 RAID 当成备份、把快照当成容灾直到真出事才发现根本没有可回滚的数据。这些坑我都踩过有些还踩了不止一次。这篇笔记想做的事情很简单把存储从容量怎么算到块、文件、对象怎么选再到RAID 与纠删码怎么算账压测怎么做换盘扩容怎么走流程应用侧的类型和会话该放哪这一整条链路串起来写成一份可以直接照着用的基础笔记。它不挑读者刚入门的人能补上概念拼图做过几年的人可以拿它当一份检查清单看看自己手上那套系统的哪一环其实一直是空着的。1. 容量对不上账这件事先把单位、开销和保留块算清楚只要是跟存储打交道的人第一个撞上的问题一定是数字不对。一块标称 8TB 的机械盘插上机器变成 7.28TB一块 512GB 的固态在系统里显示 476GB手机标称 256GB 可用只剩 220 多 GB。这三个缩水的幅度完全不一样成因也完全不同如果混在一起讨论很容易得出厂商虚标这种既对又不解决问题的结论。正确的做法是把它拆成三层来看单位换算带来的差异、文件系统格式化带来的开销、以及硬件本身预留的冗余空间。这三层叠加之后你能看到的可用容量就是最终那个看起来吃亏的数字而且它是可以被计算、被验证、甚至在部分场景下被要回来的。1.1 标称容量的两层账1000 与 1024硬盘和闪存厂商用的是十进制定义1KB 1000 字节1MB 1000KB1GB 1000MB1TB 1000GB。而操作系统尤其是 Windows习惯用二进制口径来显示1KiB 1024 字节1MiB 1024KiB层层递进之后两个口径之间的差距会随容量放大。换算关系其实就一个公式以 GiB 为单位的数字 以 GB 为单位的数字 × (10^9 / 2^30)也就是乘 0.9313。所以 8TB 标称盘在二进制口径下是 8 × 0.9313 ≈ 7.45TiB如果再把硬盘的 LBA 换算细节算进去落到 7.28TiB 左右完全正常。标称容量十进制二进制口径显示折算系数256GB约 238GiB0.9313512GB约 476GiB0.93131TB约 931GiB0.93134TB约 3.63TiB0.93138TB约 7.28TiB0.9100 左右含内部换算差异只到这一步减少的容量是口径问题不是真的丢了。真正需要警惕的是第二步如果你的业务做容量规划报价单上写的是 TB而监控系统里画的是 TiB两个数字长期混用你会在扩容时机上判断失误。我见过最典型的一次是某业务按监控里还有 15% 空间判断不用扩容实际按采购口径已经接近 90%结果赶在业务高峰期临时加盘。所以从第一天起就把单位统一采购口径写 TB监控口径写 TiB并在文档里注明换算系数。1.2 格式化之后缩水的部分去了哪里越过单位这一层接下来就是文件系统的开销。以 ext4 为例格式化时会做几件事写入超级块和备份超级块、分配 inode 表、划分日志区journal、以及默认预留 5% 的块给 root 使用。那个 5% 的预留是最容易被误判的一块 1TB 的盘被扣掉 5%就是凭空少了 50GB而它存在的理由是防止普通用户把文件系统写满导致系统进程无法写日志。如果你的场景是大容量纯数据盘且能接受写满即告警的运维方式完全可以用tune2fs -m 1 /dev/sdb1把预留降到 1%甚至 0把空间要回来。# 查看文件系统的块数、预留比例、inode 使用情况 tune2fs -l /dev/sdb1 | egrep Block count|Reserved block count|Inode count # 把 root 预留从 5% 调到 1% tune2fs -m 1 /dev/sdb1 # 查看各挂载点的真实可用空间与 inode 消耗 df -hT df -iXFS 的逻辑不同它没有可调的预留块比例但元数据占用会随目录数量和文件数增长NTFS 有 MFT主文件表和 $LogFile 日志文件小文件极多时 MFT 会明显膨胀。再往下就是硬件层的预留固态盘的 OPOver-Provisioning通常留 7% 左右用来做垃圾回收和磨损均衡手机和嵌入式设备上的 A/B 双分区方案、恢复分区、厂商定制分区也会吃掉可观的空间。真正该记住的经验是任何格式化后缩水的判断都要先问清楚是单位、是预留、是元数据还是分区占用四个原因对应四种完全不同的处理手段其中只有预留和分区是真有可能调整的。1.3 存储感知这类省空间功能到底要不要开Windows 上的存储感知、云盘的生命周期规则、应用自行设计的过期清理本质上都是同一类东西按时间或空间阈值自动删除文件。这类功能的价值和风险都很极端。在个人终端、临时文件堆积严重的开发机上打开它确实能省出几十 GB但在需要保留操作记录、需要事后追溯的机器上自动清理等于把证据链掐断。我的做法是分机器决策办公终端和测试终端默认开启只清理临时目录、回收站和缩略图缓存不碰用户文档服务器上彻底关闭系统级自动清理改为按业务语义做显式的归档策略比如日志按天归档到对象存储本地只留七天。这里有个细节值得单独提一句自动清理的时间阈值不要拍脑袋。如果你的备份周期是七天全量加每日增量而清理策略是删除 30 天内未访问的文件那没问题但如果清理策略是删除 7 天前的文件而增量备份只保留了 3 天中间就会形成一个谁也没注意到的数据空洞。清理阈值永远要大于等于备份保留周期这是条不需要论证的硬规则。2. 块、文件、对象三种形态它们各自解决的是哪一类麻烦存储领域最容易被讲玄乎的就是三种存储形态。剥掉包装之后其实很朴素块存储给你一块可以随机寻址的裸空间文件存储给你一棵有名字、有权限、有目录层级的树对象存储给你一个扁平的键值空间加 HTTP 接口。它们的差别不在高级程度而在于把管理的复杂度放在了谁身上——放在应用侧、放在存储系统侧还是放在中间这层协议栈上。选型时只要问一个问题就够了这个数据将来是被操作系统当文件打开还是被程序当字节流读写还是被 HTTP 客户端按 URL 取回答案指向哪个就用哪个。2.1 块存储把裸设备交给文件系统块存储暴露的是固定大小扇区的随机读写能力最小单位通常是 512 字节或 4KiB 的逻辑块。本地盘、直连阵列的 LUN、iSCSI 卷、云上的云硬盘本质都是块设备。它最大的特点是什么都不管不认文件名不认目录也不知道你写的是什么只保证第 N 个块写进去读出来还是那批字节。正因为语义最少它的开销也最小路径最短延迟最低所以数据库、虚拟机磁盘镜像、需要自己控制落盘顺序的应用几乎都跑在块设备上。代价是管理责任全部转移到你这边分区表怎么划、文件系统选什么、挂载参数怎么调、多路径怎么做、掉电后一致性怎么保证都得自己负责。我在生产上见过最省事也最危险的做法是把两个节点同时挂载同一个块设备不是集群文件系统就是普通 ext4两边都以为自己在写最后文件系统直接损坏。块设备不做仲裁谁挂谁写这个前提一旦被忽略后果就是数据不可恢复。2.2 文件存储NAS 与共享目录的天然边界文件存储补上了命名、目录、权限和锁让多个客户端可以通过 NFS 或 SMB 协议访问同一份数据。它的舒适区是共享文档、代码仓库、构建产物、媒体素材库这类人也要看、程序也要看的数据。但共享协议带来的复杂度是实打实的NFS 的 root_squash、SMB 的 ACL、两套权限模型混用时的映射错乱都是高频坑点。最常见的现场是 Linux 端用 NFS 挂载写文件Windows 端用 SMB 打开同一个目录然后出现文件属主变成 nobody、新文件无法覆盖、删除后仍占空间的现象。还有一个小白最容易忽略的点不要把数据库的数据目录放在网络文件共享上。数据库对 fsync 的语义有强依赖而 NFS 在缓存与提交语义上和本地文件系统不同轻则性能跌到本地盘的十分之一重则事务提交不落地掉电后数据错乱。共享存储适合放文件不适合放需要精确控制落盘顺序的数据结构。2.3 对象存储桶、键值与自建 MinIO 的取舍对象存储把一切都简化成三件事桶bucket作为命名空间键key作为唯一标识值value是任意二进制数据另外挂一组元数据。访问方式是 HTTP API没有目录树控制台上看到的文件夹只是键名里带斜杠的视觉效果没有原地修改只有整体覆盖。它的优势在于近乎无限的扩展性、天然的多副本或纠删码冗余、以及便宜——这是它成为图片、视频、备份归档、日志冷数据默认归宿的原因。自建对象存储时MinIO 是绕不开的选项单二进制、兼容 S3 接口、部署成本低几个节点就能跑起一套可用的服务。应用侧接入通常只需要配置 endpoint、AccessKey、SecretKey 和 region然后调用 SDK。Java 侧的典型装配大致是这样MinioClient client MinioClient.builder() .endpoint(http://10.0.0.12:9000) // 不要带桶名 .credentials(your-access-key, your-secret-key) .build(); // 小于 5MiB 的文件走单次上传大文件请走分片上传 boolean exists client.bucketExists( BucketExistsArgs.builder().bucket(assets).build()); if (!exists) { client.makeBucket(MakeBucketArgs.builder().bucket(assets).build()); } client.putObject(PutObjectArgs.builder() .bucket(assets) .object(2024/06/photo-001.jpg) .stream(inputStream, -1, 10 * 1024 * 1024) // 分片阈值 .contentType(image/jpeg) .build());配置上踩坑最多的三处endpoint 填了带桶名的路径导致签名校验失败AccessKey 权限给成了管理员业务被入侵后直接可控整桶大文件没走分片上传一个网络抖动就要从头再传。这三点后面第 7 章还会展开。2.4 用一张表把选型定下来把上面的判断揉成一张表实际选型时对着看基本不会跑偏维度块存储文件存储对象存储访问接口裸设备 / LUNNFS、SMBHTTP(S) / S3 API命名方式无块号路径名桶 键典型延迟最低中等较高含网络与协议扩展方式纵向为主纵向 集群近乎线性横向扩展适合数据数据库、虚拟机磁盘共享文档、媒体素材图片、备份、归档、日志主要责任方应用与运维存储系统 权限管理应用侧 SDK 使用一句话总结就是需要极致延迟和自主控制的用块需要多人共享和直观目录的用文件需要海量、便宜、能被 URL 直接访问的用对象。3. 从寄存器到磁带分层存储里的数量级直觉很多人做容量规划时只看还剩多少 TB从来不看这份数据放在哪一层。结果是热数据被塞进慢速大盘冷数据占着昂贵的全闪阵列两边都不划算。建立数量级直觉的价值在于当有人提出一个方案时你能立刻判断它在物理上是否可行——比如把 4K 随机读延迟压到 100 微秒以内并且全部放在机械盘上这种需求不用评估直接否掉。3.1 延迟、带宽、容量三个维度一起看下面这张表里的数字不必精确到个位记住量级就够了层级访问延迟量级容量量级特点CPU 寄存器 / L1纳秒级KB极快极小内存100 纳秒级GB ~ TB掉电即失NVMe 固态数十至数百微秒TB 级高 IOPSSATA 固态数百微秒TB 级性价比高机械硬盘数毫秒至十几毫秒数十 TB顺序吞吐好、随机差磁带 / 冷归档秒级至分钟级PB 级单位成本最低这张表解释了几件日常现象为什么 4K 随机写在机械盘上只有几百 IOPS而同样的盘做顺序大块写能跑到 200MB/s 以上为什么数据库的随机读一旦穿透缓存就会明显抖动为什么归档数据放对象存储的冷层是合理的而放全闪阵列是浪费。做分层的时候判断标准就一条这份数据的访问频率和延迟容忍度匹配哪一层。热数据、温数据、冷数据分开放比把所有数据塞进同一层高效得多也便宜得多。3.2 字节序大端与小端为什么会影响解析存储基础里有个知识点看起来偏底层但踩坑的人非常多就是字节序。多字节数值在内存和磁盘上排列时有两种约定高位字节在前叫大端Big-Endian低位字节在前叫小端Little-Endian。x86 与绝大多数 ARM 默认是小端网络协议规定统一用大端传输而某些嵌入式芯片、部分文件格式和工业协议用的是大端。问题就出在跨平台读写时如果写入方按小端把0x12345678存成78 56 34 12读取方按大端解析得到的就是完全不同的数。判断本机字节序最省事的办法是直接把一个整数按字节打印出来#include stdio.h int main(void) { unsigned int v 0x12345678; unsigned char *p (unsigned char *)v; printf(%02x %02x %02x %02x\n, p[0], p[1], p[2], p[3]); // 输出 78 56 34 12 即小端输出 12 34 56 78 即大端 return 0; }实操经验是凡是自己设计落盘格式或通信协议一律在文档里写明字节序并在读写代码里显式做转换读写固定用宏或函数别依赖编译器默认而不是反正两边都是同一款芯片。跨平台、跨语言、跨年代的场景里同一款芯片这个假设迟早会被打破。另外结构体直接按内存块写入文件是个经典陷阱因为编译器会插入填充字节不同编译器、不同对齐设置下结果不一致这类问题的排查成本极高。3.3 EEPROM 与 TF 卡擦写寿命决定了日志该怎么写嵌入式场景里的存储是另一套逻辑因为介质寿命成了设计约束。EEPROM 的擦写次数通常在十万到百万量级NOR Flash 约十万次SLC NAND 约十万次MLC 降到几千次TLC 通常只有一千到三千次。TF 卡更特殊它内部的控制器和磨损均衡策略你完全看不到标称寿命和实际表现差距很大尤其在频繁小写入的场景下会迅速退化。这直接决定了 MCU 的日志存储方案该怎么设计。如果每隔几十毫秒就往 EEPROM 或 TF 卡写一条日志寿命问题会在几周内暴露。可靠的做法有这么几种一是用环形缓冲区固定大小的块循环覆盖避免每次分配新块二是双区交替写A 区写满切 B 区擦除动作和写入动作错开减少擦写次数三是只记录变化量或事件而不是周期性记录全量状态四是在 RAM 里做聚合达到一定条数或一定时间再批量落盘同时配合掉电检测把未落盘的数据保护起来。提示TF 卡上跑长时间日志记录务必单独留一个只写日志的分区并定期校验文件系统一致性。整卡用于日志、同时被系统频繁读写配置文件的方案出问题只是时间早晚。4. RAID、副本与纠删码冗余的账要算明白冗余是存储里最容易想当然的部分。很多人知道 RAID 5 能坏一块盘但不知道重建一块大容量机械盘时失败的概率有多高很多人知道对象存储有三副本但不知道三副本意味着三倍成本更多人把快照当成备份把备份当成容灾直到真出事才发现层次全错。这一章把这几笔账用能算的方式摊开。4.1 常见 RAID 级别的可用容量与风险先看容量公式这是最直观的级别最少盘数可用容量容错能力备注RAID 02N × 单盘无性能最高坏一块全丢RAID 12N/2 × 单盘坏 1 块镜像对写放大明显成本高RAID 53(N-1) × 单盘坏 1 块写惩罚重建压力大RAID 64(N-2) × 单盘坏 2 块安全冗余更足写性能低RAID 104N/2 × 单盘视镜像对而定随机写性能好利用率 50%真正的关键是重建风险。机械盘的不可恢复读错误率通常在 10^14 比特量级换算过来大约是每读取 12.5TB 数据遇到一次不可恢复错误。这意味着一个由多块大容量盘组成的 RAID 5在重建过程中需要读遍所有剩余盘的全部数据一旦在重建期间碰到读错误整组就会丢失。容量越大、盘越多这个概率越高。所以容量密度上来之后RAID 5 在大盘阵列上已经不太适合了RAID 6 或 RAID 10 是更现实的选择——多花一块盘的容量换一次真正能扛住的故障。还有一个容易被忽略的操作细节重建期间不要同时跑大批量备份或全量校验也不要安排其他维护动作让重建独占 IO。我见过为了节省时间一边重建一边做数据迁移结果重建时间被拉长三倍反而增加了风险窗口。4.2 分布式存储的三副本与纠删码分布式存储把冗余从盘与盘抬到节点与节点。多副本是最直观的方案每份数据存三份落在三个不同节点最好跨机架、跨故障域任意一个节点挂掉都不影响读取读写路径也简单。代价是 3 倍原始容量开销。纠删码EC走的是另一条路把数据切成 K 个数据块再算出 M 个校验块总存储是 (KM)/K 倍。比如 83 的配置冗余开销只有 37.5%能容忍任意 3 个块丢失容量效率远高于三副本。但纠删码的读取需要同时拉取多个块并做计算延迟高、重建时的网络与 CPU 开销也大所以常见做法是分层热数据用多副本保证体验冷数据用纠删码降低成本。这里有个运维侧的经验分布式存储的池pool创建、节点扩容、故障域划分绝大多数操作都是通过命令行在节点上完成的SSH 登录某个管理节点后按集群工具的命令建池、加盘、调整 CRUSH 规则或副本数。操作前必须确认三件事——当前的副本策略是什么、新增节点的故障域标签是否正确、池的 PG 数量是否与目标规模匹配。这三件事任意一件没确认就动手后续要花几倍时间收拾。4.3 快照、备份、容灾三者不能互相替代这一节没有技术难点但它是所有事故复盘里出镜率最高的认知错误。快照是某个时间点上数据状态的引用它快、省空间但通常和源数据在同一个存储系统里源系统损坏时快照一起没。备份是把数据复制到另一套独立介质上能应对误删除和逻辑损坏但恢复时间长。容灾是在异地或另一套环境里保持一份可接管的服务能力应对的是整机房级别的故障。三者对应三种不同的失效模式误删靠备份介质损坏靠冗余机房级故障靠容灾。用快照代替备份等于把全部希望押在同一套硬件上。判断标准很简单如果这套存储整体消失我还能不能把数据拿回来需要多久。答不上来就说明备份这条链是断的。5. 上线前压测与日常巡检存储性能到底怎么测存储性能这件事最怕两种极端一种是不测上线后靠用户投诉来发现问题另一种是乱测用顺序大块写的漂亮数字去支撑一个随机小 IO 的业务结果自然对不上。压测的目标从来不是跑出最高分而是搞清楚在我真实的访问模式下这套存储能稳定跑成什么样拐点在哪里。5.1 fio 思路块大小、队列深度、读写比例用 fio 之前先把业务特征翻译成四个参数块大小、读写比例、并发深度、访问模式顺序还是随机。数据库联机事务基本是 4K 或 8K 随机读为主混合少量写视频转码是大块顺序读写日志写入是追加式的顺序小块写。把业务翻译错了测出来的数就没有参考价值。一个可用的起点配置如下[global] ioenginelibaio direct1 # 绕过页缓存测到真实介质性能 time_based1 runtime300 # 单场景至少跑 5 分钟看稳态而非峰值 group_reporting1 filename/dev/sdb # 压测裸盘请格外小心会覆盖数据 size32G [rand-read-4k] rwrandread bs4k iodepth32 numjobs4 [seq-write-1m] rwwrite bs1m iodepth16 numjobs1几个必须注意的点direct1一定要开否则测的是内存速度runtime要够长前几十秒的突发性能不代表稳态filename指向裸盘会直接破坏数据生产环境务必用文件或独立测试盘或者干脆用测试环境跑之前确认盘上没挂载文件系统。压测的产出不是单一数字而是一组曲线随着队列深度增加IOPS 上升、单次延迟也上升当延迟开始非线性恶化时那个点就是这台设备的实际工作上限比标称峰值有参考价值得多。5.2 应用内存储写入测试该关注什么移动端或客户端应用做本地存储压测关注点和服务器完全不同。手机的内部存储是闪存关键指标有三个持续写入速度会不会掉、掉速后稳定在什么水平、以及长期小文件高频写会不会导致闪存寿命与文件系统退化。测试方法是持续写入固定大小的文件并计时同时观察写入过程中的速度曲线很多设备在前几十秒能跑到很高的速度之后因为缓存耗尽和垃圾回收介入速度会掉到几分之一这个稳态速度才是用户实际感受到的。实践心得是App 的本地存储尽量不要用大量小文件堆叠能合并的合并能用追加写日志的别用频繁随机改写。小文件的元数据开销在闪存上格外明显还会加速文件系统碎片化。如果业务本身就需要频繁写状态考虑用追加式日志加定期压缩而不是每次改一行就重写整个文件。5.3 巡检要看的几个数与常见告警巡检不用追求指标全抓住几个关键的就够了容量水位建议 80% 告警、90% 必须处理、IOPS 与吞吐的长期趋势、平均与尾延迟、介质健康度SMART 的重分配扇区、待处理扇区、通电时间、以及 RAID 或副本的降级状态。其中尾延迟如 P99比平均值重要得多平均延迟漂亮但 P99 抖到几百毫秒的系统用户体验一定不好。告警项里最需要提前设计阈值的是重建中和降级。这两种状态本身不是故障但它们意味着系统已经失去了部分冗余此时任何一块盘再出问题就是数据丢失。所以这两种状态应该触发最高优先级通知而不是当成普通信息忽略掉。6. 扩容、换盘与故障排查的实操链路存储运维里最考验人的不是日常巡检而是扩容和换盘这两类需要动手的操作。它们共同的特点是操作本身不难但前置检查、过程中的判断、以及失败后的回退路径决定了这次操作是顺利还是事故。6.1 扩容前的容量规划与水位线扩容决策不该等到空间见红才做。合理的节奏是按增长速率倒推先看最近 90 天的容量增长曲线算出日均增长量再用剩余可用空间 / 日均增长得到安全天数。如果这个天数低于采购和上架所需周期很多时候是两到四周现在就该启动了。除了总容量还要关注单一目录、单一用户、单一库表的增长异常局部膨胀往往比整体增长更危险。水位线建议分三档管理70% 时开始规划80% 时触发告警并提交采购90% 时启动应急清理或扩容95% 以上属于高危此时连日志写入都可能失败。另外提醒一句扩容并不总是加盘这么简单块设备加盘可能涉及阵列的 RAID 组扩展或新建卷分布式存储加节点可能涉及数据重平衡对象存储加节点会触发大量副本迁移。这些动作都会抢占带宽和 IO必须安排在业务低峰期并预留出比理论时间长一倍以上的窗口。6.2 集中式阵列更换硬盘的完整流程集中式存储换盘是典型的高风险低难度操作。一块坏盘插进去阵列开始重建正常情况下几小时到几十小时不等。流程上我建议按这个顺序走先确认告警对应的物理槽位与真实位置一致很多事故源于拔错了盘再确认阵列当前状态是否降级、是否有其他盘处于预警状态接着确认热备盘是否已经顶替、重建是否已经开始最后才去动硬件。如果阵列还有热备盘可用其实不需要人工干预换盘插入新盘后系统会自动回拷把盘留在原位等回拷完成反而更稳。动手时几个细节拔盘前先通过管理界面确认盘已从阵列中剔除或离线别在阵列还认为它在线时直接拔换盘期间不要同时做其他维护插入新盘后确认它被识别为同一类型或兼容型号有些平台对混合型号会拒绝入组。曾经有个现场是换盘后重建一直停在某个百分比最后查到是因为机柜里同时换了两块不同类型盘其中一块被判定为不兼容而没有真正参与重建。6.3 排查顺序从链路到介质别一上来就换盘存储问题排查最常见的坏习惯是拿到告警就直接怀疑硬件、准备换盘。实际上从上到下的顺序能省掉大量无用功先看告警本身描述的是什么容量、延迟、介质错误、链路闪断再看是不是业务侧的变化引起的新上的批处理、突增的写入、误配的定时任务接着看链路层多路径状态、交换机端口错包、HBA 日志最后才落到介质层SMART 数据、阵列控制器日志。举个系统盘侧的常见例子Windows 上提示组件存储损坏这属于系统组件库层面的问题不是物理盘坏了先尝试用系统的修复命令扫描并修复系统映像再决定要不要动硬件。同理遇到蓝屏事件日志里出现存储相关的记录先确认是内存、驱动还是介质问题别急着换盘。桌面端还有一类高频问题是大缓存应用比如地理信息类软件默认把缓存写到系统盘导致 C 盘迅速吃满这类问题改一次默认存储路径就能解决跟硬件一点关系没有。再比如存储型 XSS 这类问题看起来和存储无关其实是被存储的内容在展示环节没有做处理。用户上传的文件名、描述、备注被原样渲染到页面上就会形成长期存在的脚本注入点。处理办法是在入库和渲染两个环节都做转义与白名单校验上传的文件名建议统一重命名原始名称只作为元数据保存。这类问题的修复成本远低于事后清理。7. 应用侧最容易搞错的几件事类型、会话与上传前面几章讲的是存储系统本身最后这一章聊应用怎么用存储。这里的问题往往不体现在存储指标上而是以数据库膨胀异常服务重启后任务丢失上传大文件老失败的形式冒出来排查时容易往基础设施方向找实际根因在代码里。7.1 整数类型的选择不是随便挑数据库里存整数用什么类型看着是小事实际直接影响索引体积、内存占用和查询性能。以 MySQL 为例常用整数类型和取值范围如下类型字节数有符号范围无符号范围TINYINT1-128 ~ 1270 ~ 255SMALLINT2-32768 ~ 327670 ~ 65535MEDIUMINT3约 -838 万 ~ 838 万0 ~ 1677 万INT4约 -21 亿 ~ 21 亿0 ~ 42 亿BIGINT8约 ±9.22 × 10^180 ~ 1.844 × 10^19选择原则很简单按业务上限选最小的够用类型并优先用无符号来扩大取值上限。状态码、类型标识、小范围计数用 TINYINT用户 ID、自增主键在可预见范围内用 INT只有涉及分布式 ID、时间戳毫秒值、大额计数时才用 BIGINT。这个选择不是微优化一张千万级表上把主键从 BIGINT 改成 INT索引体积能明显下降缓冲池命中率随之提升。代价是迁移成本所以最好在建模阶段就定下来。7.2 会话与异步结果该放哪会话数据和异步任务结果这两类数据的共同点是有明确的生命周期可以丢但丢了会影响体验。把会话直接放在应用进程内存里单机没问题一扩容成多实例就会出现用户一会儿登录一会儿掉线的诡异现象根因是请求被负载均衡打到了不同实例。解决办法是把会话外置到共享存储Redis 是最常见的选择同时根据业务设置合理的过期时间避免无人清理的会话堆积。异步任务同理。任务生产者把任务投递到消息队列工作进程消费完后需要把结果写到某个地方供查询这就是结果后端。可选方案有消息中间件本身、Redis、以及关系型数据库差别在于持久性、查询能力和运维复杂度。结果数据通常要设置过期时间否则结果表会无限增长成为存储增长曲线里最不好解释的那一段。经验做法是结果保留期略大于业务侧可能的查询窗口比如异步导出类任务结果保留 24 到 72 小时而不是永久保留。7.3 直传对象存储的配置要点与上传踩坑最后聊对象存储的应用侧接入。生产上推荐的模式是客户端直传服务端只负责签发临时凭证或预签名 URL这样大文件流量不经过业务服务器能显著降低带宽和 CPU 压力。配置上有几个必须确认的点endpoint 只写到主机和端口不要带桶名签名区域与桶所在区域一致临时凭证的有效期要覆盖最长上传时间且权限收敛到只能写指定前缀大文件必须走分片上传单片大小、并发数、失败重试策略要在客户端明确配置。踩坑清单里排第一的是权限过宽为了省事给业务方一个管理员凭证一旦凭证泄漏整个存储桶可以任人读写删。第二是分片上传中断后没有清理残留分片这些看不见的分片会一直占空间账单上表现为存储用量比实际文件大很多处理办法是配置生命周期规则自动清理未完成的分片。第三是把对象存储当成可以频繁覆盖写的地方对象存储的覆盖语义是整体重写不是原地修改高频小改动应该聚合后再上传。还有个容易被忽视的细节桶的公开访问策略。素材类文件需要外部直接访问时用独立的只读桶或 CDN 回源别把含业务数据的桶直接放开。所有用户可控的内容文件名、自定义描述、富文本备注在展示前统一转义这是防存储型注入最基础也最有效的一步。我个人在这条路上踩得最深的一次是早期给小团队搭对象存储时把 AccessKey 写死在客户端里觉得反正是内网。后来内网被一台被入侵的开发机横穿密钥被拿去遍历了整个桶好在桶里只是构建产物损失有限。从那之后我给自己定了一条规矩任何密钥都不进客户端、不进代码仓库只走临时凭证任何桶的权限都从最小开始不够再加。这条规矩看起来麻烦但它把一次可能致命的失误压缩成了一次可控的小事故。密钥轮换的周期也别定得太长三个月一次是最低要求涉及核心数据的桶更应该缩短到一个月。 从容量换算到块/文件/对象：存储基础与运维实战笔记
做存储这行时间久了会慢慢发现一个规律绝大多数存储出问题的现场故障本身并不复杂复杂的是大家对同一套概念用了不同的理解。有人拿着一块标称 8TB 的硬盘问为什么只有 7.28TB有人把数据库文件丢到网络共享目录里然后抱怨写入慢十倍也有人把 RAID 当成备份、把快照当成容灾直到真出事才发现根本没有可回滚的数据。这些坑我都踩过有些还踩了不止一次。这篇笔记想做的事情很简单把存储从容量怎么算到块、文件、对象怎么选再到RAID 与纠删码怎么算账压测怎么做换盘扩容怎么走流程应用侧的类型和会话该放哪这一整条链路串起来写成一份可以直接照着用的基础笔记。它不挑读者刚入门的人能补上概念拼图做过几年的人可以拿它当一份检查清单看看自己手上那套系统的哪一环其实一直是空着的。1. 容量对不上账这件事先把单位、开销和保留块算清楚只要是跟存储打交道的人第一个撞上的问题一定是数字不对。一块标称 8TB 的机械盘插上机器变成 7.28TB一块 512GB 的固态在系统里显示 476GB手机标称 256GB 可用只剩 220 多 GB。这三个缩水的幅度完全不一样成因也完全不同如果混在一起讨论很容易得出厂商虚标这种既对又不解决问题的结论。正确的做法是把它拆成三层来看单位换算带来的差异、文件系统格式化带来的开销、以及硬件本身预留的冗余空间。这三层叠加之后你能看到的可用容量就是最终那个看起来吃亏的数字而且它是可以被计算、被验证、甚至在部分场景下被要回来的。1.1 标称容量的两层账1000 与 1024硬盘和闪存厂商用的是十进制定义1KB 1000 字节1MB 1000KB1GB 1000MB1TB 1000GB。而操作系统尤其是 Windows习惯用二进制口径来显示1KiB 1024 字节1MiB 1024KiB层层递进之后两个口径之间的差距会随容量放大。换算关系其实就一个公式以 GiB 为单位的数字 以 GB 为单位的数字 × (10^9 / 2^30)也就是乘 0.9313。所以 8TB 标称盘在二进制口径下是 8 × 0.9313 ≈ 7.45TiB如果再把硬盘的 LBA 换算细节算进去落到 7.28TiB 左右完全正常。标称容量十进制二进制口径显示折算系数256GB约 238GiB0.9313512GB约 476GiB0.93131TB约 931GiB0.93134TB约 3.63TiB0.93138TB约 7.28TiB0.9100 左右含内部换算差异只到这一步减少的容量是口径问题不是真的丢了。真正需要警惕的是第二步如果你的业务做容量规划报价单上写的是 TB而监控系统里画的是 TiB两个数字长期混用你会在扩容时机上判断失误。我见过最典型的一次是某业务按监控里还有 15% 空间判断不用扩容实际按采购口径已经接近 90%结果赶在业务高峰期临时加盘。所以从第一天起就把单位统一采购口径写 TB监控口径写 TiB并在文档里注明换算系数。1.2 格式化之后缩水的部分去了哪里越过单位这一层接下来就是文件系统的开销。以 ext4 为例格式化时会做几件事写入超级块和备份超级块、分配 inode 表、划分日志区journal、以及默认预留 5% 的块给 root 使用。那个 5% 的预留是最容易被误判的一块 1TB 的盘被扣掉 5%就是凭空少了 50GB而它存在的理由是防止普通用户把文件系统写满导致系统进程无法写日志。如果你的场景是大容量纯数据盘且能接受写满即告警的运维方式完全可以用tune2fs -m 1 /dev/sdb1把预留降到 1%甚至 0把空间要回来。# 查看文件系统的块数、预留比例、inode 使用情况 tune2fs -l /dev/sdb1 | egrep Block count|Reserved block count|Inode count # 把 root 预留从 5% 调到 1% tune2fs -m 1 /dev/sdb1 # 查看各挂载点的真实可用空间与 inode 消耗 df -hT df -iXFS 的逻辑不同它没有可调的预留块比例但元数据占用会随目录数量和文件数增长NTFS 有 MFT主文件表和 $LogFile 日志文件小文件极多时 MFT 会明显膨胀。再往下就是硬件层的预留固态盘的 OPOver-Provisioning通常留 7% 左右用来做垃圾回收和磨损均衡手机和嵌入式设备上的 A/B 双分区方案、恢复分区、厂商定制分区也会吃掉可观的空间。真正该记住的经验是任何格式化后缩水的判断都要先问清楚是单位、是预留、是元数据还是分区占用四个原因对应四种完全不同的处理手段其中只有预留和分区是真有可能调整的。1.3 存储感知这类省空间功能到底要不要开Windows 上的存储感知、云盘的生命周期规则、应用自行设计的过期清理本质上都是同一类东西按时间或空间阈值自动删除文件。这类功能的价值和风险都很极端。在个人终端、临时文件堆积严重的开发机上打开它确实能省出几十 GB但在需要保留操作记录、需要事后追溯的机器上自动清理等于把证据链掐断。我的做法是分机器决策办公终端和测试终端默认开启只清理临时目录、回收站和缩略图缓存不碰用户文档服务器上彻底关闭系统级自动清理改为按业务语义做显式的归档策略比如日志按天归档到对象存储本地只留七天。这里有个细节值得单独提一句自动清理的时间阈值不要拍脑袋。如果你的备份周期是七天全量加每日增量而清理策略是删除 30 天内未访问的文件那没问题但如果清理策略是删除 7 天前的文件而增量备份只保留了 3 天中间就会形成一个谁也没注意到的数据空洞。清理阈值永远要大于等于备份保留周期这是条不需要论证的硬规则。2. 块、文件、对象三种形态它们各自解决的是哪一类麻烦存储领域最容易被讲玄乎的就是三种存储形态。剥掉包装之后其实很朴素块存储给你一块可以随机寻址的裸空间文件存储给你一棵有名字、有权限、有目录层级的树对象存储给你一个扁平的键值空间加 HTTP 接口。它们的差别不在高级程度而在于把管理的复杂度放在了谁身上——放在应用侧、放在存储系统侧还是放在中间这层协议栈上。选型时只要问一个问题就够了这个数据将来是被操作系统当文件打开还是被程序当字节流读写还是被 HTTP 客户端按 URL 取回答案指向哪个就用哪个。2.1 块存储把裸设备交给文件系统块存储暴露的是固定大小扇区的随机读写能力最小单位通常是 512 字节或 4KiB 的逻辑块。本地盘、直连阵列的 LUN、iSCSI 卷、云上的云硬盘本质都是块设备。它最大的特点是什么都不管不认文件名不认目录也不知道你写的是什么只保证第 N 个块写进去读出来还是那批字节。正因为语义最少它的开销也最小路径最短延迟最低所以数据库、虚拟机磁盘镜像、需要自己控制落盘顺序的应用几乎都跑在块设备上。代价是管理责任全部转移到你这边分区表怎么划、文件系统选什么、挂载参数怎么调、多路径怎么做、掉电后一致性怎么保证都得自己负责。我在生产上见过最省事也最危险的做法是把两个节点同时挂载同一个块设备不是集群文件系统就是普通 ext4两边都以为自己在写最后文件系统直接损坏。块设备不做仲裁谁挂谁写这个前提一旦被忽略后果就是数据不可恢复。2.2 文件存储NAS 与共享目录的天然边界文件存储补上了命名、目录、权限和锁让多个客户端可以通过 NFS 或 SMB 协议访问同一份数据。它的舒适区是共享文档、代码仓库、构建产物、媒体素材库这类人也要看、程序也要看的数据。但共享协议带来的复杂度是实打实的NFS 的 root_squash、SMB 的 ACL、两套权限模型混用时的映射错乱都是高频坑点。最常见的现场是 Linux 端用 NFS 挂载写文件Windows 端用 SMB 打开同一个目录然后出现文件属主变成 nobody、新文件无法覆盖、删除后仍占空间的现象。还有一个小白最容易忽略的点不要把数据库的数据目录放在网络文件共享上。数据库对 fsync 的语义有强依赖而 NFS 在缓存与提交语义上和本地文件系统不同轻则性能跌到本地盘的十分之一重则事务提交不落地掉电后数据错乱。共享存储适合放文件不适合放需要精确控制落盘顺序的数据结构。2.3 对象存储桶、键值与自建 MinIO 的取舍对象存储把一切都简化成三件事桶bucket作为命名空间键key作为唯一标识值value是任意二进制数据另外挂一组元数据。访问方式是 HTTP API没有目录树控制台上看到的文件夹只是键名里带斜杠的视觉效果没有原地修改只有整体覆盖。它的优势在于近乎无限的扩展性、天然的多副本或纠删码冗余、以及便宜——这是它成为图片、视频、备份归档、日志冷数据默认归宿的原因。自建对象存储时MinIO 是绕不开的选项单二进制、兼容 S3 接口、部署成本低几个节点就能跑起一套可用的服务。应用侧接入通常只需要配置 endpoint、AccessKey、SecretKey 和 region然后调用 SDK。Java 侧的典型装配大致是这样MinioClient client MinioClient.builder() .endpoint(http://10.0.0.12:9000) // 不要带桶名 .credentials(your-access-key, your-secret-key) .build(); // 小于 5MiB 的文件走单次上传大文件请走分片上传 boolean exists client.bucketExists( BucketExistsArgs.builder().bucket(assets).build()); if (!exists) { client.makeBucket(MakeBucketArgs.builder().bucket(assets).build()); } client.putObject(PutObjectArgs.builder() .bucket(assets) .object(2024/06/photo-001.jpg) .stream(inputStream, -1, 10 * 1024 * 1024) // 分片阈值 .contentType(image/jpeg) .build());配置上踩坑最多的三处endpoint 填了带桶名的路径导致签名校验失败AccessKey 权限给成了管理员业务被入侵后直接可控整桶大文件没走分片上传一个网络抖动就要从头再传。这三点后面第 7 章还会展开。2.4 用一张表把选型定下来把上面的判断揉成一张表实际选型时对着看基本不会跑偏维度块存储文件存储对象存储访问接口裸设备 / LUNNFS、SMBHTTP(S) / S3 API命名方式无块号路径名桶 键典型延迟最低中等较高含网络与协议扩展方式纵向为主纵向 集群近乎线性横向扩展适合数据数据库、虚拟机磁盘共享文档、媒体素材图片、备份、归档、日志主要责任方应用与运维存储系统 权限管理应用侧 SDK 使用一句话总结就是需要极致延迟和自主控制的用块需要多人共享和直观目录的用文件需要海量、便宜、能被 URL 直接访问的用对象。3. 从寄存器到磁带分层存储里的数量级直觉很多人做容量规划时只看还剩多少 TB从来不看这份数据放在哪一层。结果是热数据被塞进慢速大盘冷数据占着昂贵的全闪阵列两边都不划算。建立数量级直觉的价值在于当有人提出一个方案时你能立刻判断它在物理上是否可行——比如把 4K 随机读延迟压到 100 微秒以内并且全部放在机械盘上这种需求不用评估直接否掉。3.1 延迟、带宽、容量三个维度一起看下面这张表里的数字不必精确到个位记住量级就够了层级访问延迟量级容量量级特点CPU 寄存器 / L1纳秒级KB极快极小内存100 纳秒级GB ~ TB掉电即失NVMe 固态数十至数百微秒TB 级高 IOPSSATA 固态数百微秒TB 级性价比高机械硬盘数毫秒至十几毫秒数十 TB顺序吞吐好、随机差磁带 / 冷归档秒级至分钟级PB 级单位成本最低这张表解释了几件日常现象为什么 4K 随机写在机械盘上只有几百 IOPS而同样的盘做顺序大块写能跑到 200MB/s 以上为什么数据库的随机读一旦穿透缓存就会明显抖动为什么归档数据放对象存储的冷层是合理的而放全闪阵列是浪费。做分层的时候判断标准就一条这份数据的访问频率和延迟容忍度匹配哪一层。热数据、温数据、冷数据分开放比把所有数据塞进同一层高效得多也便宜得多。3.2 字节序大端与小端为什么会影响解析存储基础里有个知识点看起来偏底层但踩坑的人非常多就是字节序。多字节数值在内存和磁盘上排列时有两种约定高位字节在前叫大端Big-Endian低位字节在前叫小端Little-Endian。x86 与绝大多数 ARM 默认是小端网络协议规定统一用大端传输而某些嵌入式芯片、部分文件格式和工业协议用的是大端。问题就出在跨平台读写时如果写入方按小端把0x12345678存成78 56 34 12读取方按大端解析得到的就是完全不同的数。判断本机字节序最省事的办法是直接把一个整数按字节打印出来#include stdio.h int main(void) { unsigned int v 0x12345678; unsigned char *p (unsigned char *)v; printf(%02x %02x %02x %02x\n, p[0], p[1], p[2], p[3]); // 输出 78 56 34 12 即小端输出 12 34 56 78 即大端 return 0; }实操经验是凡是自己设计落盘格式或通信协议一律在文档里写明字节序并在读写代码里显式做转换读写固定用宏或函数别依赖编译器默认而不是反正两边都是同一款芯片。跨平台、跨语言、跨年代的场景里同一款芯片这个假设迟早会被打破。另外结构体直接按内存块写入文件是个经典陷阱因为编译器会插入填充字节不同编译器、不同对齐设置下结果不一致这类问题的排查成本极高。3.3 EEPROM 与 TF 卡擦写寿命决定了日志该怎么写嵌入式场景里的存储是另一套逻辑因为介质寿命成了设计约束。EEPROM 的擦写次数通常在十万到百万量级NOR Flash 约十万次SLC NAND 约十万次MLC 降到几千次TLC 通常只有一千到三千次。TF 卡更特殊它内部的控制器和磨损均衡策略你完全看不到标称寿命和实际表现差距很大尤其在频繁小写入的场景下会迅速退化。这直接决定了 MCU 的日志存储方案该怎么设计。如果每隔几十毫秒就往 EEPROM 或 TF 卡写一条日志寿命问题会在几周内暴露。可靠的做法有这么几种一是用环形缓冲区固定大小的块循环覆盖避免每次分配新块二是双区交替写A 区写满切 B 区擦除动作和写入动作错开减少擦写次数三是只记录变化量或事件而不是周期性记录全量状态四是在 RAM 里做聚合达到一定条数或一定时间再批量落盘同时配合掉电检测把未落盘的数据保护起来。提示TF 卡上跑长时间日志记录务必单独留一个只写日志的分区并定期校验文件系统一致性。整卡用于日志、同时被系统频繁读写配置文件的方案出问题只是时间早晚。4. RAID、副本与纠删码冗余的账要算明白冗余是存储里最容易想当然的部分。很多人知道 RAID 5 能坏一块盘但不知道重建一块大容量机械盘时失败的概率有多高很多人知道对象存储有三副本但不知道三副本意味着三倍成本更多人把快照当成备份把备份当成容灾直到真出事才发现层次全错。这一章把这几笔账用能算的方式摊开。4.1 常见 RAID 级别的可用容量与风险先看容量公式这是最直观的级别最少盘数可用容量容错能力备注RAID 02N × 单盘无性能最高坏一块全丢RAID 12N/2 × 单盘坏 1 块镜像对写放大明显成本高RAID 53(N-1) × 单盘坏 1 块写惩罚重建压力大RAID 64(N-2) × 单盘坏 2 块安全冗余更足写性能低RAID 104N/2 × 单盘视镜像对而定随机写性能好利用率 50%真正的关键是重建风险。机械盘的不可恢复读错误率通常在 10^14 比特量级换算过来大约是每读取 12.5TB 数据遇到一次不可恢复错误。这意味着一个由多块大容量盘组成的 RAID 5在重建过程中需要读遍所有剩余盘的全部数据一旦在重建期间碰到读错误整组就会丢失。容量越大、盘越多这个概率越高。所以容量密度上来之后RAID 5 在大盘阵列上已经不太适合了RAID 6 或 RAID 10 是更现实的选择——多花一块盘的容量换一次真正能扛住的故障。还有一个容易被忽略的操作细节重建期间不要同时跑大批量备份或全量校验也不要安排其他维护动作让重建独占 IO。我见过为了节省时间一边重建一边做数据迁移结果重建时间被拉长三倍反而增加了风险窗口。4.2 分布式存储的三副本与纠删码分布式存储把冗余从盘与盘抬到节点与节点。多副本是最直观的方案每份数据存三份落在三个不同节点最好跨机架、跨故障域任意一个节点挂掉都不影响读取读写路径也简单。代价是 3 倍原始容量开销。纠删码EC走的是另一条路把数据切成 K 个数据块再算出 M 个校验块总存储是 (KM)/K 倍。比如 83 的配置冗余开销只有 37.5%能容忍任意 3 个块丢失容量效率远高于三副本。但纠删码的读取需要同时拉取多个块并做计算延迟高、重建时的网络与 CPU 开销也大所以常见做法是分层热数据用多副本保证体验冷数据用纠删码降低成本。这里有个运维侧的经验分布式存储的池pool创建、节点扩容、故障域划分绝大多数操作都是通过命令行在节点上完成的SSH 登录某个管理节点后按集群工具的命令建池、加盘、调整 CRUSH 规则或副本数。操作前必须确认三件事——当前的副本策略是什么、新增节点的故障域标签是否正确、池的 PG 数量是否与目标规模匹配。这三件事任意一件没确认就动手后续要花几倍时间收拾。4.3 快照、备份、容灾三者不能互相替代这一节没有技术难点但它是所有事故复盘里出镜率最高的认知错误。快照是某个时间点上数据状态的引用它快、省空间但通常和源数据在同一个存储系统里源系统损坏时快照一起没。备份是把数据复制到另一套独立介质上能应对误删除和逻辑损坏但恢复时间长。容灾是在异地或另一套环境里保持一份可接管的服务能力应对的是整机房级别的故障。三者对应三种不同的失效模式误删靠备份介质损坏靠冗余机房级故障靠容灾。用快照代替备份等于把全部希望押在同一套硬件上。判断标准很简单如果这套存储整体消失我还能不能把数据拿回来需要多久。答不上来就说明备份这条链是断的。5. 上线前压测与日常巡检存储性能到底怎么测存储性能这件事最怕两种极端一种是不测上线后靠用户投诉来发现问题另一种是乱测用顺序大块写的漂亮数字去支撑一个随机小 IO 的业务结果自然对不上。压测的目标从来不是跑出最高分而是搞清楚在我真实的访问模式下这套存储能稳定跑成什么样拐点在哪里。5.1 fio 思路块大小、队列深度、读写比例用 fio 之前先把业务特征翻译成四个参数块大小、读写比例、并发深度、访问模式顺序还是随机。数据库联机事务基本是 4K 或 8K 随机读为主混合少量写视频转码是大块顺序读写日志写入是追加式的顺序小块写。把业务翻译错了测出来的数就没有参考价值。一个可用的起点配置如下[global] ioenginelibaio direct1 # 绕过页缓存测到真实介质性能 time_based1 runtime300 # 单场景至少跑 5 分钟看稳态而非峰值 group_reporting1 filename/dev/sdb # 压测裸盘请格外小心会覆盖数据 size32G [rand-read-4k] rwrandread bs4k iodepth32 numjobs4 [seq-write-1m] rwwrite bs1m iodepth16 numjobs1几个必须注意的点direct1一定要开否则测的是内存速度runtime要够长前几十秒的突发性能不代表稳态filename指向裸盘会直接破坏数据生产环境务必用文件或独立测试盘或者干脆用测试环境跑之前确认盘上没挂载文件系统。压测的产出不是单一数字而是一组曲线随着队列深度增加IOPS 上升、单次延迟也上升当延迟开始非线性恶化时那个点就是这台设备的实际工作上限比标称峰值有参考价值得多。5.2 应用内存储写入测试该关注什么移动端或客户端应用做本地存储压测关注点和服务器完全不同。手机的内部存储是闪存关键指标有三个持续写入速度会不会掉、掉速后稳定在什么水平、以及长期小文件高频写会不会导致闪存寿命与文件系统退化。测试方法是持续写入固定大小的文件并计时同时观察写入过程中的速度曲线很多设备在前几十秒能跑到很高的速度之后因为缓存耗尽和垃圾回收介入速度会掉到几分之一这个稳态速度才是用户实际感受到的。实践心得是App 的本地存储尽量不要用大量小文件堆叠能合并的合并能用追加写日志的别用频繁随机改写。小文件的元数据开销在闪存上格外明显还会加速文件系统碎片化。如果业务本身就需要频繁写状态考虑用追加式日志加定期压缩而不是每次改一行就重写整个文件。5.3 巡检要看的几个数与常见告警巡检不用追求指标全抓住几个关键的就够了容量水位建议 80% 告警、90% 必须处理、IOPS 与吞吐的长期趋势、平均与尾延迟、介质健康度SMART 的重分配扇区、待处理扇区、通电时间、以及 RAID 或副本的降级状态。其中尾延迟如 P99比平均值重要得多平均延迟漂亮但 P99 抖到几百毫秒的系统用户体验一定不好。告警项里最需要提前设计阈值的是重建中和降级。这两种状态本身不是故障但它们意味着系统已经失去了部分冗余此时任何一块盘再出问题就是数据丢失。所以这两种状态应该触发最高优先级通知而不是当成普通信息忽略掉。6. 扩容、换盘与故障排查的实操链路存储运维里最考验人的不是日常巡检而是扩容和换盘这两类需要动手的操作。它们共同的特点是操作本身不难但前置检查、过程中的判断、以及失败后的回退路径决定了这次操作是顺利还是事故。6.1 扩容前的容量规划与水位线扩容决策不该等到空间见红才做。合理的节奏是按增长速率倒推先看最近 90 天的容量增长曲线算出日均增长量再用剩余可用空间 / 日均增长得到安全天数。如果这个天数低于采购和上架所需周期很多时候是两到四周现在就该启动了。除了总容量还要关注单一目录、单一用户、单一库表的增长异常局部膨胀往往比整体增长更危险。水位线建议分三档管理70% 时开始规划80% 时触发告警并提交采购90% 时启动应急清理或扩容95% 以上属于高危此时连日志写入都可能失败。另外提醒一句扩容并不总是加盘这么简单块设备加盘可能涉及阵列的 RAID 组扩展或新建卷分布式存储加节点可能涉及数据重平衡对象存储加节点会触发大量副本迁移。这些动作都会抢占带宽和 IO必须安排在业务低峰期并预留出比理论时间长一倍以上的窗口。6.2 集中式阵列更换硬盘的完整流程集中式存储换盘是典型的高风险低难度操作。一块坏盘插进去阵列开始重建正常情况下几小时到几十小时不等。流程上我建议按这个顺序走先确认告警对应的物理槽位与真实位置一致很多事故源于拔错了盘再确认阵列当前状态是否降级、是否有其他盘处于预警状态接着确认热备盘是否已经顶替、重建是否已经开始最后才去动硬件。如果阵列还有热备盘可用其实不需要人工干预换盘插入新盘后系统会自动回拷把盘留在原位等回拷完成反而更稳。动手时几个细节拔盘前先通过管理界面确认盘已从阵列中剔除或离线别在阵列还认为它在线时直接拔换盘期间不要同时做其他维护插入新盘后确认它被识别为同一类型或兼容型号有些平台对混合型号会拒绝入组。曾经有个现场是换盘后重建一直停在某个百分比最后查到是因为机柜里同时换了两块不同类型盘其中一块被判定为不兼容而没有真正参与重建。6.3 排查顺序从链路到介质别一上来就换盘存储问题排查最常见的坏习惯是拿到告警就直接怀疑硬件、准备换盘。实际上从上到下的顺序能省掉大量无用功先看告警本身描述的是什么容量、延迟、介质错误、链路闪断再看是不是业务侧的变化引起的新上的批处理、突增的写入、误配的定时任务接着看链路层多路径状态、交换机端口错包、HBA 日志最后才落到介质层SMART 数据、阵列控制器日志。举个系统盘侧的常见例子Windows 上提示组件存储损坏这属于系统组件库层面的问题不是物理盘坏了先尝试用系统的修复命令扫描并修复系统映像再决定要不要动硬件。同理遇到蓝屏事件日志里出现存储相关的记录先确认是内存、驱动还是介质问题别急着换盘。桌面端还有一类高频问题是大缓存应用比如地理信息类软件默认把缓存写到系统盘导致 C 盘迅速吃满这类问题改一次默认存储路径就能解决跟硬件一点关系没有。再比如存储型 XSS 这类问题看起来和存储无关其实是被存储的内容在展示环节没有做处理。用户上传的文件名、描述、备注被原样渲染到页面上就会形成长期存在的脚本注入点。处理办法是在入库和渲染两个环节都做转义与白名单校验上传的文件名建议统一重命名原始名称只作为元数据保存。这类问题的修复成本远低于事后清理。7. 应用侧最容易搞错的几件事类型、会话与上传前面几章讲的是存储系统本身最后这一章聊应用怎么用存储。这里的问题往往不体现在存储指标上而是以数据库膨胀异常服务重启后任务丢失上传大文件老失败的形式冒出来排查时容易往基础设施方向找实际根因在代码里。7.1 整数类型的选择不是随便挑数据库里存整数用什么类型看着是小事实际直接影响索引体积、内存占用和查询性能。以 MySQL 为例常用整数类型和取值范围如下类型字节数有符号范围无符号范围TINYINT1-128 ~ 1270 ~ 255SMALLINT2-32768 ~ 327670 ~ 65535MEDIUMINT3约 -838 万 ~ 838 万0 ~ 1677 万INT4约 -21 亿 ~ 21 亿0 ~ 42 亿BIGINT8约 ±9.22 × 10^180 ~ 1.844 × 10^19选择原则很简单按业务上限选最小的够用类型并优先用无符号来扩大取值上限。状态码、类型标识、小范围计数用 TINYINT用户 ID、自增主键在可预见范围内用 INT只有涉及分布式 ID、时间戳毫秒值、大额计数时才用 BIGINT。这个选择不是微优化一张千万级表上把主键从 BIGINT 改成 INT索引体积能明显下降缓冲池命中率随之提升。代价是迁移成本所以最好在建模阶段就定下来。7.2 会话与异步结果该放哪会话数据和异步任务结果这两类数据的共同点是有明确的生命周期可以丢但丢了会影响体验。把会话直接放在应用进程内存里单机没问题一扩容成多实例就会出现用户一会儿登录一会儿掉线的诡异现象根因是请求被负载均衡打到了不同实例。解决办法是把会话外置到共享存储Redis 是最常见的选择同时根据业务设置合理的过期时间避免无人清理的会话堆积。异步任务同理。任务生产者把任务投递到消息队列工作进程消费完后需要把结果写到某个地方供查询这就是结果后端。可选方案有消息中间件本身、Redis、以及关系型数据库差别在于持久性、查询能力和运维复杂度。结果数据通常要设置过期时间否则结果表会无限增长成为存储增长曲线里最不好解释的那一段。经验做法是结果保留期略大于业务侧可能的查询窗口比如异步导出类任务结果保留 24 到 72 小时而不是永久保留。7.3 直传对象存储的配置要点与上传踩坑最后聊对象存储的应用侧接入。生产上推荐的模式是客户端直传服务端只负责签发临时凭证或预签名 URL这样大文件流量不经过业务服务器能显著降低带宽和 CPU 压力。配置上有几个必须确认的点endpoint 只写到主机和端口不要带桶名签名区域与桶所在区域一致临时凭证的有效期要覆盖最长上传时间且权限收敛到只能写指定前缀大文件必须走分片上传单片大小、并发数、失败重试策略要在客户端明确配置。踩坑清单里排第一的是权限过宽为了省事给业务方一个管理员凭证一旦凭证泄漏整个存储桶可以任人读写删。第二是分片上传中断后没有清理残留分片这些看不见的分片会一直占空间账单上表现为存储用量比实际文件大很多处理办法是配置生命周期规则自动清理未完成的分片。第三是把对象存储当成可以频繁覆盖写的地方对象存储的覆盖语义是整体重写不是原地修改高频小改动应该聚合后再上传。还有个容易被忽视的细节桶的公开访问策略。素材类文件需要外部直接访问时用独立的只读桶或 CDN 回源别把含业务数据的桶直接放开。所有用户可控的内容文件名、自定义描述、富文本备注在展示前统一转义这是防存储型注入最基础也最有效的一步。我个人在这条路上踩得最深的一次是早期给小团队搭对象存储时把 AccessKey 写死在客户端里觉得反正是内网。后来内网被一台被入侵的开发机横穿密钥被拿去遍历了整个桶好在桶里只是构建产物损失有限。从那之后我给自己定了一条规矩任何密钥都不进客户端、不进代码仓库只走临时凭证任何桶的权限都从最小开始不够再加。这条规矩看起来麻烦但它把一次可能致命的失误压缩成了一次可控的小事故。密钥轮换的周期也别定得太长三个月一次是最低要求涉及核心数据的桶更应该缩短到一个月。