ELK 架构中 Redis 起什么作用？

Redis 在 ELK 里不是必需组件，而是可选的"缓冲层"：Filebeat → Redis → Logstash → Elasticsearch。它解决三个问题：流量尖峰削峰、下游故障时的数据暂存、采集端与处理端解耦。

为什么加这一层

1. 削峰填谷：日志洪峰来临时，Redis 内存队列顶住写入，Logstash 按自己的能力消费——可缓冲短时峰值，但队列有限且长期入速大于消费速率仍会耗尽容量。

2. 故障缓冲：ES 或 Logstash 宕机时，日志在 Redis 中堆积等待，恢复后继续——不保证无损；持久化、消费确认和故障窗口都影响交付。

3. 解耦：采集端只认 Redis，处理端扩容、重启、升级互不影响。

架构示意

Filebeat（各节点） → Redis（本例list队列） → Logstash（多个实例消费） → ES → Kibana

Logstash 侧配置：

input {
  redis {
    host => "redis.internal"
    key => "logs"
    data_type => "list"
  }
}

取舍与替代

• Redis可用RDB快照或AOF，但均有相应数据丢失窗口；list弹出后到下游持久入库前也可能丢失——要更强保障用 Kafka（磁盘持久化、消费组）；
• 小流量场景不需要这层——Filebeat 直连 Logstash/ES 即可，Filebeat 自身的背压机制已够用。

常见问题（FAQ）

Q：Redis 和 Kafka 在这层怎么选？ 日志量大、要多消费者复用、要强持久化选 Kafka；轻量缓冲 Redis 够用。

Q：Redis key 用什么数据结构？ 标准Logstash redis input支持list/channel/pattern_channel，不直接支持Streams消费组；改用Streams需另外实现/选择兼容消费者。Filebeat配置的datatype/key需与Logstash的data_type/key匹配，并配置容量和eviction策略，不能让队列key被随意淘汰。