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

最大努力通知步骤

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

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

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

与本地消息事务区别

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

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

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

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

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

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

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

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

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

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

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

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

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

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

相关推荐
ssshooter11 分钟前
Tauri 2 iOS 开发避坑指南:文件保存、Dialog 和 Documents 目录的那些坑
前端·后端·ios
追逐时光者25 分钟前
一个基于 .NET Core + Vue3 构建的开源全栈平台 Admin 系统
后端·.net
程序员飞哥30 分钟前
90后大龄程序员失业4个月终于上岸了
后端·面试·程序员
彭于晏Yan2 小时前
Redisson分布式锁
spring boot·redis·分布式
GetcharZp2 小时前
Git 命令行太痛苦?这款 75k Star 的神级工具,让你告别“合并冲突”恐惧症!
后端
Victor3563 小时前
MongoDB(69)如何进行增量备份?
后端
Victor3563 小时前
MongoDB(70)如何使用副本集进行备份?
后端
千寻girling4 小时前
面试官 : “ 说一下 Python 中的常用的 字符串和数组 的 方法有哪些 ? ”
人工智能·后端·python
ywf12155 小时前
Spring Boot接收参数的19种方式
java·spring boot·后端
LSTM975 小时前
C# 实战:轻松提取 PDF 文件中的文字内容
后端