先说个态度：我不喜欢审计日志。就像不喜欢体检报告——知道有用，但每次看到会被刺眼的数据扎得疼。直到线上支付系统被检查出资金流水篡改痕迹后，我才从被窝里爬起来，仔细看了看这堆冷冰冰的字节。审计日志不是拿来“记”的，它是拿来“拍板”的。它必须做到不可抵赖。但是，怎么做到？靠文件系统？别逗。
审计日志的不可抵赖，靠的是把历史织成一条钢链
大多业务系统审计就是插个表格，存个diff。可这有什么意义？DBA改个数据行，你敢说这是审计？真要较真，我们得让每一条日志都成为“前一条日志的证明者”。这就是哈希链——每个日志块要保存前一个块的SHA-256摘要。一段流程下来，整个日志就是一个长得像链表的东西，但每个节点都咬住前一个的尾巴。改中间任何一笔，后边的哈希全崩。这就像多米诺骨牌，你推动任何一块，整个证据链就倒掉。
具体实现上，我们维护一个全局的 last_hash，每写一条记录时，计算 (last_hash + 当前内容) 的哈希，写进 head，再更新 last_hash。要注意，这里需要原子性。怎么做到？可以用一个 8 字节的序列号，写在日志的固定偏移位置，然后文件锁？不，我们直接用 O_APPEND 模式写入——内核保证追加原子性。但这不是重点。
倒序看，如果攻击者要篡改某条记录，他必须同时修复它之后所有记录的哈希。这意味着计算量是指数级上升——所以他必须把整条链重写。但审计日志不傻，我们用单独的离线校验服务，每天把链上哈希全部对一遍，发现断裂就告警。整个过程就像给账本打公证章。
很多人会问：哈希链会带来存储放大吗？我们算一下：每 100 字节业务数据，加上 32 字节哈希，以及固定 16 字节元信息，放大率只有 1.48 倍。但好处是，我们可以把每 5 分钟进行一次全链校验，而不用实时算。这在实现上就是后台任务慢慢跑。
性能不是砸钱买SSD，而是把写日志动作变成“物理上无法更优”
线上压测真是惨痛教训。起初我们用普通的 fwrite + fflush，每次调用都经过系统调用，锁在 FILE 结构上，压测目标 50 万 TPS 直接跪了。测出来的数字是每秒 4 万条，但 CPU 已经烧到 70% 以上。磁盘是 NVMe，却连 500MB/s 都没跑到。问题出在哪？是调用次数。
我们把每个日志条目拆成一个 512 字节的块，假设我们要达到 100万条/秒，那么需要的带宽为 512MB/s。NVMe的顺序写性能可以到 3GB/s，但我们要填满它，需要每秒约 600 万次 write()。而系统的最大 syscall 能力约为 200 万次/秒。所以必须减少调用次数。我们的解法是：用 mmap 把日志文件映射到用户态，直接写内存，由一个后台线程每隔 4KB 或 10ms 批量 fsync。这就是“零拷贝”——不对，应该说减少拷贝。
结论非常直接：改用内存映射排序追加后，我们压测达到每秒 129 万条审计日志（每条 512 字节），CPU 只占 18%，磁盘顺序写带宽稳定在 650MB/s。这个数据告诉我们，性能瓶颈在“系统调用”而不是“磁盘”。如果你还有疑惑，看这个推导：一次 fsync 大约耗时 200 微秒，如果我们能批量合并 100 条日志，那么每 100 条只需 200 微秒，相当于单条 2 微秒，这才是 50 万 TPS 的基石。
三个坑，每一个都是用不眠之夜填平的
坑1：分布式节点时间不可信。这不是理论问题。我们有三台订单节点，时间偏移最大 800ms，直接导致同一笔业务的 create 和 settle 日志错位，审计员差点在我们的代码里寻找隐藏后门。解法是抛弃机器时钟，改用 Lamport 逻辑时钟。每个事件携带逻辑时间戳，但日志本身保留物理时间作为参考。这样排序问题就解决了。
坑2：日志文件无限膨胀。一开始我以为 60 天见顶，结果 21 天就被提醒磁盘告急。单条日志 512 字节，每秒 100 万条，一天就是 43TB！这不现实。我们做了两层压缩：热日志只保留 3 天，全部放内存盘；冷日志用 Gzip 归档，并把它做成 parquet 列存，配合日分区。再用一个简单的查询引擎，过滤掉 90% 的全表扫描。要小心的是：zstd 压缩对哈希链没有影响，因为哈希只对原数据计算，压缩不影响验证。
坑3：完整性校验会影响在线写入。 我曾天真地设计成每次启动时全量遍历哈希链。结果就是系统启动要 5 分钟，这谁受得了？后来改用 Merkle 树：每隔 1 分钟生成一个树根，校验时只需要对比这些树根。增量校验，不用全读。具体做法是每写 1024 条记录构建一个 1024 叶子节点的 Merkle 树，根哈希存入另一个小文件，然后离线校验只用抽查分支。这种设计让启动时间缩到 40ms 以内，离线校验可以每 5 分钟跑一遍，性能损失几乎为零。
这还没完。我们还得考虑日志“读”的幂等性。你永远不知道审计员会怎么检索——时间范围、用户 ID、金额？我们用 B 树索引维护日志偏移量，每个索引项指向日志文件位置，同时加上简单布隆过滤器，让 95% 的检索落到 1GB 范围内。不过这都是后话。
工程的最后一公里
写完这几个模块后，系统终于敢说是“审计日志”了。但我还是想说一个反常识的点：审计日志的工程美学，在于它尽可能少做事，而把验证留给时间。我们不做原地更新，不做修改删除，只对齐扇区地追加。数据的物理路径就是从用户态到 page cache 再到 NVMe。每个字节都按顺序躺着，像一块安静的墓碑，记录着谁在这个世界做过什么。
所以，当下次有人轻飘飘地说“审计日志不就是写个 append only 文件吗”时，你可以把这篇记向他们。哦对了，如果你正打算自己实现，提醒你：先写一个二进制格式，再考虑文本格式。因为二进制可以让哈希链的构造量降低 37%。
就是这样。不是劝退，是劝你重视这堆字节。毕竟，你的系统可以崩，但审计日志不能丢。
