1、日志系统概述：为什么日志系统会丢数据？核心挑战与设计目标。

大家好，我是你们的老朋友。今天咱们聊聊日志系统。

说实话，日志系统这东西，看着不起眼，但一旦出问题，那真是要命。我见过太多团队，线上服务跑得飞起，结果日志丢了，排查问题就像大海捞针。你想想看，一个系统连自己怎么挂的都不知道，这多可怕？

所以，这门课咱们就聚焦一个核心问题：日志系统怎么才能不丢数据？

1.1 日志系统到底在干嘛？

说白了，日志系统就是给系统装个“黑匣子”。

它记录下系统里发生的每一件重要的事：谁来了、干了什么、结果如何、花了多久。这些记录，就是我们排查故障、分析性能、审计安全的第一手资料。

我个人习惯把日志系统比作“飞机的飞行记录仪”。平时没人看它，但一旦出事，它就是唯一的救命稻草。所以，这根稻草绝对不能丢。

1.2 为什么日志系统会丢数据？

这个问题，我当年刚入行时也踩过坑。有一次线上告警，我查了半天日志，发现关键时间点的记录全没了。后来一查，是磁盘写满了，日志进程直接罢工。嗯，从那以后，我再也不敢小看日志系统的容错设计了。

丢数据的原因，归纳起来就这几类：

• 磁盘满了：这是最常见的原因。日志写得太快，磁盘空间撑爆，新日志写不进去，旧日志被强制删除。
• 进程崩溃：日志采集进程突然挂了，内存里还没来得及刷盘的日志，直接蒸发。
• 网络抖动：分布式日志系统里，日志从客户端传到服务端，网络一断，数据就丢了。
• 缓冲区溢出：内存缓冲区太小，生产速度大于消费速度，数据被无情丢弃。
• 配置错误：比如日志级别设错了，或者滚动策略没配好，导致日志被误删。

1.3 核心挑战：写日志到底难在哪？

你可能会想：不就是写个文件吗？有什么难的？

其实不然。日志系统面临的核心挑战，说白了就是三个字：快、稳、省。

挑战	具体表现	后果
快	业务系统每秒产生数万条日志，写入速度必须跟上	写慢了会阻塞业务线程，影响主流程性能
稳	日志系统不能成为单点故障，不能因为日志挂了导致业务也挂	日志系统崩溃，业务系统跟着遭殃
省	磁盘空间、内存、网络带宽都是有限的	资源耗尽，日志写不进去，数据丢失

这三个挑战，互相制约。你想快，就得用内存缓冲，但内存有限；你想稳，就得做冗余，但冗余消耗资源；你想省，就得压缩、裁剪，但可能丢数据。

所以，设计日志系统，本质上就是在性能、可靠性、资源消耗三者之间找平衡。

1.4 设计目标：我们要做成什么样？

基于上面的挑战，我给日志系统定了几个硬性目标。这些目标，也是咱们这门课要逐一攻克的。

1. 零丢失：这是底线。任何情况下，已确认的日志都不能丢。哪怕进程崩溃、机器宕机，也要保证数据能恢复。
2. 高性能：写入延迟要低，吞吐量要高。不能因为写日志，拖慢了业务主流程。
3. 高可用：日志系统自身要能容错。单点故障不影响整体服务。
4. 资源可控：内存、磁盘、网络的使用量要可预测、可配置。不能出现“日志把磁盘撑爆”这种低级事故。
5. 可观测：日志系统自身的运行状态要能监控。比如：当前积压了多少日志？写入速度是多少？有没有丢数据？

1.5 知识体系总览

为了让大家对这门课有个整体认识，我画了一张图。这张图展示了日志系统内存管理的核心逻辑。

这张图很直观：日志从产生到持久化，中间经过内存缓冲。而内存缓冲，恰恰是丢数据的高发区。咱们这门课，就是要解决这个缓冲区的各种问题。

好了，第一章就到这里。咱们把日志系统的背景、挑战和目标都理清了。下一章，我会带大家深入内存缓冲区的内部，看看数据到底是怎么丢的。

---