分布式事务-最大努力通知

最大努力通知步骤

最大努力通知(Best-Effort Notification)是一种在分布式系统中处理分布式事务的方法之一,它强调尽力而为,不保证完全的事务一致性,但可以通过一定的机制来提供部分保证。在最大努力通知中,主要目标是在发生分布式事务失败时,尽可能地通知相关的参与者或系统,以尝试进行后续的处理或补偿。

最大努力通知的主要特点和流程如下:

  1. 事务执行: 参与者执行本地事务操作。
  2. 通知机制: 当参与者的事务操作成功完成后,它会尝试通知其他相关的参与者。通知可以通过消息队列、HTTP请求、RPC等方式进行。
  3. 异步通知: 最大努力通知通常是异步的,即通知发出后,不会等待接收方的确认。这是为了避免通知过程的延迟影响到当前事务的性能。
  4. 接收和处理: 接收通知的系统可能会执行一些处理操作,如更新状态、执行补偿操作等,以保持系统的一致性。
  5. 重试和补偿: 如果通知发送失败或接收方处理失败,通知服务可以实施重试机制,尝试多次发送通知。同时,接收方可能需要实施补偿机制来纠正事务操作的影响。

与本地消息事务区别

发起通知者通过一定的最大努力机制通知接收者业务处理的结果。具体而言:

通知消息可以重复发送。因为接收方可能无法接收到通知,所以应该有一些机制来重复通知消息。 消息可以被检查。如果即使经过最大努力,接收方仍未收到通知,或者接收方已经消费了消息但希望再次消费,接收方应该被允许主动从发起通知者那里查询消息信息。 之前介绍的本地消息传递和事务性消息传递模型都产生可靠的消息,与本文介绍的最大努力通知模型有什么不同呢?

在本地消息表模型中,发起通知者确保消息被发送并传递到接收方。换句话说,消息的可靠性由通知方保证。

而在最大努力通知模型中,发起通知者尽其所能通知业务处理结果给接收者,但消息仍然可能未被接收。因此,接收方需要主动调用发起通知者的接口来查询业务处理的结果,这意味着通知的可靠性依赖于接收方。

使用最大努力通知模型的问题

最大努力通知模式在处理分布式事务时具有一些问题和限制,这些问题可能会影响系统的可靠性和一致性。以下是一些最大努力通知模式可能面临的问题:

  1. 消息丢失: 由于最大努力通知不保证通知一定会被接收方收到,存在消息丢失的风险。即使通知发送了多次,也无法完全消除这种风险。

  2. 不确定性: 接收方无法确定通知的状态,因为通知可能被接收、未被接收、接收后被处理失败等情况。这可能导致数据的不一致性。

  3. 接收方延迟: 由于通知是异步的,接收方可能存在不同程度的延迟,这可能导致业务处理的不同步。

  4. 重复通知: 在通知过程中,由于网络等原因,可能会导致通知的重复发送,从而使接收方重复处理相同的事务。

  5. 补偿复杂性: 如果发生通知失败或接收方处理失败,需要设计复杂的补偿机制来纠正业务操作的影响,这可能增加系统的复杂性。

  6. 接收方主动查询: 为了保证通知的可靠性,接收方需要主动查询通知结果,这可能增加系统的负担和复杂性。

  7. 不适用于关键业务: 最大努力通知模式适用于一些不太关键的业务场景,但对于需要高度一致性和可靠性的关键业务,这种模式可能不合适。

最大努力通知模式虽然提供了一种灵活的处理分布式事务的方法,但由于其不确定性和局限性,可能不适用于所有场景,特别是对于要求高度一致性和可靠性的应用。在选择通知模式时,需要根据业务需求和系统要求综合考虑。

相关推荐
Csvn1 小时前
Day 3:LIKE 与模式匹配 — 让查询学会"模糊搜索"
后端·sql
ACP广源盛139246256731 小时前
IX8024@ACP# 搭配此芯 AI 服务器 + 爱芯元智产品完整方案
大数据·运维·服务器·人工智能·分布式·嵌入式硬件
Hazenix2 小时前
Go 指南:一篇文章速通 Golang
开发语言·后端·golang
灯澜忆梦2 小时前
GO_复合类型---指针
开发语言·后端·golang
IT_陈寒3 小时前
SpringBoot自动装配坑了我一天,原来问题出在这
前端·人工智能·后端
星栈3 小时前
深度复盘:比 EventLoop 更隐蔽!Node 微任务堆积引发的线上接口雪崩事故
后端·node.js
名字还没想好☜4 小时前
Go slice 的 append 陷阱:共享底层数组导致的数据串改
开发语言·后端·golang·go·slice
诸神缄默不语4 小时前
FastAPI后端配置CORS中间件支持浏览器跨域访问
后端·fastapi
Fanta丶4 小时前
14.Activiti7 网关 排他网关ExclusiveGateway、并行网关ParallelGateway
后端
明月_清风4 小时前
robots.txt 完全指南:从入门到精通
后端·爬虫