iis服务器助手广告广告
返回顶部
首页 > 资讯 > 精选 >基于TCC如何实现一个通用的分布式事务框架
  • 664
分享到

基于TCC如何实现一个通用的分布式事务框架

2023-06-16 16:06:04 664人浏览 薄情痞子
摘要

这篇文章给大家介绍基于TCC如何实现一个通用的分布式事务框架,内容非常详细,感兴趣的小伙伴们可以参考借鉴,希望对大家能有所帮助。一个TCC事务框架需要解决的当然是分布式事务的管理。TCC事务模型虽然说起来简单,然而要基于TCC实现一个通用的

这篇文章给大家介绍基于TCC如何实现一个通用的分布式事务框架,内容非常详细,感兴趣的小伙伴们可以参考借鉴,希望对大家能有所帮助。

一个TCC事务框架需要解决的当然是分布式事务的管理。

TCC事务模型虽然说起来简单,然而要基于TCC实现一个通用的分布式事务框架,却比它看上去要复杂的多,不只是简单的调用一下Confirm/Cancel业务就可以了的。

小编将以spring容器为例,试图分析一下,实现一个通用的TCC分布式事务框架需要注意的一些问题。

一、TCC全局事务必须基于RM本地事务来实现

TCC服务是由Try/Confirm/Cancel业务构成的,其Try/Confirm/Cancel业务在执行时,会访问资源管理器(Resource  Manager,下文简称RM)来存取数据。

这些存取操作,必须要参与RM本地事务,以使其更改的数据要么都commit,要么都rollback。

这一点不难理解,考虑一下如下场景:

基于TCC如何实现一个通用的分布式事务框架

假设图中的服务B没有基于RM本地事务(以RDBS为例,可通过设置auto-commit为true来模拟),那么一旦[B:Try]操作中途执行失败,TCC事务框架后续决定回滚全局事务时,该[B:Cancel]则需要判断[B:Try]中哪些操作已经写到DB、哪些操作还没有写到DB.

假设[B:Try]业务有5个写库操作,[B:Cancel]业务则需要逐个判断这5个操作是否生效,并将生效的操作执行反向操作。

不幸的是,由于[B:Cancel]业务也有n(0<=n<=5)个反向的写库操作,此时一旦[B:Cancel]也中途出错,则后续的[B:Cancel]执行任务更加繁重。

因为相比第一次[B:Cancel]操作,后续的[B:Cancel]操作还需要判断先前的[B:Cancel]操作的n(0<=n<=5)个写库中哪几个已经执行、哪几个还没有执行.

这就涉及到了幂等性问题,而对幂等性的保障,又很可能还需要涉及额外的写库操作,该写库操作又会因为没有RM本地事务的支持而存在类似问题。。。

可想而知,如果不基于RM本地事务,TCC事务框架是无法有效的管理TCC全局事务的。

反之,基于RM本地事务的TCC事务,这种情况则会很容易处理。

[B:Try]操作中途执行失败,TCC事务框架将其参与RM本地事务直接rollback即可。后续TCC事务框架决定回滚全局事务时,在知道“[B:Try]操作涉及的RM本地事务已经rollback”的情况下,根本无需执行[B:Cancel]操作。

换句话说,基于RM本地事务实现TCC事务框架时,一个TCC型服务的cancel业务要么执行,要么不执行,不需要考虑部分执行的情况。

二、TCC事务框架应该接管Spring容器的TransactionManager

基于RM本地事务的TCC事务框架,可以将各Try/Confirm/Cancel业务看成一个原子服务:一个RM本地事务提交,参与该RM本地事务的所有Try/Confirm/Cancel业务操作都生效;反之,则都不生效。

掌握每个RM本地事务的状态以及它们与Try/Confirm/Cancel业务方法之间的对应关系,以此为基础,TCC事务框架才能有效的构建TCC全局事务。

TCC服务的Try/Confirm/Cancel业务方法在RM上的数据存取操作,其RM本地事务是由Spring容器的PlatfORMTransactionManager来commit/rollback的,TCC事务框架想要了解RM本地事务的状态,只能通过接管Spring的事务管理器功能。

2.1. 为什么TCC事务框架需要掌握RM本地事务的状态?

首先,根据TCC机制的定义,TCC事务是通过执行Cancel业务来达到回滚效果的。仔细分析一下,这里暗含一个事实:只有生效的Try业务操作才需要执行对应的Cancel业务操作。

换句话说,只有Try业务操作所参与的RM本地事务被commit了,后续TCC全局事务回滚时才需要执行其对应的Cancel业务操作

否则,如果Try业务操作所参与的RM本地事务被rollback了,后续TCC全局事务回滚时就不能执行其Cancel业务,此时若盲目执行Cancel业务反而会导致数据不一致。

其次,Confirm/Cancel业务操作必须保证生效。Confirm/Cancel业务操作也会涉及RM数据存取操作,其参与的RM本地事务也必须被commit。

TCC事务框架需要在确切的知道所有Confirm/Cancel业务操作参与的RM本地事务都被成功commit后,才能将标记该TCC全局事务为完成。

如果TCC事务框架误判了Confirm/Cancel业务参与RM本地事务的状态,就会造成全局事务不一致。

最后,未完成的TCC全局,TCC事务框架必须重新尝试提交/回滚操作。重试时会再次调用各TCC服务的Confirm/Cancel业务操作。

如果某个服务的Confirm/Cancel业务之前已经生效(其参与的RM本地事务已经提交),重试时就不应该再次被调用。否则,其Confirm/Cancel业务被多次调用,就会有“服务幂等性”的问题。

2.2.  拦截TCC服务的Try/Confirm/Cancel业务方法的执行,根据其异常信息可否知道其RM本地事务是否commit/rollback了呢?

基本上很难做到,为什么这么说?

第一,事务是可以在多个(本地/远程)服务之间互相传播其事务上下文的,一个业务方法(Try/Confirm/Cancel)执行完毕并不一定会触发当前事务的commit/rollback操作。

比如,被传播事务上下文的业务方法,在它开始执行时,容器并不会为其创建新的事务,而是它的调用方参与的事务,使得二者操作在同一个事务中;同样,在它执行完毕时,容器也不会提交/回滚它参与的事务的。

因此,这类业务方法上的异常情况并不能反映他们是否生效。不接管Spring的TransactionManager,就无法了解事务于何时被创建,也无法了解它于何时被提交/回滚。

第二、一个业务方法可能会包含多个RM本地事务的情况。

比如:A(REQUIRED)->B(REQUIRES_NEW)->C(REQUIRED),这种情况下,A服务所参与的RM本地事务被提交时,B服务和C服务参与的RM本地事务则可能会被回滚。

第三、并不是抛出了异常的业务方法,其参与的事务就回滚了。

Spring容器的声明式事务定义了两类异常,其事务完成方向都不一样:系统异常(一般为Unchecked异常,默认事务完成方向是rollback)、应用异常(一般为Checked异常,默认事务完成方向是commit)。

二者的事务完成方向又可以通过@Transactional配置显式的指定,如rollbackFor/noRollbackFor等。

第四、Spring容器还支持使用setRollbackOnly的方式显式的控制事务完成方向;

最后,自行拦截业务方法的拦截器和Spring的事务处理的拦截器还会存在执行先后、拦截范围不同等问题。

例如,如果自行拦截器执行在前,就会出现业务方法虽然已经执行完毕但此时其参与的RM本地事务还没有commit/rollback。

TCC事务框架的定位应该是一个TransactionManager,其职责是负责commit/rollback事务。

而一个事务应该commit、还是rollback,则应该是由Spring容器来决定的:

Spring决定提交事务时,会调用TransactionManager来完成commit操作;Spring决定回滚事务时,会调用TransactionManager来完成rollback操作。

接管Spring容器的TransactionManager,TCC事务框架可以明确的得到Spring的事务性指令,并管理Spring容器中各服务的RM本地事务。

否则,如果通过自行拦截的机制,则使得业务系统存在TCC事务处理、RM本地事务处理两套事务处理逻辑,二者互不通信,各行其是。

这种情况下要协调TCC全局事务,基本上可以说是缘木求鱼,本地事务尚且无法管理,更何谈管理分布式事务?

三、TCC事务框架应该具备故障恢复机制

一个TCC事务框架,若是没有故障恢复的保障,是不成其为分布式事务框架的。

分布式事务管理框架的职责,不是做出全局事务提交/回滚的指令,而是管理全局事务提交/回滚的过程。

它需要能够协调多个RM资源、多个节点的分支事务,保证它们按全局事务的完成方向各自完成自己的分支事务。

这一点,是不容易做到的。因为,实际应用中,会有各种故障出现,很多都会造成事务的中断,从而使得统一提交/回滚全局事务的目标不能达到,甚至出现”一部分分支事务已经提交,而另一部分分支事务则已回滚”的情况。

比较常见的故障,比如:业务系统服务器宕机、重启;数据库服务器宕机、重启;网络故障;断电等。这些故障可能单独发生,也可能会同时发生。

作为分布式事务框架,应该具备相应的故障恢复机制,无视这些故障的影响是不负责任的做法。

一个完整的分布式事务框架,应该保障即使在最严苛的条件下也能保证全局事务的一致性,而不是只能在最理想的环境下才能提供这种保障。退一步说,如果能有所谓“理想的环境”,那也无需使用分布式事务了。

TCC事务框架要支持故障恢复,就必须记录相应的事务日志。事务日志是故障恢复的基础和前提,它记录了事务的各项数据。

TCC事务框架做故障恢复时,可以根据事务日志的数据将中断的事务恢复至正确的状态,并在此基础上继续执行先前未完成的提交/回滚操作。关注微信公众号:Java技术栈,在后台回复:架构,可以获取我整理的  N 篇架构教程,都是干货。

四、TCC事务框架应该提供Confirm/Cancel服务的幂等性保障

一般认为,服务的幂等性,是指针对同一个服务的多次(n>1)请求和对它的单次(n=1)请求,二者具有相同的副作用。

在TCC事务模型中,Confirm/Cancel业务可能会被重复调用,其原因很多。

比如,全局事务在提交/回滚时会调用各TCC服务的Confirm/Cancel业务逻辑。执行这些Confirm/Cancel业务时,可能会出现如网络中断的故障而使得全局事务不能完成。

因此,故障恢复机制后续仍然会重新提交/回滚这些未完成的全局事务,这样就会再次调用参与该全局事务的各TCC服务的Confirm/Cancel业务逻辑。

既然Confirm/Cancel业务可能会被多次调用,就需要保障其幂等性。

那么,应该由TCC事务框架来提供幂等性保障?还是应该由业务系统自行来保障幂等性呢?

个人认为,应该是由TCC事务框架来提供幂等性保障。如果仅仅只是极个别服务存在这个问题的话,那么由业务系统来负责也是可以的;

然而,这是一类公共问题,毫无疑问,所有TCC服务的Confirm/Cancel业务存在幂等性问题。TCC服务的公共问题应该由TCC事务框架来解决;

而且,考虑一下由业务系统来负责幂等性需要考虑的问题,就会发现,这无疑增大了业务系统的复杂度。

五、TCC事务框架不能盲目的依赖Cancel业务来回滚事务

前文以及提到过,TCC事务通过Cancel业务来对Try业务进行回撤的机制暗含了一个事实:Try操作已经生效。

也就是说,只有Try操作所参与的RM本地事务已经提交的情况下,才需要执行其Cancel操作进行回撤。没有执行、或者执行了但是其RM本地事务被rollback的Try业务,是一定不能执行其Cancel业务进行回撤的。

因此,TCC事务框架在全局事务回滚时,应该根据TCC服务的Try业务的执行情况选择合适的处理机制。而不能盲目的执行Cancel业务,否则就会导致数据不一致。

一个TCC服务的Try操作是否生效,这是TCC事务框架应该知道的,因为其Try业务所参与的RM事务也是由TCC事务框架所commit/rollbac的(前提是TCC事务框架接管了Spring的事务管理器)。推荐:分布式事务不理解?一次给你讲清楚。

所以,TCC事务回滚时,TCC事务框架可考虑如下处理策略:

  1. 鸿蒙官方战略合作共建——HarmonyOS技术社区

  2. 如果TCC事务框架发现某个服务的Try操作的本地事务尚未提交,应该直接将其回滚,而后就不必再执行该服务的cancel业务;

  3. 如果TCC事务框架发现某个服务的Try操作的本地事务已经回滚,则不必再执行该服务的cancel业务;

  4. 如果TCC事务框架发现某个服务的Try操作尚未被执行过,那么,也不必再执行该服务的cancel业务。

总之,TCC事务框架应该保障:

  1. 鸿蒙官方战略合作共建——HarmonyOS技术社区

  2. 已生效的Try操作应该被其Cancel操作所回撤;

  3. 尚未生效的Try操作,则不应该执行其Cancel操作。这一点,不是幂等性所能解决的问题。如上文所述,幂等性是指服务被执行一次和被执行n(n>0)次所产生的影响相同。但是,未被执行和被执行过,二者效果肯定是不一样的,这不属于幂等性的范畴。

六、Cancel业务与Try业务并行,甚至先于Try操作完成

这应该算TCC事务机制特有的一个不可思议的陷阱。

一般来说,一个特定的TCC服务,其Try操作的执行,是应该在其Confirm/Cancel操作之前的。

Try操作执行完毕之后,Spring容器再根据Try操作的执行情况,指示TCC事务框架提交/回滚全局事务。然后,TCC事务框架再去逐个调用各TCC服务的Confirm/Cancel操作。

然而,超时、网络故障、服务器的重启等故障的存在,使得这个顺序会被打乱。比如:

基于TCC如何实现一个通用的分布式事务框架

上图中,假设[B:Try]操作执行过程中,网络闪断,[A:Try]会收到一个rpc远程调用异常。

A不处理该异常,导致全局事务决定回滚,TCC事务框架就会去调用[B:Cancel],而此刻A、B之间网络刚好已经恢复。如果[B:Try]操作耗时较长(网络阻塞/数据库操作阻塞),就会出现[B:Try]和[B:Cancel]二者并行处理的现象,甚至[B:Cancel]先完成的现象。

这种情况下,由于[B:Cancel]执行时,[B:Try]尚未生效(其RM本地事务尚未提交),因此,[B:Cancel]是不能执行的,至少是不能生效(执行了其RM本地事务也要rollback)的。

然而,当[B:Cancel]处理完毕(跳过执行、或者执行后rollback其RM本地事务)后,[B:Try]操作完成又生效了(其RM本地事务成功提交),这就会使得[B:Cancel]虽然提供了,但却没有起到回撤[B:Try]的作用,导致数据的不一致。

所以,TCC框架在这种情况下,需要:

  1. 鸿蒙官方战略合作共建——HarmonyOS技术社区

  2. 将[B:Try]的本地事务标注为rollbackOnly,阻止其后续生效;

  3. 禁止其再次将事务上下文传递给其他远程分支,否则该问题将在其他分支上出现;

  4. 相应地,[B:Cancel]也不必执行,至少不能生效。

当然,TCC事务框架也可以简单的选择阻塞[B:Cancel]的处理,待[B:Try]执行完毕后,再根据它的执行情况判断是否需要执行[B:Cancel]。

不过,这种处理方式因为需要等待,所以,处理效率上会有所不及。

同样的情况也会出现在confirm业务上,只不过,发生在Confirm业务上的处理逻辑与发生在Cancel业务上的处理逻辑会不一样。

TCC框架必须保证:

  1. 鸿蒙官方战略合作共建——HarmonyOS技术社区

  2. Confirm业务在Try业务之后执行,若发现并行,则只能阻塞相应的Confirm业务操作;

  3. 在进入Confirm执行阶段之后,也不可以再提交同一全局事务内的新的Try操作的RM本地事务。

七、TCC服务复用性是不是相对较差?

TCC事务机制的定义,决定了一个服务需要提供三个业务实现:Try业务、Confirm业务、Cancel业务。

可能会有人因此认为TCC服务的复用性较差。怎么说呢,要是将 Try/Confirm/Cancel业务逻辑单独拿出来复用,其复用性当然是不好的。

Try/Confirm/Cancel  逻辑作为TCC型服务中的一部分,是不能单独作为一个组件来复用的。Try、Confirm、Cancel业务共同才构成一个组件,如果要复用,应该是复用整个TCC服务组件,而不是单独的Try/Confirm/Cancel业务。

八、TCC服务是否需要对外暴露三个服务接口?

不需要。TCC服务与普通的服务一样,只需要暴露一个接口,也就是它的Try业务。

Confirm/Cancel业务逻辑,只是因为全局事务提交/回滚的需要才提供的,因此Confirm/Cancel业务只需要被TCC事务框架发现即可,不需要被调用它的其他业务服务所感知。

换句话说,业务系统的其他服务在需要调用TCC服务时,根本不需要知道它是否为TCC型服务。

因为,TCC服务能被其他业务服务调用的也仅仅是其Try业务,Confirm/Cancel业务是不能被其他业务服务直接调用的。

九、TCC服务A的Confirm/Cancel业务中能否调用它依赖的TCC服务B的Confirm/Cancel业务?

最好不要这样做。

首先,没有必要。TCC服务A依赖TCC服务B,那么[A:Try]已经将事务上下文传播给[B:Try]了,后续由TCC事务框架来调用各自的Confirm/Cancel业务即可;

其次,Confirm/Cancel业务如果被允许调用其他服务,那么它就有可能再次发起新的TCC全局事务。如此递归下去,将会导致全局事务关系混乱且不可控。

TCC全局事务,应该尽量在Try操作阶段传播事务上下文。Confirm/Cancel操作阶段仅需要完成各自Try业务操作的确认操作/补偿操作即可,不适合再做远程调用,更不能再对外传播事务上下文。

关于基于TCC如何实现一个通用的分布式事务框架就分享到这里了,希望以上内容可以对大家有一定的帮助,可以学到更多知识。如果觉得文章不错,可以把它分享出去让更多的人看到。

--结束END--

本文标题: 基于TCC如何实现一个通用的分布式事务框架

本文链接: https://www.lsjlt.com/news/284346.html(转载时请注明来源链接)

有问题或投稿请发送至: 邮箱/279061341@qq.com    QQ/279061341

本篇文章演示代码以及资料文档资料下载

下载Word文档到电脑,方便收藏和打印~

下载Word文档
猜你喜欢
  • 基于TCC如何实现一个通用的分布式事务框架
    这篇文章给大家介绍基于TCC如何实现一个通用的分布式事务框架,内容非常详细,感兴趣的小伙伴们可以参考借鉴,希望对大家能有所帮助。一个TCC事务框架需要解决的当然是分布式事务的管理。TCC事务模型虽然说起来简单,然而要基于TCC实现一个通用的...
    99+
    2023-06-16
  • 用python完成一个分布式事务TCC
    前言: 什么是分布式事务?银行跨行转账业务是一个典型分布式事务场景,假设A需要跨行转账给B,那么就涉及两个银行的数据,无法通过一个数据库的本地事务保证转账的ACID,只能够通过分布式...
    99+
    2024-04-02
  • Java中TCC分布式事务的实现原理
    这篇文章给大家分享的是有关Java中TCC分布式事务的实现原理的内容。小编觉得挺实用的,因此分享给大家做个参考,一起跟随小编过来看看吧。Java的特点有哪些Java的特点有哪些1.Java语言作为静态面向对象编程语言的代表,实现了面向对象理...
    99+
    2023-06-14
  • 基于 XA 事务协议,用代码实现一个二阶段分布式事务
    在具体的 Demo 之前,先来补充一点 XA 事务的知识:DTP 模型与 XA 规范。DTP 模型与 XA 规范是由 X/Open 维护,也就是现在的 open group,官方网址:http://www.opengroup.org/。op...
    99+
    2023-06-02
  • Laravel基于reset怎么实现分布式事务
    这篇文章主要讲解了“Laravel基于reset怎么实现分布式事务”,文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着小编的思路慢慢深入,一起来研究和学习“Laravel基于reset怎么实现分布式事务”吧!    ...
    99+
    2023-06-25
  • 基于dubbo的分布式架构怎么实现
    本篇内容介绍了“基于dubbo的分布式架构怎么实现”的有关知识,在实际案例的操作过程中,不少人都会遇到这样的困境,接下来就让小编带领大家学习一下如何处理这些情况吧!希望大家仔细阅读,能够学有所成!前言现在越来越多的互联网公司还是将自己公司的...
    99+
    2023-06-05
  • 如何通过 ASP 框架和 Django 实现高效的分布式应用?
    在当今的互联网时代,越来越多的应用程序需要支持分布式部署,以保证高可用性和可扩展性。为了实现这种需求,开发人员需要采用一些现代的框架和技术。在本文中,我们将介绍如何通过 ASP框架和 Django实现高效的分布式应用。 ASP框架和Djan...
    99+
    2023-07-08
    框架 django 分布式
  • Redis如何实现分布式事务的一致性
    Redis是一个高性能、分布式内存数据库,被广泛应用在分布式系统中。在分布式系统中,如何实现事务的一致性一直是一个难题,而Redis提供的事务机制可以帮助开发者解决这个问题。本文将介绍Redis如何实现分布式事务的一致性,并展示代码示例。一...
    99+
    2023-11-07
    redis 分布式事务 一致性
  • 如何进行分布式事务框架GTS全解析
    今天就跟大家聊聊有关如何进行分布式事务框架GTS全解析,可能很多人都不太了解,为了让大家更加了解,小编给大家总结了以下内容,希望大家根据这篇文章可以有所收获。全局事务服务(Global Transaction Service,简称 GTS)...
    99+
    2023-06-04
  • 如何用C#实现SAGA分布式事务
    目录背景成功的 SAGA异常的 SAGA子事务屏障写在最后背景 银行跨行转账业务是一个典型分布式事务场景,假设 A 需要跨行转账给 B,那么就涉及两个银行的数据,无法通过一个数据库的...
    99+
    2022-11-13
    Saga分布式事务 C#实现SAGA分布式事务
  • 如何分析基于redis分布式锁实现秒杀
    本篇文章为大家展示了如何分析基于redis分布式锁实现秒杀,内容简明扼要并且容易理解,绝对能使你眼前一亮,通过这篇文章的详细介绍希望你能有所收获。业务场景所谓秒杀,从业务角度看,是短时间内多个用户“争抢”资源,这里的资源在大部分秒杀场景里是...
    99+
    2023-06-02
  • 如何使用HTML和CSS实现一个响应式导航框架布局
    导航栏是网页中非常重要的一部分,它可以帮助用户快速导航到网站的各个页面。为了适应不同设备的屏幕尺寸,我们需要使用HTML和CSS来创建一个响应式的导航框架布局。下面我将详细介绍如何实现这一目标,并提供相应的代码示例。HTML结构首先,我们需...
    99+
    2023-10-21
    响应式 CSS html
  • 如何实现J2EE分布式系统框架设计
    今天就跟大家聊聊有关如何实现J2EE分布式系统框架设计,可能很多人都不太了解,为了让大家更加了解,小编给大家总结了以下内容,希望大家根据这篇文章可以有所收获。一,导言框架设计(Framework Design)是系统设计的重要组成部分,一个...
    99+
    2023-06-03
  • 一文搞懂MySQL XA如何实现分布式事务
    目录前言XA 协议如何通过MySQL XA实现分布式事务前言 MySQL支持单机事务的良好表现毋庸置疑,那么在分布式系统中,涉及多个节点,MySQL又是如何实现分布式事务的呢?比如开...
    99+
    2024-04-02
  • 如何通过AmazonAurora实现数据库的分布式事务处理
    Amazon Aurora是一个关系型数据库服务,其支持分布式事务处理。要通过Amazon Aurora实现数据库的分布式事务处理,...
    99+
    2024-04-09
    AmazonAurora
  • Spring Boot + RabbitMQ如何实现分布式事务
    小编给大家分享一下Spring Boot + RabbitMQ如何实现分布式事务,希望大家阅读完这篇文章之后都有所收获,下面让我们一起去探讨吧!一:分布式事务解决方案1.两阶段提交(2PC)第一阶段:事务协调器要求每个涉及到事务的数据库预提...
    99+
    2023-06-03
  • 如何在Redis中实现分布式事务
    在Redis中实现分布式事务可以通过使用 Redis 的事务机制 MULTI/EXEC 和 WATCH 命令来实现。以下是实现分布式...
    99+
    2024-04-09
    Redis
  • 基于redis分布式锁如何实现秒杀功能
    这篇文章主要介绍了基于redis分布式锁如何实现秒杀功能,具有一定借鉴价值,感兴趣的朋友可以参考下,希望大家阅读完这篇文章之后大有收获,下面让小编带着大家一起了解一下。业务场景所谓秒杀,从业务角度看,是短时...
    99+
    2024-04-02
  • 如何利用Redis实现分布式事务管理
    如何利用Redis实现分布式事务管理引言:随着互联网的快速发展,分布式系统的使用越来越广泛。在分布式系统中,事务管理是一项重要的挑战。传统的事务管理方式在分布式系统中难以实现,并且效率低下。而利用Redis的特性,我们可以轻松地实现分布式事...
    99+
    2023-11-07
    管理 redis 分布式事务
  • .NET Core分布式链路追踪框架的基本实现原理
    目录分布式追踪什么是分布式追踪分布式系统分布式追踪分布式追踪有什么用呢Dapper分布式追踪系统的实现跟踪树和 spanJaeger 和 OpenTracingOpenTracing...
    99+
    2024-04-02
软考高级职称资格查询
编程网,编程工程师的家园,是目前国内优秀的开源技术社区之一,形成了由开源软件库、代码分享、资讯、协作翻译、讨论区和博客等几大频道内容,为IT开发者提供了一个发现、使用、并交流开源技术的平台。
  • 官方手机版

  • 微信公众号

  • 商务合作