🌊 Oceanus 流计算在复杂计算任务中，状态存储与故障恢复是保证exactly-once语义和系统稳定性的关键环节。🚀
状态存储
Oceanus 主要依赖以下几种机制进行状态存储：
- 检查点 (Checkpoint):
- Oceanus 定期将算子的状态快照持久化到可靠存储上，如 HDFS、COS (腾讯云对象存储) 等。 📸
- 检查点包含了算子在特定时间点的所有状态数据，例如窗口聚合的中间结果、机器学习模型的参数等。 📊
- 检查点策略可以配置，例如设置检查点间隔、超时时间等。⏰
- 触发方式通常是基于时间的，也可以基于记录数或自定义条件。
- 保存点 (Savepoint):
- 保存点是用户手动触发的检查点，用于升级、迁移或调试作业。 💾
- 与检查点不同，保存点不会被自动删除，可以长期保存。 🕰️
- 保存点在保存时会停止作业，确保状态一致性。
- RocksDB State Backend:
- Oceanus 支持使用 RocksDB 作为状态后端，将状态数据存储在本地磁盘上。 💽
- RocksDB 具有高性能和可扩展性，适合存储大规模状态数据。 💪
- 适用于需要快速读写状态的场景。
- Memory State Backend:
- Oceanus 也支持将状态数据存储在内存中。 🧠
- 内存状态后端速度快，但容量有限，且存在数据丢失的风险。 ⚠️
- 适用于状态较小且对性能要求高的场景，例如简单的计数器。
- 状态TTL (Time-To-Live):
- Oceanus 支持为状态设置 TTL，过期状态会被自动清理。 🗑️
- TTL 可以防止状态无限增长，避免内存溢出。
- 适用于只需要最近一段时间状态的场景，例如滑动窗口。
故障恢复
当 Oceanus 作业发生故障时，系统会尝试从最近的可用检查点或保存点恢复。 🛠️
- 自动重启:
- Oceanus 支持自动重启失败的作业。 🔄
- 重启策略可以配置，例如固定延迟、指数退避等。 ⏳
- 系统会尝试从最近的检查点或保存点恢复作业状态。
- 状态恢复流程:
- 当作业重启后，Oceanus 会从检查点或保存点读取状态数据。 📚
- 算子会根据读取的状态数据，恢复到故障发生前的状态。
- 系统会重新处理从检查点到故障期间的数据，保证exactly-once语义。 💯
- Flink 的 Chandy-Lamport 算法:
- Oceanus 底层依赖 Flink 的 Chandy-Lamport 算法来实现分布式快照。 🤖
- 该算法保证在不停止作业的情况下，生成一致性的状态快照。
- 算法通过在数据流中插入 barrier 来标记检查点的边界。
- 增量检查点:
- Oceanus 支持增量检查点，只保存状态的增量变化。 ➕
- 增量检查点可以减少检查点的大小和时间，提高恢复速度。 🚀
- 适用于状态变化频繁的场景。
- 本地恢复:
- 如果作业是从 RocksDB 状态后端恢复，Oceanus 可以尝试从本地磁盘恢复状态。 📍
- 本地恢复速度快，可以减少恢复时间。
- 但需要保证本地磁盘的可靠性。
最佳实践
- 选择合适的 State Backend:
- 根据状态大小、性能要求和容错需求，选择合适的 State Backend。 🤔
- 大规模状态建议使用 RocksDB，小规模状态可以使用 Memory。
- 合理配置 Checkpoint 间隔:
- Checkpoint 间隔越短，恢复时间越短，但会增加系统负担。 ⚖️
- 根据业务需求，合理配置 Checkpoint 间隔。
- 监控 Checkpoint 状态:
- 监控 Checkpoint 的大小、时间和成功率，及时发现问题。 🔍
- 可以使用 Oceanus 的监控面板或 API 进行监控。
- 定期创建 Savepoint:
- 在升级、迁移或调试作业前，创建 Savepoint。 🗓️
- Savepoint 可以作为作业的备份，防止数据丢失。
- 开启增量检查点:
- 如果状态变化频繁，开启增量检查点可以提高性能。 👍
- 但需要注意增量检查点可能增加恢复的复杂性。
总而言之，Oceanus 通过检查点、保存点等机制实现了状态存储，并通过自动重启和状态恢复流程保证了故障恢复能力。 掌握这些概念并合理配置参数，能够构建稳定可靠的流计算应用。🎉
