Flink不能直接用Redis Pub/Sub当Source，因其默认Source不支持长连接流式订阅；Jedis阻塞式订阅破坏Checkpoint机制且cancel失效；需手动实现可checkpoint、可取消、并发安全的自定义Source，或改用Lettuce异步客户端+Redis Stream保障Exactly-Once。
为什么 Flink 不能直接用 Redis Pub/Sub 当作 Source
因为 RedisSourceFunction（包括 Bahir 的 flink-connector-redis）默认只支持读取键值快照（如 HGETALL、LRANGE），不原生支持订阅频道的长连接流式消费。一旦你尝试把 PUBSUB SUBSCRIBE 塞进 SourceFunction.run()，会立刻遇到两个硬伤：Jedis 阻塞式订阅无法配合 Flink 的 checkpoint 机制；线程卡死导致 cancel() 失效，作业无法优雅关闭。
用 Jedis + RichParallelSourceFunction 手动实现订阅源
必须绕过官方 Connector，自己封装一个可 checkpoint、可取消、能并发分片的 Source。核心要点如下：
-
Jedis实例不能复用在多线程里，每个并行子任务需独占一个Jedis连接（或JedisPool单资源借出） - 订阅逻辑必须包裹在
while (isRunning) { ... }循环内，并在每次循环开头检查Thread.interrupted() - 每条收到的
PUBLISH消息需立即调用sourceContext.collect()，不能缓存或批量提交 - 必须重写
snapshotState()：记录当前已处理的message id（若使用 Redis Stream）；纯 Pub/Sub 场景则只能靠外部 offset 管理（比如把最后时间戳写入 Redis key） - 示例关键片段：
public class RedisPubSubSource implements RichParallelSourceFunction<string> { private transient Jedis jedis; private volatile boolean isRunning = true; private String channel; @Override public void open(Configuration parameters) throws Exception { jedis = new Jedis("localhost", 6379); channel = "flink:events"; } @Override public void run(SourceContext<string> ctx) throws Exception { jedis.subscribe(new JedisPubSub() { @Override public void onMessage(String channel, String message) { ctx.collect(message); // 立即发出 } }, channel); while (isRunning) { Thread.sleep(100); // 防止空转耗 CPU } } @Override public void cancel() { isRunning = false; if (jedis != null) jedis.close(); } }</string></string>
用 Lettuce 替代 Jedis 支持异步与 Reactive 订阅
如果你的 Flink 作业部署在高并发或低延迟敏感场景（比如风控规则实时匹配），Jedis 的阻塞模型会成为瓶颈。Lettuce 是唯一被广泛验证可用于 Flink Pub/Sub 场景的 Redis 客户端，原因在于：
- 它基于 Netty，天然支持异步命令和响应式流（
Mono/Flux） -
StatefulRedisPubSubConnection可注册回调，避免轮询或阻塞线程 - 配合
AsyncFunction或自定义Source，能真正实现非阻塞、背压感知的数据拉取 - 注意：Flink 1.15+ 才较好支持
CompletableFuture回调链，低于该版本建议用RichParallelSourceFunction+LettuceClientResources手动管理连接生命周期 - 关键配置项：
client.setOptions(ClientOptions.builder().autoReconnect(true).build())，否则网络抖动时订阅会静默断开
订阅数据如何对齐 Flink Checkpoint 与 Exactly-Once
这是最容易被跳过的致命环节——Pub/Sub 本身是 at-least-once 语义，而 Flink 默认 checkpoint 不会捕获 Redis 的订阅状态。结果就是：作业重启后重复消费、漏消费、甚至因消息无序导致业务逻辑错乱。
- 纯
PUB/SUB无法做到 Exactly-Once，只能退到 At-Least-Once + 幂等写入：下游 Sink 必须按业务主键去重（如用HSET user:123 last_event_ts+EXPIRE） - 如果必须强一致性，请改用
Redis Stream（XREADGROUP）：每个 Flink 并行子任务绑定独立 consumer group，通过snapshotState()持久化lastId到 Flink state backend - 千万别把 offset 存在本地文件或内存里——Flink 重启后状态丢失，等于没做
- 测试时务必模拟 kill -9 作业进程，观察重启后是否从断点续订；仅靠
cancel()正常退出不能代表生产可靠性
真实项目里最常被忽略的，不是怎么连上 Redis，而是怎么让“订阅”这个动作，在 Flink 的容错生命周期里真正活下来——它既不能抢走 checkpoint 线程，也不能在失败时悄悄丢消息。
