我正在 Flink 有状态函数中实现一个用例。我的规范强调从业务工作流的有状态函数开始 （换句话说，一组有状态函数 f1、f2、... fn被顺序或并行或两者调用）。有状态函数 f等待返回结果以更新本地状态，它还启动超时回调，即给自己的消息。在超时时，f 检查本地状态是否已更新（它已收到结果），如果是这种情况，生命是好的。
但是，如果在超时时 f 发现它还没有收到结果，它必须启动一个补偿工作流来撤消有状态函数 f1、f2、... fn可能收到的任何更改。
Flink 有状态功能框架是否支持设计模式/用例等，还是应该在应用程序级别实现？实现这种解决方案的最简单设计是什么？例如，如何知道工作流有状态函数 f1, f2, ... fn 的哪些函数受到超时调用（控制流已超时）的影响？Flink 状态功能以及集成消息和状态的概念如何促成这种模式？
谢谢你。
我想提到的第一件事是，如果您对该场景的最初动机是担心暂时性故障，例如：
然后，StateFun 消除了所有这些问题和一整类临时错误，否则您必须在业务逻辑中自己处理（如重试、回退、服务发现等）。
现在，如果您的激励方案不是关于瞬态错误，而是更多关于事务工作流，那么正如 Dawid 所提到的，您必须在应用程序逻辑中实现这一点。我认为您描述流的方式应该直接映射到一个协调函数（每个流实例），该函数在其内部状态中跟踪结果/超时。
这是一个草图：
流协调器功能 - 将使用启动流所需的输入来调用它。它将开始调用相关函数（由流的 DAG 定义）并保持内部状态，指示调用了哪些函数（地址）及其完成状态。当流程成功完成时，协调器可以安全地丢弃其状态。在任何情况下，协调器决定中止流程（内部超时/外部消息/等），它都必须检查其内部状态并启动补偿工作流程（向已经成功/正在进行的功能发送特殊消息)
流程中的每个功能都必须依次接受来自协调器的消息，并以成功或失败进行回复。