关键在“断开耦合”和“分级缓冲”：异步解耦（无锁环形队列+1–2消费线程）、传输加固（Kafka幂等+背压）、冷热分流+fallback降级、全链路可观测告警。
百万 QPS 场景下日志采集不丢、不卡，关键不在“加机器”，而在“断开耦合”和“分级缓冲”。同步写磁盘、单点直连后端、无背压机制——这三类设计在高并发下必然导致丢日志或拖垮业务。
异步解耦：把日志写入从主线程彻底剥离
业务线程只负责快速入队，不碰 I/O。推荐采用 spdlog 异步模式或 zap 的 buffered writer，背后是生产者-消费者模型：
- 队列类型优先选无锁环形缓冲（如 spdlog 的 `ansync_logger` 默认实现），避免锁竞争；
- 队列大小需结合日志平均长度与峰值持续时间预估：例如每条日志约 150 字节，预期尖峰持续 2 秒、QPS 为 100 万，则建议初始队列容量 ≥ 30 万条（预留 20% 冗余）；
- 后台消费线程数通常设为 1–2 个即可，过多反而引发上下文切换开销；实测在 Xeon Platinum 8380 上，1 线程 + 256 字节对齐的队列元素性能最优。
传输链路加固：用带 ACK 和重试的消息中间件兜底
Filebeat 或 ilogtail 直传 Kafka / Pulsar 是目前最稳的路径，比直连 Elasticsearch 或 HTTP 接口更可靠：
- Kafka 启用幂等 Producer + 至少一次语义（at-least-once），配合 Filebeat 的 `close_inactive` 和 `clean_removed` 参数，保障文件轮转时不丢行；
- ilogtail 建议开启内置背压：当 Kafka 分区积压超阈值时自动限速，而非内存暴涨或 crash；
- 避免使用无确认机制的 UDP syslog 或裸 HTTP POST，网络抖动即丢数据。
落地层防止单点塌方：冷热分流 + 失败降级
后端存储不是铁板一块，要按日志价值分级处置：
- 错误日志、审计日志走强一致通道（如 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 错误频次；
- 一旦发现队列堆积速率 > 消费速率 20%，立即触发告警并启动降级预案。
