问题一：files-to-delete 的执行为什么可以异步进行？
files-to-delete 的执行为什么可以异步进行？
参考回答：
files-to-delete 的执行失败只会留下一些无用的文件残留，不会影响到副本的可用性。因此，可以异步进行这些操作，即使失败也有兜底策略进行清理，不会对整体流程造成重大影响。
关于本问题的更多回答可点击原文查看：
https://developer.aliyun.com/ask/671962
问题二：除了 Checkpoint 跨机房副本制作，还进行了哪些状态稳定性方面的优化？
除了 Checkpoint 跨机房副本制作，还进行了哪些状态稳定性方面的优化？
参考回答：
除了 Checkpoint 跨机房副本制作外，还进行了其他三个方面的优化，包括但不限于改进状态后端（如 RocksDB）的配置和性能、优化状态快照和恢复的流程、以及加强状态一致性的校验等，以提升 Flink 作业的状态稳定性。
关于本问题的更多回答可点击原文查看：
https://developer.aliyun.com/ask/671963
问题三：在使用 RocksDBStateBackend 时，作业重启后为什么会发生内存泄露？
在使用 RocksDBStateBackend 时，作业重启后为什么会发生内存泄露？
参考回答：
在使用 RocksDBStateBackend 时，如果作业发生重启并且重启后复用了未退出的 TaskManager（TM），同时在 TM 的 heap 内存充足且 full gc 不频繁的情况下，可能会触发内存泄露。原因是 RocksDBStateBackend 的清理过程中存在 bug，导致一处 RocksObject 没有被正确清理，进而使得 restart 前 RocksDB 实例的 native 内存无法释放，随着多次重启，TM 内存会持续增长，最终可能导致内存超用。
关于本问题的更多回答可点击原文查看：
https://developer.aliyun.com/ask/671964
问题四：Savepoint 后紧跟的增量 Checkpoint 为什么会退化成全量 Checkpoint 并上传大量文件？
Savepoint 后紧跟的增量 Checkpoint 为什么会退化成全量 Checkpoint 并上传大量文件？
参考回答：
Savepoint 后紧跟的增量 Checkpoint 退化成全量 Checkpoint 并上传大量文件的原因是在 Savepoint 制作完成后，错误地清理了 previous-sst-list。这个问题已经修复并提交给社区，用户可以通过升级到对应版本来避免这个问题。未修复前，由于 previous-sst-list 的错误清理，导致增量 Checkpoint 无法基于之前的 Checkpoint 增量生成，从而退化成全量 Checkpoint，上传了所有 RocksDB 文件。
关于本问题的更多回答可点击原文查看：
https://developer.aliyun.com/ask/671966
问题五：为什么需要为 Checkpoint 触发时指定单独的超时时间？
为什么需要为 Checkpoint 触发时指定单独的超时时间？
参考回答：
需要为 Checkpoint 触发时指定单独的超时时间是因为大状态作业的 Savepoint 制作时间通常远超增量 Checkpoint。在之前的版本中，Savepoint 直接采用 Checkpoint 的超时时间配置，这可能导致无法及时暴露作业在长时间制作 Savepoint 时可能遇到的问题。通过为 Savepoint 指定单独的超时时间，可以更早地发现并处理这些问题，提高作业的稳定性和可维护性。
关于本问题的更多回答可点击原文查看：
