┌─────────────────────────────────────────────────────────────────┐
│                        数据来源层                                │
│   闸机设备 / 门禁控制器 / 设备日志 / APP告警 / 业务系统          │
└───────────────┬─────────────────────────┬───────────────────────┘
                │                         │
         SDK/Agent采集              HTTP/MQTT上报
                │                         │
┌───────────────▼─────────────────────────▼───────────────────────┐
│                        接入层（网关）                             │
│         Nginx / API Gateway / MQTT Broker（EMQ X）               │
│              限流 / 鉴权 / 协议转换 / 负载均衡                    │
└───────────────────────────┬─────────────────────────────────────┘
                            │
┌───────────────────────────▼─────────────────────────────────────┐
│                     Kafka 消息总线层                              │
│                                                                   │
│  Topic: gate-events     Topic: device-logs    Topic: app-alerts  │
│  Partition: 128         Partition: 64         Partition: 32       │
│  Replication: 3         Replication: 3        Replication: 3      │
│                                                                   │
│              Broker Cluster（3~5 节点）                           │
└────────┬──────────────────┬──────────────────┬───────────────────┘
         │                  │                  │
┌────────▼──────┐  ┌────────▼──────┐  ┌───────▼────────┐
│  实时流处理层  │  │  告警处理层    │  │  日志归档层     │
│  Flink Job    │  │  Flink Job    │  │  Kafka Connect │
│  亚秒级聚合   │  │  去重/降噪/聚合│  │  写入 HDFS/ES  │
└────────┬──────┘  └────────┬──────┘  └───────┬────────┘
         │                  │                  │
┌────────▼──────────────────▼──────────────────▼────────┐
│                       存储层                            │
│   Redis（热数据）  ClickHouse（分析）  ES（检索）        │
│   MySQL（业务）    HDFS（归档）        InfluxDB（时序）  │
└───────────────────────────────────────────────────────┘

# 批量发送 —— 提升吞吐
batch.size=131072              # 128KB，攒够再发
linger.ms=5                   # 最多等5ms，平衡延迟与吞吐
buffer.memory=134217728        # 发送缓冲区 128MB

# 压缩 —— 降低网络与磁盘开销
compression.type=lz4           # LZ4：压缩率与速度最佳平衡

# 可靠性
acks=1                         # 闸机事件：Leader确认即可（允许少量丢失）
acks=all                       # 告警数据：全副本确认（不可丢失）
retries=3
retry.backoff.ms=100

# 幂等（防重复写入）
enable.idempotence=true

目标：从设备上报 → 业务消费 < 500ms

延迟拆解：
├── 设备上报网络传输：   ~50ms
├── 接入网关处理：       ~10ms
├── Kafka Producer发送： ~5ms  （linger.ms=5）
├── Kafka Broker写入：   ~5ms  （顺序IO + page cache）
├── Flink消费处理：      ~100ms（mini-batch，100ms窗口）
└── 结果写入Redis：      ~10ms
                    合计: ~180ms  ✅ 满足亚秒级要求

# 性能优化
num.network.threads=8
num.io.threads=16
socket.send.buffer.bytes=102400
socket.receive.buffer.bytes=102400
log.flush.interval.messages=10000    # 批量刷盘，减少IO次数

# 高可用
default.replication.factor=3
min.insync.replicas=2                # 至少2副本同步才确认写成功
unclean.leader.election.enable=false # 禁止脏选举，保障数据一致性

# 容量规划（单Broker）
log.dirs=/data1/kafka,/data2/kafka   # 多磁盘分散IO
log.retention.hours=24
log.segment.bytes=1073741824         # 1GB/segment

app-alerts-raw
      │
      ▼
┌─────────────────────────────────────────────────────┐
│                  Flink 告警处理 Job                  │
│                                                      │
│  Step1: 实时去重                                     │
│    └─ 基于 alertId + deviceId + alertType 组合Key   │
│       布隆过滤器（Redis BitMap）快速判重              │
│       TTL = 10分钟，避免短时重复告警                  │
│                                                      │
│  Step2: 降噪处理                                     │
│    └─ 规则引擎过滤无效告警（心跳误报、测试告警等）    │
│       滑动窗口：同设备同类型告警 60s 内超过阈值才上报 │
│                                                      │
│  Step3: 告警聚合                                     │
│    └─ 滚动窗口（1min）：相同区域/类型告警合并为1条   │
│       输出：聚合告警 + 影响设备列表 + 告警计数        │
└─────────────────────────────────────────────────────┘
      │                    │
      ▼                    ▼
app-alerts-clean     app-alerts-agg
（去重后原始）        （聚合告警）

规则1：频率过滤
  同一设备 + 同一告警类型，60s 内超过 N 次 → 合并为1条，附聚合次数

规则2：阈值过滤  
  心跳超时误报：设备离线后 30s 内的告警忽略
  
规则3：白名单过滤
  测试设备、已知维修中设备 → 告警直接丢弃

规则4：关联分析
  同一时刻同区域 > 80% 设备告警 → 判定为区域性故障，合并上报

规则5：告警风暴熔断
  1min 内原始告警 > 10000 条 → 触发熔断，采样 10% 上报，其余计数

Layer 1：接入总线（高频、短保留）
  ├── gate-events        闸机通行事件，保留 24h
  ├── device-logs        设备日志，保留 72h
  └── app-alerts-raw     原始告警，保留 48h

Layer 2：处理总线（清洗后，中期保留）
  ├── gate-events-clean  清洗后闸机事件，保留 7d
  ├── app-alerts-clean   去重后告警，保留 7d
  └── app-alerts-agg     聚合告警，保留 30d

Layer 3：分发总线（按消费方隔离）
  ├── sink-clickhouse    → ClickHouse 实时分析
  ├── sink-es            → Elasticsearch 全文检索
  ├── sink-mysql         → MySQL 业务写入
  └── sink-hdfs          → HDFS 离线归档

# 吞吐优化
fetch.min.bytes=65536          # 64KB，攒够再拉，减少请求次数
fetch.max.wait.ms=100          # 最多等100ms
max.poll.records=1000          # 每次拉取最多1000条

# 可靠性
enable.auto.commit=false       # 关闭自动提交，手动控制Offset
auto.offset.reset=earliest     # 消费者组首次消费从最早开始

# 并行度
# 消费者线程数 = Partition数，1:1效率最高

监控指标：consumer_group_lag > 阈值

处理流程：
  Lag < 10万   → 正常，观察
  Lag 10~100万 → 告警，检查消费者性能，适当扩容
  Lag > 100万  → 紧急扩容Consumer（不超过Partition数）
              + 临时提升 max.poll.records
              + 检查下游写入瓶颈（DB慢查询等）
  Lag 持续不降 → 启动消费加速Job（跳过非关键数据）
              + 通知业务方降级处理

Kafka JMX Metrics
      │
      ▼
Prometheus（采集）→ Grafana（可视化）→ AlertManager（告警）
      │
      ▼
关键 Dashboard：
  ├── Broker Overview（吞吐、分区、ISR状态）
  ├── Producer Metrics（发送速率、错误率、延迟）
  ├── Consumer Group Lag（各消费组积压趋势）
  └── Topic 热力图（各分区流量均衡情况）