计算机基础这块儿最容易出现一个现象CPU、内存、操作系统讲得头头是道一到存储就只剩“硬盘速度不行”“换SSD就快了”这种模糊认知。这期笔记选择“数据落盘”作为主角是因为我最近帮一个数据团队排查线上任务变慢绕了很大一圈最后才发现问题出在存储链路的底层理解上。这篇内容适合正在补基础、又不想只看理论的同学也适合写业务代码时被偶发卡顿困扰的开发者。读完你会对“从程序发出写请求到数据真正稳定在磁盘上”这条链路建立一个完整坐标系。1. 为什么基础笔记到了第12篇才切入存储先坦白一个感受计算机基础类的知识体系里存储常常是最后才被认真对待的板块。前几篇笔记聊CPU流水线、虚拟内存、网络协议栈都有一个相对集中的主线存储不一样它横跨硬件介质、操作系统内核、文件系统、数据库四层每一层单拎出来都能写一本书所以很多学习路径会下意识把它往后放。放太久了就形成了知识盲区。我自己的转折点来自一次不算复杂的故障。某个数据分析任务每天凌晨跑批某段时间经常从十几分钟拖到一小时以上刚开始怀疑是SQL写得有问题调了一遍没效果又怀疑网络传输瓶颈抓包也没发现异常。直到无意中用监控工具看了一眼磁盘IO才发现IO利用率持续飙到90%以上而CPU和内存都闲着。当时的第一反应是“磁盘是不是坏了”换了块新盘竟然还是慢后来才意识到问题根本不在“盘坏了”而在于任务本身的读写模式和底层存储特性完全不匹配。那次之后我把存储相关的基础知识重刷了一遍发现很多困惑的根源在于我们平时写代码、建表、配置参数都把“存储”当成一个黑盒盒子里发生什么完全靠猜。而真实运行逻辑是分层的——应用层以为调了一个write()就写完了操作系统可能只是把数据放进了页缓存真正刷到磁盘是后面的事。数据库以为提交了事务就安全了其实还要依赖fsync配合日志机制。每一层都有各自的承诺和边界哪一层理解不到位排障时就会走弯路。所以这篇笔记打算沿着一条主线走从一次数据写入的完整路径出发分别拆解硬件介质、操作系统IO栈、文件系统、以及数据库存储引擎这几个关键环节。它适合两类人一类是刚开始系统学习计算机基础、想搭一个完整框架的学习者另一类是工作两三年、经常被性能问题折磨但一直没机会系统补课的后端或数据开发者。如果你属于前者建议放慢速度边读边对照实验如果属于后者可以直接看第2章和第4章再回头看其余内容。2. 从程序指令到磁盘扇区一次数据落盘的全路径拆解很多时候大家聊存储性能喜欢直接对比“顺序写多少MB/s”“随机IOPS多少个”但如果不先把路径搞清楚这些数字就像没有参照系的地图坐标。这里我从一次最简单的文件写入开始拆假设程序调用 write(fd, buf, 1024)这1024字节数据从用户态到磁盘到底经历了什么。2.1 用户态到内核态的第一次交接写操作首先进入的是虚拟文件系统层。这一层负责跟具体文件系统解耦比如你的磁盘分区是ext4还是xfs对于上层应用来说并不关心。VFS接收到请求后会根据文件描述符找到对应的文件对象再定位到文件的inode从而知道这次写入要落在哪个文件的哪个偏移量上。这一步有三个值得注意的细节。第一write()这个系统调用本身只是把数据从用户空间的缓冲区拷贝到内核空间的页缓存(page cache)中这时“写入”已经完成但数据还没到磁盘。第二因为存在这个拷贝过程传大缓冲区不一定比传小缓冲区快因为页缓存分配、锁竞争等因素也在起作用。第三VFS层会维护一堆元数据操作表不同的文件系统通过注册不同的函数指针来实现自己的逻辑这也是为什么“一切皆文件”在Linux里能成立。2.2 页缓存系统给你的“后悔药”页缓存是理解存储性能绕不开的一个概念。简单说内核会把读过的磁盘块缓存到内存里写入的数据也会先进这个缓存区。这带来一个明显的收益短时间内重复读取同一个文件可以直接命中内存速度比磁盘快几个数量级。代价则是内存压力上升以及在极端情况下的数据丢失风险。数据进入页缓存后会被标记为“脏页”表示它和磁盘上的内容不一致。内核有一套刷盘机制触发条件主要有三个脏页占比超过阈值、距上次刷盘超过设定时间、或者有人显式调用sync/fsync。参数通常在 /proc/sys/vm/ 下比如 dirty_ratio 和 dirty_background_ratio。这里有一个特别容易被忽略的结论操作系统只在内存紧张或达到阈值时批量刷盘它追求的是整体吞吐而不是单个进程的实时落盘。我见过有同学做个简单的配置测试程序里写了个大文件sleep几秒后断电重启发现文件一半是空的就说文件系统有bug其实是没理解页缓存这层。这不是杞人忧天很多在线服务崩溃后出现数据缺失追根溯源都是“以为write完成就安全”的认知误区。2.3 块设备层与驱动IO请求开始排队脏页被刷出后数据会进入通用块层。这一层会把文件系统传来的IO请求重新组织、合并、排序比如相邻扇区的写入请求会被合并成一个更大的请求。操作系统在这里还会根据IO调度器做调度传统机械盘时代常用的调度算法会尽量把读写请求按扇区顺序排列减少磁头往复运动SSD时代则可以更偏向延迟优先。块层下面就是设备驱动它负责把请求翻译成设备能理解的形式。比如对NVMe SSD驱动会构造相应的命令并通过PCIe总线发送给设备对机械硬盘则要换算成柱面、磁头、扇区这些物理寻址信息。这个过程非常底层大多数开发者不需要直接接触但理解它有助于看懂后面的性能指标。2.4 磁盘介质层数据真正“涂”上去数据到达磁盘后具体怎么落位就取决于介质了。机械硬盘要等盘片转到对应扇区再让磁头写到磁道上SSD则要先通过FTL映射找到一个空闲块再在NAND闪存单元中改变电荷状态。这一层的能力决定了随机和顺序读写的巨大差距下一章详细聊。有一次排查慢查询时我用 blktrace 抓过IO事件发现一个看起来普通的UPDATE操作在块设备层产生了上百个分散的小请求每个请求之间的等待都超过1ms数量一大整体就慢得离谱。这种问题光看应用层SQL永远找不到答案必须把视角下沉到IO栈。读路径的流程也类似先从页缓存查找命中就直接返回如果不命中才走块设备层发起磁盘读并把结果回填到页缓存。理解这条路径后很多“缓存命中率”“冷热数据”的话题就有了落地的认知基础。3. 机械硬盘与固态硬盘的底层逻辑差异远不止“快和慢”很多人的存储知识停留在“SSD比HDD快所以贵的就好”。但实际工程中两种盘在随机读写、并发压力、寿命衰老这些维度上的差异会直接影响你怎么设计系统。如果你不清楚底层逻辑拿到一台机器只看容量和价格迟早会在性能优化上踩坑。3.1 机械盘一场磁头与盘片的“赛跑”机械硬盘的工作原理一点都不复杂盘片持续高速旋转磁头悬浮在盘面上通过移动悬臂定位到目标磁道。一次数据访问的时间 寻道时间 旋转延迟 传输时间。老一点的7200转硬盘寻道时间平均在8ms左右旋转延迟约4ms左右加起来随便一次随机访问就是10ms量级。这个数量级意味着什么假设一个程序每秒发起1000次随机小IO理论上每块盘的极限就在每秒100次左右还得是排队理想的情况下。一旦并发上去请求全在排队性能曲线直接崩掉。顺序读写就完全不一样了磁头定位一次然后连续读一串扇区每秒钟能写几百MB。可以这么理解机械盘就像一家需要员工到仓库不同货架上取货的商店。如果订单内容散落在各个角落员工大部分时间都花在路上如果订单恰好是连着几个相邻货架员工推着车一趟就搬完了。这也是为什么机械盘时代几乎所有性能优化的核心思路都是“把随机变顺序”。3.2 固态盘没有寻道但也有“沉重的代价”SSD没有机械运动访问任何地址的延迟都在几十微秒量级所以随机读性能比机械盘高好几个数量级。但SSD不是没有软肋它的问题出在NAND闪存的物理特性上。闪存颗粒只能按块擦除、按页写入一个块擦除前如果还残留旧数据必须先搬走有效数据再擦除这就是写放大。具体到4KB小块随机写入的场景SSD内部可能要“读-改-写”一个更大的块实际写入量可能达到逻辑写入量的好几倍。这就解释了为什么很多SSD在纯随机小写场景下性能反而不稳定。另外FTL映射表需要随写随更新掉电时需要恢复映射状态这又引出了掉电保护电路和固件策略的差异。3.3 一张表看透两种介质的本质差别为了直观比较我把工程中最常用到的几个维度列成这样一张表维度机械硬盘固态硬盘典型随机访问延迟8-15ms0.02-0.1ms顺序吞吐量150-250MB/s500MB/s-7GB/s随机小IOPS100-200数万到数十万随机与顺序性能差距数十倍随机读尚可随机小写存在写放大磨损限制基本无有擦写次数上限受OP空间影响数据恢复难度相对可控掉电/固件故障后恢复困难SSD物理结构的另一个影响是预留空间OP。通常市售SSD标称容量和实际可用容量之间存在差额这部分空间用于垃圾回收、磨损均衡和坏块替换。如果你把盘的利用率填到97%以上写放大会明显上升性能会下滑得非常快。所以线上机器留20%左右空余不单是容量规划问题更是性能问题。SSD的随机读优势是结构性的但这个优势要建立在操作系统IO调度和文件系统分配策略与之匹配的前提下。比如日志型文件系统如果设计成总是追加写入在两种介质上都有很好的表现而频繁原地覆盖更新的文件在SSD上则会不断触发FTL垃圾回收。设计应用时尽量让写入变成顺序追加减少小块随机更新这种习惯在HDD时代是优化技巧在SSD时代依然是有效的。4. 文件系统的几个关键细节页缓存、fsync 与日志应用一般不会直接跟磁盘打交道中间隔着文件系统。文件系统负责把块设备的线性空间组织成目录、文件、权限这样的抽象结构。这一层有一些容易被忽视的细节理解透彻之后很多“数据怎么丢了”“性能怎么突然垮了”的问题都能解释清楚。4.1 写日志不等于数据已经落盘很多数据库和消息中间件为了确保崩溃恢复能力都会先写日志再写数据文件比如MySQL的redo log、Kafka的partition日志。但这里有个典型的混淆点应用做了write()之后日志数据可能在页缓存里并没有真正落盘。要想保证这次写入在断电后仍然存在必须调用fsync或者fdatasync强制将文件相关的脏页刷到磁盘。我见过一个真实案例某任务队列在进程正常退出时一切正常一旦机器突然掉电已经“确认成功”的消息就丢了一部分。表面上看起来是程序bug实际上就是确认逻辑里缺了fsync。修法很简单在写入后调用fsync结果吞吐量下降了业务方又不接受于是就得靠批量提交、分组fsync来做权衡。4.2 日志与一致性文件系统如何面对“写了一半”文件系统本身也有日志机制目的是防止元数据更新中途掉电导致目录结构损坏。以ext4为例默认的dataordered模式会先保证文件数据在元数据落盘之前已经写入这样即使崩溃也能恢复到一致状态。这里的一制性不是指你的业务数据不丢而是指文件系统结构本身不损坏——两者目标完全不同。考虑一个写文件场景创建文件、写入内容、更新目录。如果这三个动作没有顺序约束突然断电后可能出现“目录里有文件但inode指向的内容是垃圾”的中间状态。日志机制就是把关键动作序列先记下来崩溃后重放保证要么全部做完要么全部回退。这不是性能优化而是底线保障。4.3 挂载参数里的工程学问文件系统的默认参数在个人电脑上通常够用但在高并发服务上往往需要根据业务模型调整挂载选项。这里分享几个工程中常用的参数及其影响noatime可以避免每次读文件都更新访问时间减少不必要的写IOnodiratime类似抑制目录访问时间的更新。对于读多写少的服务这两个参数收益明显。还有一个值得注意的选项是barrier/nobarrier。在传统块设备上文件系统通过barrier保证刷盘顺序保证日志先于数据落盘。但在一些有独立电池备份的RAID卡上可以安全关掉barrier来提升性能。不过这要求你非常清楚硬件具备掉电保护能力否则一旦断电数据损坏风险大幅增加。这类参数没有绝对好坏必须结合具体硬件和业务SLA来定。我建议每个上线服务都提前规划好挂载参数而不是等出现丢数据或性能问题再临时改。改挂载参数要重建文件系统或者重启服务代价很大。有个小技巧在部署阶段用一个临时目录做写入基准测试分别测默认参数和优化参数下的吞吐差异用数据说话比靠感觉靠谱得多。5. 从文件到数据库存储抽象如何影响上层设计如果只讲文件系统对很多做应用开发的人来说还是有点远。真正把存储基础跟日常开发连接起来的是数据库存储引擎。为什么数据库不直接读文件为什么明明是一台机器换个存储引擎性能差这么多这一章从存储角度看数据库你会发现很多配置项的逻辑一下子通了。5.1 为什么数据库不直接读写文件文件系统提供了按“文件”为单位的抽象但业务查询需要的是按“记录”快速定位。如果每次查询都从文件头扫描到尾任何系统都扛不住。所以数据库内部必须维护一套索引结构把“记录键”映射到“文件偏移”。经典的B树索引本质上就是在做这件事。它把索引和数据组织成多叉树每次查找最多访问少数几个节点。这里需要注意一点B树的节点通常和磁盘页大小对齐比如16KB这样一次IO就能读取一个完整节点。如果节点大小设置不合适会产生大量碎片IO性能下降明显。很多数据库默认值是基于通用场景调的实际业务里值得单独验证。5.2 追加写与LSM树把随机写变成顺序写传统B树在数据更新时需要原地修改这会产生大量随机写。而很多日志类、KV类系统采用了LSM树思想先把写入放在内存结构里积累到一定阈值后再批量合并落盘。因为每次合并都是大段的顺序追加写放大和随机写开销都被压缩了这也是RocksDB、LevelDB这批存储引擎在写密集场景下表现出色的根本原因。但LSM树也有代价读取时可能要查多层结构读放大明显后台合并还会占用IO带宽。所以你看没有什么引擎是“最好”的都是拿一部分特性换另一部分特性。理解了这层就不会盲目评判“XX数据库比XX数据库快”而会说“在某种负载下某种结构更适合”。5.3 事务提交和日志的关系数据库事务的持久性依赖预写日志。每次事务提交数据先写日志再写数据文件日志顺序追加因此提交的延迟主要取决于日志写入的fsync速度。这就解释了为什么事务型数据库的性能上限常常卡在“单机fsync次数”上每秒能安全刷盘多少次就大致决定了每秒能提交多少事务。生产环境中常见的调优手段比如组提交就是把一段时间内的多个事务合并成一次fsync摊薄固定开销。如果你看到数据库参数里有“sync_binlog1”“innodb_flush_log_at_trx_commit2”这类选项本质上都是在“安全性”和“每秒fsync次数”之间做选择。基础扎实之后你再看这些配置就不会死记硬背了。6. 把存储知识落地的两个小实验与避坑心得这一章写给想亲手验证上面理论的同学也记录我踩过的几个坑。实验不需要高配机器普通Linux服务器或者一台虚拟机就能做。重点是亲自观察过以后书上的数字才能真正变成你自己的判断力。6.1 观察顺序IO与随机IO的差距第一组实验最直观用fio或者dd分别测顺序写和随机写的性能。没有fio的话用两个简单的dd命令也能看出明显差别。顺序写可以这样测dd if/dev/zero of/tmp/test.bin bs1M count1024 convfdatasync。这里bs1M让每次请求都是大块连续写可以用fdatasync保证真正落盘避免只测到页缓存速度。测完记得清理rm /tmp/test.bin然后再做随机写对比。随机写可以用fiofio -namerandwrite -rwrandwrite -bs4k -size1G -iodepth32 -ioenginelibaio -direct1。注意direct1是为了绕过页缓存直接发起设备层IO否则结果会被缓存干扰。如果你机器上跑的是业务先在空闲时段操作并且别拿系统盘做这个测试免得IO波动影响其他服务。这两条命令跑完你会看到顺序写可能在每秒几百MB到数GB而随机4K写入只有每秒几万KB到几十万KB。数字的震撼比任何书里的描述都直接。6.2 观察脏页更新与刷盘机制第二个实验排查IO问题时非常有用。先记录当前脏页量cat /proc/meminfo | grep -i dirty然后在一个文件里持续写入数据比如 dd if/dev/zero of/tmp/dirty.bin bs1M count2048。写入过程中每隔几秒再看一次Dirty值你会发现它先涨上去然后到某个人阈值后落下来这是因为后台线程开始刷盘。这个实验之后你再看到监控里磁盘IO有小幅周期波动就不会觉得异常了。那很可能是系统在按自己的节奏刷脏页与业务洪峰叠加后表现出来。想更精细地观察可以用iostat -x 1看await和%util看看IO在设备层面是否饱和。6.3 排障时的五个固定检查项这几年排查存储相关性能问题我逐渐形成了一套固定的检查顺序照着做很少跑偏。第一先看磁盘空间和inode使用率很多诡异问题其实是磁盘写满或inode耗尽表现成“创建文件失败”“写入卡住”。第二看IO延迟和队列长度iostat里的await和aqu-sz如果明显偏高说明设备层已经过载。第三检查挂载参数确认是不是默认参数在拖后腿。第四看页缓存和脏页水位避免频繁刷盘抖动。第五确认是否有人在跑批处理任务比如全量备份高峰期IO冲突经常被误判为应用变慢。我有一次排查慢接口花了几个小时看应用代码和数据库慢查询最后发现是隔壁团队在做全量数据迁移整块磁盘的IO都被吃满了。所以遇到性能问题第一步不是怀疑代码而是先看整个系统层的资源状态。最后还有一个小建议别把存储性能测试做成日常运维任务。磁盘的性能会随使用状态变化SSD尤其明显。要测就固定在部署新环境或调参时测并且保存历史结果。出现性能问题时把当前结果和历史结果一对比很多问题几分钟内就定位了比临时抱佛脚高效得多。