处理异步写入方案中的错误

发布于 2024-11-01 04:12:02 字数 241 浏览 0 评论 0原文

异步写入或后写的想法是,客户端提交写入操作的请求,然后开始愉快的工作,而无需等待写入操作结束。

从我对这个主题的阅读中,我不清楚的是如果错误发生,如何处理它们。一种策略可能是记录并忽略它们。好的,所以我想客户端必须应对后续读取操作失败的情况。采用什么策略来处理不可避免的写入失败?它们是否以任何方式暴露给用户?我可以想象一些非常奇怪的应用程序行为。想象一下,如果数据库出现故障,并且执行了多个写入操作(从客户端的角度来看),而实际上没有发生任何持久性。

The idea of asynchronous write, or write-behind, is that clients submit a request for a write operation, and then go their merry way without waiting for the write operation to conclude.

What isn't clear to me from my reading on the subject is how errors might be handled in case they happen. One strategy might be to log and ignore them. OK, so I suppose the client then has to cope when subsequent read operations fail. What strategies are employed to deal with inevitable write failures? Are they exposed to the user in any way? I can imagine some very odd application behaviour. Imagine if the database went down, and several write operations were performed (from the client's point of view) without any persistence in fact occurring.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

阳光下的泡沫是彩色的 2024-11-08 04:12:02

看看 CQRS。

请参阅 Greg Young 的解释:

http:// /codebetter.com/gregyoung/2010/02/16/cqrs-task-based-uis-event-source-agh/

希望这会有所帮助。

Take a look at CQRS.

See Greg Young's explanation:

http://codebetter.com/gregyoung/2010/02/16/cqrs-task-based-uis-event-sourcing-agh/

hope this helps.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文