日志完整性基础：到底什么是日志完整性？
很多朋友一听到「日志完整性」，就觉得是玄学。说白了，就是确保你写进去的每一条日志，没有被偷偷改过，而且顺序是对的。
我早年有个血泪教训。某次线上事故排查，我盯着日志文件看了两小时，发现时间戳前后矛盾，事件因果链全乱套了。后来才发现，是日志系统在降级时把缓冲区里的记录给冲乱了。嗯，从那时候起，我才真正重视起这个看似不起眼的问题。
日志完整性的核心定义
日志完整性，指的是日志从生成、传输、存储到消费的整个生命周期里，每一条记录的内容没有被篡改，且记录之间的先后顺序可被忠实还原。你可以把它想象成法院上的证据链——任何一环缺失或被篡改，整个链条就失效了。
一句话总结：日志完整性 = 不可篡改 + 有序性。
两个关键属性
属性一：不可篡改
什么叫不可篡改？意思是，日志一旦落盘，就不能再被任何人在事后偷偷改掉。包括开发者、运维、甚至黑客。
你可能会想：「我自己就是管理员，我改一下日志有什么问题？」我告诉你，问题大了。假设你排查一个线上bug，日志说A操作导致了B结果，但如果你之前偷偷删过一条A操作的日志，那整个推演就全错了。
常见的实现手段：
- 哈希链：每条日志记录包含前一条的哈希值，形成链条。改一条，后面全断。
- 签名：服务端对每条日志做数字签名，客户端可以验证。
- 写后只读：存储层做成只追加（append-only），禁止随机写入或修改。
我在项目中遇到过，有人用MySQL表来存日志，结果业务逻辑里居然有update语句去修正「写错的」日志内容。一查，全是坑。所以后来我强制规定：日志只能insert，不能update/delete。
属性二：有序性
日志的顺序很关键。你想想看，如果日志记录是乱序的，你根本没法还原事情的经过。比如一个请求先打出了「异常退出」，后打出「开始处理」——这排查什么鬼？
保证有序性有几个办法：
| 方案 | 原理 | 优缺点 |
|---|---|---|
| 全局单调递增ID | 每条日志分配一个全局唯一且递增的序列号 | 强一致，但分布式下性能开销大 |
| 时间戳+自增序号 | 毫秒时间戳 + 同一毫秒内的自增计数器 | 轻量，但跨机器时钟同步难 |
| 逻辑时钟（Lamport/LWW） | 基于事件顺序的逻辑时钟 | 无需物理时钟，但复杂 |
我个人习惯在业务日志里同时带上这两个属性：一个log_id（全局自增），一个timestamp。两者配合使用，既保证顺序，又能做时间窗口分析。
一个容易被忽略的点：熔断降级下的完整性
熔断降级时，系统可能来不及写入完整日志就跳过了。这时候日志完整性就面临双重挑战：一是日志可能丢失（不完整），二是幸存日志的顺序可能被打乱。
举个例子：你的服务有A、B两个节点，熔断后A节点把日志丢到了本地文件，B节点绕过了日志直接返回降级结果。后续你从A的本地文件捞日志，却发现B的日志根本没有——那你根本不知道B当时做了什么。
注意：熔断降级下，不要假设所有的日志都能按正常流程写入。你必须设计一个熔断期间的特殊日志通道，比如内存缓冲区+异步flush、降级专用日志存储。否则，排查事故时你只能靠猜。
日志完整性的知识结构图
下面这张图梳理了本章的核心逻辑。你可以把它当作一个思维导图来看。
小结：这三个要点请记住
- 日志完整性 = 不可篡改 + 有序性。缺一不可。
- 熔断降级会同时攻击这两个属性。你必须在设计时提前规划降级日志通道。
- 不要信任任何能随意修改的日志存储。日志必须是 append-only，且最好加上哈希链或签名。