我正在寻找一个容错流处理引擎。因此，我用一个简单的工作测试flink:sockettextstreamwordcount示例，它从文本套接字读取单词！我在一个有3个任务管理器的独立集群上运行了它，找到了负责从socket读取的任务管理器！我杀死了taskmanger（kill-9）并等待结果：大约30秒后，jobmanger移除了死去的taskmanger！并将作业分配为失败！
看来，容错保证不是一般的事情，取决于工作！我说得对吗？有什么可以解释的参考资料吗？
我正在寻找一个容错流处理引擎。因此，我用一个简单的工作测试flink:sockettextstreamwordcount示例，它从文本套接字读取单词！我在一个有3个任务管理器的独立集群上运行了它，找到了负责从socket读取的任务管理器！我杀死了taskmanger（kill-9）并等待结果：大约30秒后，jobmanger移除了死去的taskmanger！并将作业分配为失败！
看来，容错保证不是一般的事情，取决于工作！我说得对吗？有什么可以解释的参考资料吗？
1条答案
按热度按时间jdzmm42g1#
flink中的容错性不仅仅依赖于在一个taskmanager失败时在另一个taskmanager上重新启动一个任务。您还需要启用检查点，并且对于端到端的精确一次保证，您需要具有支持重播的源和幂等或事务性的接收器。
但是，在您的情况下，首先要开始的可能是配置一个重启策略——请参阅此处的文档。
flink文档的其他几个部分与此主题相关。一个好的起点是流式容错部分。有关检查点、状态后端、容错保证和高可用性的部分也很重要。
data artisans网站上有一篇博文，展示了通过检查点进行故障恢复的出色工作。同时还提供了一个附带的youtube视频和github repo。