英文:
Even hub checkpoint as resiliency mechanism
问题
我正在读取数据并进一步处理。如果处理失败，我将不会调用检查点函数。我希望不检查点将停止事件的进一步处理，直到问题得到修复。检查点是否足够确保弹性，还是我需要实现类似死亡块处理器来提供故障处理？
英文:
I am reading data and processing it further. if processing fails, I will not call checkpoint function. I hope that not checkpointing will stop further processing of events until issue is fixed. Is checkpointing sufficient for resiliency or I need to implement something like dead blob processor to provide failure handling?
答案1
得分: 1
检查点 (checkpoint) 能否保证可靠性？
不完全如此。处理将会一直继续，直到托管处理逻辑的进程停止。例如，如果你有一个处理消息的 Azure 函数，它会持续执行。
但在函数重新启动（或者你用来处理事件中心消息的其他进程）的情况下会发生什么呢？函数将从上次检查点的时刻开始处理消息。这可能不是你想要的，因为曾经导致失败的消息将被再次处理，可能再次失败。
系统默认没有死信处理或重试机制，你需要自己定义这个逻辑。
所以，简而言之：检查点的唯一目的是告诉处理逻辑从消息积压的地方开始处理。
英文:
> Is checkpointing sufficient for resiliency
No not really. The processing will continue until the process hosting the processing logic stops. Say for example you have an azure funtion processing the message this will go on.
What does happen that in the event of a function restart (or whatever process you use to handle event hub messages) the function will start processing messages from the moment of the last checkpoint. Probably not what you want because the messages that caused a failure in the past will be processed again and probably fail again.
There is no dead lettering or retry mechanism out of the box, you will need to define that logic yourself.
So, TL;DR: the checkpoint its only purpose is to tell the processing logic where to start processing message from the backlog.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论