Flink 有状态函数：超时补偿回调
Flink stateful functions : compensating callback on a timeout
我正在 Flink 有状态函数中实现一个用例。我的规范强调从 有状态函数 f 开始一个业务工作流（换句话说 一组有状态函数 f1、f2、... fn 被称为顺序或并行或两者兼而有之）。 有状态函数 f 等待返回结果以更新本地状态，它还会启动超时回调，即给自己的消息。在超时时，f 检查本地状态是否已更新（它已收到结果），如果是这种情况，则生活很好。
但是，如果在超时 f 发现它还没有收到结果，它必须启动一个补偿工作流来撤消 有状态函数 f1、f2、... fn 的任何更改 可能已经收到了。
Flink stateful functions framework 是否支持设计pattern/use case，还是应该在应用层实现？实现这种解决方案的最简单设计是什么？例如，如何知道工作流有状态函数 f1、f2、... fn 的哪些函数受到超时调用（控制流已超时）的影响？ Flink 安全功能以及集成消息传递和状态 的概念如何促进这种模式？
谢谢。
我在 Apache Flink 邮件列表上发布了这个问题，并得到了 Igal Shilman 的以下回复，感谢 Igal。
我想提的第一件事是，如果您的原创
该场景的动机是对瞬态故障的关注，例如：
- 功能 Y 是否收到过功能 X 发送的消息？
- 是否发送消息失败？
- 目标函数是否接受发送给它的消息？
- 是不是消息顺序搞错了？
- 等等'
然后，StateFun 消除了所有这些问题和整个 class
否则您将不得不自己处理的暂时性错误
您的业务逻辑（如重试、退避、服务发现等）。
现在，如果您的激励场景不是关于暂时性错误，而是更多
关于事务性工作流程，那么正如 Dawid 提到的那样，您必须
实行
这在您的应用程序逻辑中。我认为你描述的方式
流程应直接映射到协调功能（每个流程实例）
在其内部状态跟踪 results/timeouts。
这是一个草图：
一个流协调器函数 - 它会被输入调用
启动流程所必需的。它将开始调用相关的
函数（由流的 DAG 定义）并保持内部状态
表明
调用了哪些功能（地址）及其完成状态。
当流程成功完成时，协调器可以安全地丢弃它的
状态。
在任何情况下，协调器决定中止流程（内部
超时/外部消息/等'）它必须检查其内部
声明并启动一个补偿工作流（向
已经 succeed/in 个进度函数）
流中的每个函数都必须接受来自协调器的消息，
依次回复成功或失败。
我正在 Flink 有状态函数中实现一个用例。我的规范强调从 有状态函数 f 开始一个业务工作流（换句话说 一组有状态函数 f1、f2、... fn 被称为顺序或并行或两者兼而有之）。 有状态函数 f 等待返回结果以更新本地状态，它还会启动超时回调，即给自己的消息。在超时时，f 检查本地状态是否已更新（它已收到结果），如果是这种情况，则生活很好。
但是，如果在超时 f 发现它还没有收到结果，它必须启动一个补偿工作流来撤消 有状态函数 f1、f2、... fn 的任何更改 可能已经收到了。
Flink stateful functions framework 是否支持设计pattern/use case，还是应该在应用层实现？实现这种解决方案的最简单设计是什么？例如，如何知道工作流有状态函数 f1、f2、... fn 的哪些函数受到超时调用（控制流已超时）的影响？ Flink 安全功能以及集成消息传递和状态 的概念如何促进这种模式？
谢谢。
我在 Apache Flink 邮件列表上发布了这个问题，并得到了 Igal Shilman 的以下回复，感谢 Igal。
我想提的第一件事是，如果您的原创 该场景的动机是对瞬态故障的关注，例如：
- 功能 Y 是否收到过功能 X 发送的消息？
- 是否发送消息失败？
- 目标函数是否接受发送给它的消息？
- 是不是消息顺序搞错了？
- 等等'
然后，StateFun 消除了所有这些问题和整个 class 否则您将不得不自己处理的暂时性错误 您的业务逻辑（如重试、退避、服务发现等）。
现在，如果您的激励场景不是关于暂时性错误，而是更多 关于事务性工作流程，那么正如 Dawid 提到的那样，您必须 实行 这在您的应用程序逻辑中。我认为你描述的方式 流程应直接映射到协调功能（每个流程实例） 在其内部状态跟踪 results/timeouts。
这是一个草图：
一个流协调器函数 - 它会被输入调用 启动流程所必需的。它将开始调用相关的 函数（由流的 DAG 定义）并保持内部状态 表明 调用了哪些功能（地址）及其完成状态。 当流程成功完成时，协调器可以安全地丢弃它的 状态。 在任何情况下，协调器决定中止流程（内部 超时/外部消息/等'）它必须检查其内部 声明并启动一个补偿工作流（向 已经 succeed/in 个进度函数）
流中的每个函数都必须接受来自协调器的消息， 依次回复成功或失败。