Flink中的广播变量（Broadcast State）

Flink 的广播状态（Broadcast State） 是用于在 流处理（DataStream API）中，将一条控制流或规则流广播到所有并行实例，并在每个算子实例中维护一致的共享状态的一种机制。

主要用于：

• 动态规则下发
• 实时风控规则更新
• 动态维表更新
• 配置变更实时生效

一、为什么需要广播变量？

在分布式流处理中：

• 主数据流（如用户行为流）会被 keyBy 分区
• 控制流（如规则更新流）需要被 所有并行任务看到

如果直接 keyBy：

• 规则可能只到达某个分区
• 其他分区拿不到规则

广播状态的作用：
👉 把规则流广播给所有并行算子实例
👉 每个实例都维护一份本地规则副本

二、核心API结构

1️⃣ 定义广播状态描述符

MapStateDescriptor<String, Rule> ruleStateDescriptor =
    new MapStateDescriptor<>(
        "RulesBroadcastState",
        BasicTypeInfo.STRING_TYPE_INFO,
        TypeInformation.of(Rule.class)
    );

2️⃣ 广播规则流

BroadcastStream<Rule> broadcastStream =
    ruleStream.broadcast(ruleStateDescriptor);

3️⃣ 连接主流和广播流

dataStream
    .connect(broadcastStream)
    .process(new MyBroadcastProcessFunction());

三、BroadcastProcessFunction 详解

有两种常用类型：

通常用第二种。

代码示例

public class MyFunction extends KeyedBroadcastProcessFunction<
        String,        // 主流 key 类型
        Event,         // 主流数据类型
        Rule,          // 广播流数据类型
        Result> {      // 输出类型

    // 处理主数据流
    @Override
    public void processElement(
            Event event,
            ReadOnlyContext ctx,
            Collector<Result> out) throws Exception {

        ReadOnlyBroadcastState<String, Rule> rules =
                ctx.getBroadcastState(ruleStateDescriptor);

        Rule rule = rules.get(event.getRuleId());

        if (rule != null) {
            // 根据规则处理数据
        }
    }

    // 处理广播规则流
    @Override
    public void processBroadcastElement(
            Rule rule,
            Context ctx,
            Collector<Result> out) throws Exception {

        BroadcastState<String, Rule> state =
                ctx.getBroadcastState(ruleStateDescriptor);

        state.put(rule.getId(), rule);
    }
}

四、广播状态的核心特点

1️⃣ 每个并行实例都有一份完整副本

• 并不是共享内存
• 每个 task 自己维护一份

优点：

• 本地读取，性能高
• 不需要跨网络通信

‍

2️⃣ 只允许在广播流中写入

这是为了保证一致性。

‍

3️⃣ 支持 checkpoint

广播状态：

• 会参与 checkpoint
• 支持 exactly-once
• 故障恢复时规则状态也会恢复

‍

4️⃣ 不能 TTL

Broadcast State 不支持 State TTL。

如果规则需要过期：

• 需要自己实现过期逻辑

  • 规则自带过期时间 + 懒清理（最常用）
  • 规则流发“撤销/删除事件”（推荐，语义最清晰）
  • 广播侧“自建定时器”做周期清理（没有 TTL 时的工程解法）

‍

五、经典应用场景

1️⃣ 实时规则下发（最典型场景）

例如：

• 实时风控规则
• 实时营销活动规则
• 标签圈选规则
• 动态黑名单
• AB 实验配置
• 动态阈值参数

例如在实时营销系统中：

• 主流：用户行为数据流
• 广播流：营销规则流（从 MySQL binlog / Kafka 获取）

规则更新后，需要立即影响后续数据计算。

‍

2️⃣ 小表与大流 Join

当：

• 小表数据量较小（如几万~几十万条）
• 需要高频匹配
• 不适合频繁访问外部存储

可以将小表作为广播流，下发到所有 TaskManager 本地状态中。

‍

3️⃣ 维表实时更新

例如：

• 用户等级规则
• 风控策略表
• 配置参数表

相比普通 MapState，BroadcastState 的特点是：

每个并行实例都会完整持有一份规则副本。

六、Broadcast State vs 其他状态

‍

七、如何保持数据一致性

1️⃣ Checkpoint 机制保证状态一致

Broadcast State 属于：

Flink Managed State

它和普通 Keyed State 一样：

• 会参与 checkpoint
• 恢复时可回滚到一致状态
• 支持 Exactly-Once 语义

只要开启 checkpoint：

env.enableCheckpointing(5000);

就能保证：

• 主流数据
• 广播规则
• 状态更新

在同一一致性点对齐。

‍

2️⃣ 广播流顺序一致性

Flink 保证：

所有并行实例接收到广播流的顺序完全一致。

原因：

• 广播流是单流复制
• 每个 SubTask 接收顺序相同
• 状态更新逻辑一致

前提是：

广播流必须是单分区或保证全局顺序。

‍

3️⃣ 规则更新幂等设计（业务层保证）

Broadcast State 只能保证：

技术一致性

但不能保证：

规则逻辑正确

因此建议：

• 规则加 version 字段
• 新规则覆盖旧规则
• 使用 upsert 模式
• 禁止删除后再新增

例如：

{
  "rule_id": 1001,
  "version": 5,
  "type": "update"
}

处理逻辑：

• 只接受 version 更大的规则
• 避免乱序覆盖

‍

4️⃣ 规则和主流的时序一致性问题

需要注意一个关键问题：

广播规则更新和主流数据到达可能存在时序差异。

可能出现：

• 规则已更新
• 部分数据按旧规则处理
• 部分数据按新规则处理

解决方式：

方法一：规则带生效时间

规则增加：

{
  "rule_id": 1,
  "effective_time": 1700000000
}

在主流中判断：

if (eventTime >= rule.effectiveTime) {
   使用新规则
}

方法二：双流对齐（高级做法）

• 使用 eventTime
• 规则流也打 watermark
• 利用定时器对齐时间线

适合高精度场景。

‍

5️⃣ 故障恢复一致性

Flink 恢复时：

• 主流回滚
• 广播状态回滚
• Kafka offset 回滚

恢复到 checkpoint 对齐点。

因此：

规则和数据处理状态保持一致。

‍

八、Broadcast State 常见坑

❌ 1. 规则太大

广播状态不适合：

• 百万级大表
• 高频全量更新

否则：

• 状态膨胀
• checkpoint 变慢
• OOM

‍

❌ 2. 没开启 checkpoint

没有 checkpoint：

• 无法保证一致性
• 故障后状态丢失

‍

❌ 3. 广播流多分区乱序

如果规则来自 Kafka 多分区：

• 可能乱序
• 建议设置 1 分区

‍

❌ 4. 状态 TTL 误删

Broadcast State 不支持 TTL 自动清理
需要手动管理。