第2章：集中存储方案设计原则与目标

审计日志集中存储，听起来像个纯技术活。

但干过几个大项目后，我深刻体会到：技术只是冰山一角。真正决定方案成败的，是背后那套设计原则和清晰的目标。

为什么有的系统越跑越慢？为什么有的日志查起来比登天还难？为什么上着上着就崩了？

说白了，就是一开始没想清楚「我们要达成什么」。这一章，我们来聊聊这些根本问题。

2.1 我们先定下「设计目标」

我在设计第一个企业级日志平台时，犯过一个低级错误：什么都想要。

又要性能顶级，又要亿级并发，又要本地部署，又要全量审计。结果呢？项目工期一拖再拖，最后交付了一个四不像。

后来我学到一句老话：没有目标的架构，都是耍流氓。

那目标该怎么定？我个人习惯，从这五个维度入手：

1. 可靠性 – 日志不能丢，不能改，不能删。这是底线。
2. 可用性 – 7x24小时服务，单点故障不中断写入。
3. 性能 – 写入快，查询也快。别让审计业务卡死在等待上。
4. 成本 – 存储、计算、带宽，都要算清楚账。
5. 合规 – 满足GDPR、SOX、等保、内部审计要求。

2.2 核心原则一：CRUD 模型

设计存储方案，本质是在设计数据的「增删改查」。

但审计日志和普通业务数据，有本质区别。我把它映射为 CRUD 操作矩阵：

你可能会问：为什么要把 CRUD 单独拎出来？

原因很简单：不同操作，对存储引擎的要求完全不同。我曾经见过一个团队用 MySQL 做审计日志，读写都压在一个库里，结果每天凌晨的批量删除直接把主库打挂了。原因就是没想清楚「这是个写多读少，几乎不更新、几乎不删除」的场景。

2.3 核心原则二：高可用

审计日志不能停。这是红线。

我习惯把高可用拆成两个层面来思考：

• 写入高可用： 服务端宕机时，客户端能切换到备节点，日志不丢失。
• 读取高可用： 查询服务不行了，至少已有数据能读出来。

常见的实现方式：

1. 主从复制 + 自动故障转移。 比如 Elasticsearch 的 Zen Discovery + 选主。
2. 多副本写入。 每条日志写入至少 2 个独立节点后再返回成功。
3. 客户端重试 + 本地缓冲。 服务端不可用时，日志先暂存本地，等恢复后再补发。

2.4 核心原则三：可扩展

审计日志量只会涨，不会跌。

你猜怎么着？我参与的一个项目，上线三个月后日志量翻了三倍。为什么？因为业务方发现审计日志还能用来做用户行为分析，一高兴把所有操作都记录了。

幸好当时的架构是水平扩展的。加节点，改配置，数据自动 rebalance。要是用单机方案，那天就是我的末日。

可扩展的核心策略：

• 数据分片（Sharding）： 按时间、哈希、业务域做分片。
• 无状态服务： 计算层可以随意加节点。
• 存储分离： 计算和存储解耦，各自独立扩缩。
• 冷热分层： 热数据放高性能存储，冷数据放廉价存储。

2.5 核心原则四：低成本

成本这东西，我刚开始做架构时很少去算。

直到有一天老板拿着云账单问我：「为什么存储费一个月就花了 20 万？」 我一看，原来所有日志都放高性能 SSD 上，连三年前的冷数据都在上面。

那一刻我意识到：不考虑成本的架构，是站不住脚的。

控制成本的常见手段：

1. 压缩： 日志文本重复度高，压缩率能达到 5:1 甚至 10:1。
2. 冷热分层存储： 大多数日志 90% 的时间都在「冷」着。
3. 数据保留策略： 不要「永远保存」，要按合规要求设定保留期限后自动销毁。
4. 去重： 有些系统会重复发送日志，需要去重机制。
5. 批量写入： 减少网络开销和 IOPS 压力。

2.6 核心原则五：合规性

合规不是技术问题，但又必须用技术来解决。

不同行业、不同国家，要求差距很大。

2.7 本章小结（嗯，用表格收个尾）

这些原则，就像建筑的地基。地基打不好，上面盖再高的楼也是危楼。