这里有一个注意点，就是flink端的精准一次
1.barrier对齐精准和一次非对齐精准一次 对比
| 维度 | Barrier 对齐的精准一次 | Barrier 非对齐的精准一次 |
|---|---|---|
| 触发条件 | 需等待所有输入流的 Barrier 对齐后才能触发检查点 | 收到第一个 Barrier 立即触发，无需等待对齐 |
| 数据处理方式 | 对齐期间阻塞部分数据流，仅处理未到达 Barrier 的分区数据 | 允许所有数据继续流动，将 Barrier 后的数据标记为 in-flight 并保存 |
| 状态保存内容 | 仅保存算子自身的状态（如累加器、窗口状态） | 额外保存输入/输出缓冲区中的未处理数据（in-flight 数据） |
| 资源开销 | 低（仅保存状态），但可能因对齐阻塞导致吞吐下降 | 高（需保存大量缓冲区数据），但减少阻塞时间 |
| 适用场景 | 低延迟要求不高的场景，或输入流速率均衡的场景 | 高吞吐、高延迟或反压严重的场景 |
1. Barrier 对齐的精准一次
- 触发逻辑：
当算子收到所有输入流的 Barrier 后，才会触发状态快照。例如，若某个算子有两个输入流，需等待两个流的 Barrier 均到达 。 - 数据处理流程：
- 部分输入流的 Barrier 先到达时，该流后续数据会被缓存（阻塞），其他流的数据继续处理 。
- 所有 Barrier 对齐后，统一保存状态并向下游广播 Barrier；
- 优点：
- 状态体积小，恢复速度快；
- 严格保证数据仅处理一次；
2. Barrier 非对齐的精准一次
- 触发逻辑：
收到任意一个输入流的 Barrier 后立即触发快照，无需等待其他流的 Barrier ； - 数据处理流程：
- 继续处理所有输入流的数据，包括 Barrier 之后的数据；
- 将 Barrier 到达时未处理的数据（输入缓冲区）和已处理但未输出的数据（输出缓冲区）标记为 in-flight 数据，与状态一起保存 ；
- 优点：
- 避免因对齐导致的阻塞，提升吞吐量和反压容错能力；
- 适用于网络延迟波动或输入流速率差异大的场景
生产环境选择建议
| 场景 | 推荐机制 | 理由 |
|---|---|---|
| 输入流速率均衡且延迟敏感 | Barrier 对齐 | 避免额外存储开销，恢复效率高
1 4 |
| 高吞吐或反压严重 | Barrier 非对齐 | 减少阻塞时间，缓解反压影响
6 7 |
| 状态体积敏感（如 TB 级状态） | Barrier 对齐 | 非对齐模式保存的 in-flight 数据可能显著增加存储成本
3 7 |
扫一扫
620
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
