关键在解耦与缓冲：同步写磁盘、直连后端、无背压机制三类设计在百万qps下必丢日志或拖垮业务；需采用异步解耦（业务线程零等待、无锁环形队列）、传输加固（filebeat/ilogtail+kafka/pulsar）、冷热分流+fallback降级、可观测闭环监控链路健康度。
关键不在堆资源，而在解耦与缓冲。同步写磁盘、直连后端、无背压机制，这三类设计在百万 QPS 下必然丢日志或拖垮业务。
异步解耦：让业务线程零等待
业务线程只负责快速入队，不碰 I/O。推荐用 spdlog 异步模式或 zap 的 buffered writer，背后是生产者-消费者模型：
- 队列优先选无锁环形缓冲（如 spdlog 默认的
ansync_logger），避免锁竞争； - 队列容量按峰值预估：例如日志均长 150 字节、尖峰持续 2 秒、QPS 100 万，初始队列 ≥ 30 万条（加 20% 冗余）；
- 后台消费线程设 1–2 个即可，实测单线程配合 256 字节对齐元素性能最优。
传输加固：用带确认的中间件兜底
Filebeat 或 ilogtail 直传 Kafka / Pulsar 是目前最稳路径，比直连 ES 或 HTTP 接口可靠得多：
- Kafka 启用幂等 Producer + at-least-once 语义，配合 Filebeat 的
close_inactive和clean_removed防止轮转丢行； - ilogtail 开启内置背压：Kafka 分区积压超阈值时自动限速，不爆内存也不 crash；
- 禁用 UDP syslog 或裸 HTTP POST，网络抖动就会丢数据。
落地层防止单点塌方：冷热分流 + fallback 降级
后端存储不能一刀切，要按日志价值分级处置：
- 错误日志、审计日志走强一致通道（Kafka → Flink 校验 → SLS 或 ES）；
- 调试日志、访问日志可先写本地 SSD 缓冲盘，再由 rsync 归档至对象存储；
- 必须配置 fallback 路径：主链路中断时，自动切到带时间戳与序列号的本地文件暂存，恢复后补传。
可观测闭环：日志系统自己会报警
不能只看业务指标，要监控日志链路自身健康度：
- 采集端：Filebeat 的
harvester.running、libbeat.pipeline.queue.acked；ilogtail 的input_bytes_total与output_send_failures； - 传输端：Kafka 消费延迟（Lag）、重试率、压缩率突变；
- 写入端：ES bulk reject 数、SLS 写入 429 错误频次。
