一、日志体系概述：为什么库存系统需要日志？

说实话，我见过太多库存系统上线后出问题，第一反应就是「两眼一抹黑」。

库存数据对不上？不知道。谁改了库存？不知道。什么时候改的？还是不知道。

这种时候，你就算把代码翻个底朝天，也很难定位问题。为什么？因为你缺少了最关键的证据——日志。

1.1 日志的三大价值

我个人习惯把日志的价值归纳为三个词：排错、审计、监控。说白了，就是「出事能查、查了能认、认了能防」。

① 排错——出了问题，能快速定位

库存系统的错误往往很隐蔽。比如用户下单时扣了库存，但支付失败后又没回滚。这种问题，光靠看代码很难复现。

我在项目中遇到过类似情况：某次大促后，库存对不上账。查了半天，最后发现是并发扣减时，某个中间件丢了一条消息。如果没有日志，这个Bug可能要排查三天。

有了日志，你可以直接搜「扣减库存失败」或者「库存不足」，一秒定位到问题点。

② 审计——谁在什么时候做了什么

库存系统是「钱」的另一种形式。你想想看，一个商品价值几百块，仓库里几万件商品，随便改个数字就是几十万的出入。

所以，审计日志是刚需。谁改了库存？改之前是多少？改之后是多少？操作IP是什么？这些信息必须完整记录。

我曾经帮一个客户做系统审计，发现有个运营人员连续三天在凌晨两点修改库存数据。查下去才发现，他在偷偷给朋友留货。嗯，这就是审计日志的价值。

③ 监控——提前发现异常，而不是等用户投诉

库存系统的异常往往有「前兆」。比如某个商品的库存突然暴跌，或者某个仓库的出库速度异常变慢。

这些信号，如果靠人工盯着，根本盯不过来。但如果你把日志接入监控系统，设置好阈值，系统会自动报警。

我记得有一次，监控系统在凌晨三点发出告警：「某SKU库存扣减频率异常」。我们一看，原来是爬虫在刷单。如果没有日志监控，等早上上班，库存早就被刷空了。

1.2 库存系统日志的核心分类

日志不是越多越好。我见过有人把「for循环里每次变量变化」都打日志，结果一天产生几个TB的数据，查问题反而更慢。

我个人建议，库存系统的日志至少分为以下三类：

日志类型	记录内容	典型场景
操作日志	谁、什么时间、做了什么操作	用户下单、取消订单、后台调库存
业务日志	库存扣减、回滚、锁定、释放的详细数据	扣减前库存量、扣减后库存量、操作结果
系统日志	服务状态、数据库连接、中间件异常	数据库超时、消息队列积压、缓存失效

1.3 一个典型的库存日志记录示例

光说不练假把式。我们来看看，一个库存扣减操作，日志应该长什么样：

{
  "log_id": "202403150001",
  "timestamp": "2024-03-15 10:30:00.123",
  "operator": "user_12345",
  "operation": "库存扣减",
  "sku_id": "SKU_888888",
  "warehouse_id": "WH_01",
  "before_quantity": 100,
  "after_quantity": 98,
  "change_quantity": -2,
  "order_id": "ORDER_202403150001",
  "result": "success",
  "source_ip": "192.168.1.100",
  "user_agent": "Mozilla/5.0..."
}

你看，这个日志包含了所有关键信息：谁操作的、操作了什么、操作前后数据是什么、结果如何。有了这个，不管是排错还是审计，都能直接拿来用。

1.4 日志体系的核心架构图

下面这张图，是我自己总结的库存系统日志体系架构。你可以把它当成一个「地图」，后面几章的内容都会围绕它展开。

这张图展示了日志从产生到应用的完整链路。你可能会问：「这么多层，会不会太复杂？」

其实不会。每一层都有它存在的理由。比如日志采集层的异步写入，就是为了避免日志拖慢业务响应。我在早期项目中吃过这个亏——同步写日志，结果数据库一慢，整个接口都卡住了。

1.5 避坑指南：日志体系搭建的常见误区

• 误区一：日志打得越多越好——我曾经见过一个项目，一天产生50TB日志，查问题反而更慢。正确的做法是：关键路径打INFO，调试信息打DEBUG，异常打ERROR。
• 误区二：日志不设保留策略——磁盘满了，业务直接挂掉。嗯，这个坑我踩过。建议按天滚动，保留30天，超过的自动压缩归档。
• 误区三：日志格式不统一——有的日志用JSON，有的用纯文本，有的用自定义格式。查问题的时候，你光解析格式就够头疼的。建议全系统统一使用JSON格式。

---