📚 课程目录第3章审计日志数据模型设计

审计日志数据模型设计：字段定义与租户标识

数据模型这东西，说白了就是审计日志的「骨架」。骨架歪了，后面再怎么装饰也白搭。我记得刚接手一个多租户项目时，团队把租户ID直接塞进日志的扩展字段里，结果查询时翻车了——性能惨不忍睹，隔离也成了摆设。

今天我们就来聊聊，怎么把这副骨架搭结实。

3.1 核心字段设计

审计日志不是普通业务日志。它要经得起合规审查，扛得住跨团队扯皮。我个人习惯把字段分成四组：

分组	字段	说明
身份标识	tenant_id, user_id, session_id	谁干的，属于哪个租户
时间锚点	event_time, received_time, storage_time	什么时候发生的，什么时候收到的，什么时候存的
操作记录	action, resource_type, resource_id, detail	做了什么，对什么做的，具体内容
审计元数据	trace_id, source_ip, user_agent, result	上下文与结果追踪

⚠️ 核心原则：租户标识必须是结构化字段，不能塞进 JSON 或扩展属性里。否则分区、索引、分片全得跟着遭殃。

3.2 租户标识：隔离的生命线

租户标识是审计日志的「灵魂」。你想想看，如果没有它，所有租户的日志混在一起，查个日志等于大海捞针。更恐怖的是——合规审计时，你根本证明不了数据隔离了。

我建议把 tenant_id 作为日志记录的第一顺位字段，放在所有字段的最前面。这样不管用哪种序列化协议，解析时都能第一时间拿到租户上下文。

常见的租户标识设计方式：

UUID：全局唯一，但查询性能稍弱，适合分布式生成场景。
业务编码：如 org_12345，可读性好，但需要保证生成唯一性。
哈希租户名：避免敏感信息泄露，固定长度适合索引。

我在项目中遇到过一种坑——有人把 tenant_id 设计成可变长度字符串，结果分区键长度超过数据库限制，整张表重建了三次。后来我定了死规矩：租户 ID 固定 32 字节以内。

3.3 时间戳：别让时间说谎

时间戳处理不好，审计日志就是废纸。为什么？因为时间戳会撒谎。

我曾经排查过一个事故：用户操作在 14:00 发生，日志却显示 14:05。原因很简单——应用服务器和数据库服务器时间不同步。你想想看，合规审查时差 5 分钟，谁能说得清？

我的经验是引入三个时间戳：

event_time：操作发生时间，客户端生成，用 UTC。
received_time：服务端收到时间，用原子钟同步的 NTP 服务器。
storage_time：写入存储的时间，不可篡改，由存储系统自带。

💡 有个小技巧：event_time 和 received_time 的差值，可以直接监控服务延迟。差值超过 5 秒的，说明系统可能有瓶颈或时钟漂移。

3.4 操作记录：说清楚干了什么

操作记录没有统一标准，但我梳理出了一套「够用又不啰嗦」的字段集：

action：CREATE / UPDATE / DELETE / READ / EXPORT，枚举类型，别用字符串自由输入。
resource_type：用户、订单、配置、项目……按业务域划分。
resource_id：被操作资源的唯一标识。
detail：变更详情，用 JSON 格式存储，允许业务方自由扩展。

嗯，这里要注意——detail 字段很容易失控。有人把整个请求体丢进去，结果一条日志几百 KB，存储成本直接爆炸。我通常会限制 detail 不超过 4KB，超长内容单独归档，用 id 关联。

❌ 千万不要把密码、、密钥等敏感信息写入 detail 字段。审计日志的访问权限通常比业务数据更宽松，写进去等于裸奔。

3.5 完整的数据模型定义示例

下面是我现在项目里在用的模型。它不是最复杂的，但经过生产环境验证，跑了一年多没出过隔离问题。

{
  "tenant_id": "tenant_a1b2c3d4",
  "user_id": "user_98765",
  "session_id": "sess_20240301_abc123",
  "event_time": "2024-03-01T14:32:10.123Z",
  "received_time": "2024-03-01T14:32:10.456Z",
  "storage_time": "2024-03-01T14:32:11.002Z",
  "action": "UPDATE",
  "resource_type": "order",
  "resource_id": "ord_20240301_xyz789",
  "detail": {
    "changed_fields": ["status", "amount"],
    "old_value": {"status": "pending", "amount": 100.00},
    "new_value": {"status": "confirmed", "amount": 120.00}
  },
  "trace_id": "trace_8f7e6d5c4b3a2",
  "source_ip": "10.0.1.234",
  "user_agent": "Mozilla/5.0 ...",
  "result": "SUCCESS"
}

你看，每个字段都很明确。查询时按 tenant_id 分区，按 event_time 排序，十亿级数据量性能也不差。

3.6 数据模型与隔离的关系图

下面这张图展示了数据模型各字段如何支撑租户隔离：

3.7 字段设计的避坑指南

最后分享几个我用真金白银换来的教训：

别用自增 ID 做主键——多租户场景下自增 ID 容易暴露业务量，而且跨数据中心会冲突。用 UUID 或雪花算法。
枚举字段别用字符串写死——action 字段我见过写 "delete"、"Delete"、"DELETE" 三种的，查询时就等着哭吧。
索引别乱加——tenant_id + event_time 复合索引基本够用。加太多索引，写入性能会崩。
detail 字段要限流——我之前有一家客户，单条 detail 写了 50KB，数据库 IO 直接被打满。

数据模型设计这件事，多花一小时，后面省十天。我当初在模型上多花了半天去评审，结果整个项目周期里审计日志模块零故障。值不值？值。