我正在flink状态函数中实现一个用例。我的规范强调了从业务工作流的有状态函数开始（换句话说，一组有状态函数f1、f2、…fn被依次或并行调用，或者两者都被调用）。有状态函数f等待返回结果以更新本地状态，同时启动超时回调，即向自身发送消息。超时时，f检查本地状态是否已更新（它已收到结果），如果是这种情况，则检查寿命是否良好。
但是，如果在超时时f发现它还没有收到结果，它必须启动一个补偿工作流来撤消有状态函数f1、f2……fn可能已经收到的任何更改。
flink有状态函数框架是否支持设计模式/用例，或者应该在应用程序级别实现？实现这种解决方案最简单的设计是什么？例如，如何知道工作流有状态函数f1，f2，…fn的哪些函数受timedout调用的影响（其中控制流已超时）？flink sateful函数和集成消息传递和状态的概念如何促进这种模式？
谢谢您。
1条答案
按热度按时间lokaqttq1#
我把这个问题贴在apache-flink邮件列表上，得到了igal-shilman的以下回复，这要感谢igal。
我想提到的第一件事是，如果您对该场景的最初动机是关注暂时性故障，例如：
函数y是否收到过函数x发送的消息？
发送消息失败了吗？
目标函数是否接受发送给它的消息？
信息的顺序弄错了吗？
等等
然后，statefun消除了所有这些问题和一系列暂时性错误，否则您将不得不在业务逻辑中自行处理这些问题（如重试、退避、服务发现等）。
现在，如果您的激励场景不是关于暂时性错误，而是关于事务性工作流，那么正如dawid提到的，您必须在应用程序逻辑中实现这一点。我认为您描述流的方式应该直接Map到一个协调函数（每个流示例），该函数在其内部状态中跟踪结果/超时。
下面是一个草图：
一个流协调器函数-它将通过启动流所需的输入被调用。它将开始调用相关函数（由流的dag定义），并保持一个内部状态，指示调用了哪些函数（地址）及其完成状态。当流成功完成时，协调器可以安全地放弃其状态。在协调器决定中止流（内部超时/外部消息等）的任何情况下，它都必须检查其内部状态并启动补偿工作流（向已成功/正在进行的函数发送特殊消息）
流中的每个函数都必须依次接受来自协调器的消息，并以成功或失败作为答复。