分析数据库事务循环依赖的影响与解决方法 (数据库事务循环依赖)
在数据库中，事务是一组必须被一起执行的数据库操作。它们被视为一个单一的工作单元，要么全部成功，要么全部失败。事务循环依赖是指两个或多个事务互相依赖，并且被设计成必须在相互之间执行。当存在事务循环依赖时，会出现难以解决的问题，影响数据库的性能和稳定性。本文将分析数据库事务循环依赖的影响以及解决方法。
1. 事务循环依赖的影响
1.1 数据库性能受到影响
事务循环依赖可能导致数据的更新和读取之间的冲突，导致数据库性能下降。循环依赖会阻止事务完成并释放数据库锁，这可能导致其他事务在等待时间内堵塞。
1.2 数据库安全性受到威胁
事务循环依赖可能导致数据丢失和数据不完整的风险。由于互相依赖的事务的顺序无法保证，如果一个事务的失败导致系统中的其他事务一起失败，数据就会处于不一致的状态。
1.3 可维护性变差
事务循环依赖要求开发人员具有更高的技能，难以预测故障和维护代码。当软件代码中包含循环依赖关系时，团队在修复一个错误时可能会意外地影响到其他模块的功能，所以在日常维护中是难以实现的。
2. 解决数据库事务循环依赖的方法
2.1 分析依赖关系
在事务中如果存在循环依赖关系，必须首先找到每个循环并确定在哪个事务中出现问题。通过仔细调查依赖关系，可以找到数据库变化的原因，从而将这些问题逐一解决。
2.2 优化事务流程
优化事务流程是避免事务循环依赖的更好方法之一。事务流程可以通过优化数据查询，避免重复查询或在单个事务中完成多个查询等方式进行优化。这将大大减少循环依赖的危险性。
2.3 采用分布式事务处理
分布式事务处理是一种以分散数据库事务负载为中心的解决方案。它包含一个处理请求的主服务器及数个工作服务器，将数据分片分散到不同的服务器上，分散事务负载。这种方案能够有效减轻事务循环依赖时可能出现的锁等因素，但是也增加了管理的复杂性，需要考虑跨服务器的通讯等问题。
2.4 数据库重构
重构是一种在不影响现有功能的情况下从根本上修改应用程序的方式。这种方法可以解决一个系统中设计不合理的问题。当应用程序中存在循环依赖时，数据库重构是解决方法之一。重构可能涉及调整数据模型，修改表结构等等方面，需要谨慎考虑。
3.
事务循环依赖的问题可能严重影响数据库的性能和稳定性，并引起数据丢失等情况。本文提供了一些解决方案，包括分析依赖关系，优化事务流程，采用分布式处理事务等。重构是解决问题的最后手段，但需要谨慎考虑。因此，在数据库设计和开发时应该务必避免循环依赖的问题。
相关问题拓展阅读：
一篇让你学会 11个Spring 失效场景
其实关于spring事务失效的场景，网络上文章介绍的不少，参差不齐。这里只分享下自己的见解，时长大概10分钟左右，先上个图介绍下。
事务方法需要定义public，非public方法事务会失效。事务拦截器TransactionalInterceptor会在执行方法前进行拦截，通过动态代理方式如果是cglib就是intercept方法或者jdk的invoke方法间接调用AbstractFallbackTransactionAttributeSource类的getTransactionAttribute方法获取配置信息，附上源码图：
进一步的跟踪getTransactionAttribute方法，我们就能看到，spring对于非public修饰的方式，返回的事务对象是null，其中allowPublicMethodsOnly返回的是一个布尔false。
事务底层使用了aop,那么也就是说通过jdk或者是cglib生成代理类，在代理类中实现的事务的功能，如果说方法是final修饰的了，那么就会导致代理类中无法重写该方法，从而导致添加事务失败。同样的如果是static的修饰的话也是无法通过动态代理变成事务方法。
简单来说就是一个方法内部调用另一个方法，但是另一个方式是有事务的，这样也会导致事务失效，因为这个调用的是this对象的方法，而不是另一个方法持有的对象，可以这里理解。
如果想要在枯禅方法内部调用另一个方法也有事务的话，就需要新建一个service对象持有。
这样，通过新建一个service方法，将事务添加到新建的service方法里就可以了。说到这里可能小伙伴觉得这样有点麻烦，那么是否有没有其他的方式不新建一个方法呢，答案是可以的，就是注入自己，利用了spring ioc内部的三级缓存的机制，这里注入自己就很好的保证了也不会出现循环依赖：
其实到了这一步，还是发现有点不太雅观，并不是说上面代码有什么问题只是觉得，可以让上面代码更加好看一点，那么有没有呢，答案是有的，是什么呢?这就不得不佩服spring强大完善的支持，那就是AopContext.currentProxy(),这个就是创建代理类，在方法调·调用前后切入，这个代理类对象是保存在ThreadLocal中的，所以通过这个代理类对象调用事务方法就能生效了。
这样看来，代码是不是就优雅多了，哈哈!!!
这里需要明确一个前提，就是使用spring事务的前提，就是对象要被spring管理握启就需要创建bean实例，在开发中，我们都是通过@Controller,@Service,@Component,@Repository等注解自动的实现依赖注入实例化的功能，但假如说在相应的控制层，业务层，数据层忘记加相应的注解，那么也是会失效的。因为没有交给spring管理，例如：
回没皮尘想起前几年配置事务管理器时，都会有这样的一段配置：
通过这一段配置也可以知道，其实spring事务就是通过数据库连接事务多线程连接会导致持有的connetion不是同一个，从网上找了一张图，通过这张图进一步理解：
接着附上伪代码结合上面的图进一步理解：
事务add方法中调用了另一个事务doOtherThing,但是事务方法是在另一个线程中调用的，这样就会导致两个方法不在同一个线程中，获取到的数据库链接不一样，是两个不同的事务，一旦doOtherThing发生异常，add方法也是不可能发生回滚的.这里需要解释以下什么是同一个事务，也就是说只有拥有同一个数据库连接才能同时提交和回滚。如果在不同的线程，拿到的数据库连接肯定是不一样的，所以是不同的事务。
这个就没什么好讲的了，也就是innodb和myisam引擎的不同，5版本以前默认是myisam引擎，这个引擎是不支持事务的，5版本以后的innodb是支持事务的。
这个其实可能也是比较容易忽略的，因为我们印象里好像没怎么配置过怎么开启事务，也确实是这样哈，为什么?其实原因很简单，springboot项目通过DataSourceTransactionManagerAutoConfiguration这个类已经默默的为我们开启了事务。
这个类会加载spring.datasource这个配置文件从而启动事务，如果是非springboot项目就需要自己手动在xml文件中配置事务管理器。
类似这样的从而开启事务。
在使用@Transactional注解时，是可以指定propagation参数的，该参数是用来指定事务的传播特性，其中只有required,requires_new,nested这三种才会创建新事务：
像上面的Propagation.NEVER这种类型的传播特性不支持事务，如果有事务则会抛异常。
像这种手动try…catch了异常，又没有手动抛出，那么sring就会认为程序是异常的就不会回滚了。
捕获了异常又抛出了exception异常，事务同样不会回滚，因为spring事务默认情况下只会回滚RuntimeException(运行时异常)和Error(错误)，对于普通的Exception(非运行时异常)，不会回滚，网上找了一张图：
这里exception里除了分为运行时异常和非运行时异常(ioException)。
1） 让checked例外也回滚：
在整个方法前加上 @Transactional(rollbackFor=Exception.class)
2） 让unchecked例外不回滚：
@Transactional(notRollbackFor=RunTimeException.class)
3）不需要事务管理的(只查询的)方法：@Transactional(propagation=Propagation.NOT_SUPPORTED)
这里需要提及的一句是，如果是自定义了的异常，比如说我自定义了DALException异常，那么就应该是@Transactional(notRollbackFor=DALException.class)，一旦抛出的异常不属于DALException异常，那么事务也是不会生效的。
其实这个就有点像是js里的冒泡事件，可能我只是需要底部，结果外层窗口事件也触发了，联想到事务这里，那么也是一样的，嵌套多个可能只是想回滚对应的事务，就不用把其他事务也回滚了，这个可以通过try…catch来处理，将需要处理回滚的事务放这里面就不会把外层的也会滚了。
如何运用物理识图，逻辑识图进行软件架构设计
软件架构设计的目的
对于外包业务类型的项目，软件架构设计的目的与产品类型的项目有所不同，在这里主要讨论外包类型项目的软件架构设计目的。
1、为大规模开发提供基础和规范，并提供可重用的资产，软件系统的大规模开发，必须要有一定的基础和遵循一定的规范，这既是软件工程本身的要求，也是客户的要求。架构设计的过程中可以将一些公共部分抽象提取出来，形成公共类和工具类，以达到重用的目的。
2、一定程度上缩短项目的周期，利用软件架构提供的框架或重用组件，缩短项目开发的周期。
3、降低开发和维护的成本，大量的重用和抽象，可以提取出一些开发人员不用关心的公共部分，这样便可以使开发人员仅仅关注于业务逻辑的实现，从而减少了很多工作量，提高了开发效率。
4、提高产品的质量，好的软件架构设计是产品质量的保证，特别是对于客户常常提出的非功能性需求的满足。
软件架构设计的原则
软件架构设计必须遵循以下原则：
1、满足功能性需求和非功能需求。这是一个喊做软件系统最基本的要求，也是架构设计时应该遵循的最基本的原则。念汪
2、实用性原则，就像每一个软件系统交付给用户使用时必须实用，能解决用户的问题一样，架构设计也必须实用，否则就会“高来高去”或“过度设计”。
3、满足复用的要求，更大程度的提高开发人员的工作效率。
软件架构设计的几种视图
我们常常在讨论架构设计该做些什么的时候，或是在架构设计评审的会议上，会提出各种各样的问题，例如开发人员该如何记录郑高衡Log，事务如何控制？怎样才能提高我们的开发人员的工作效率，即在单位时间内更有品质的完成更多的功能？怎样满足客户的非功能性需求？怎样让生产环境的平台管理人员更好的维护系统？
上面这些问题，实际上是软件系统的不同的干系人站在不同的角度上提出的问题，要回答上面这些问题，我们就得从不同的视角来看待软件架构设计这项工作。
1、逻辑架构视角，从系统用户的角度考虑问题，设计出来的软件架构能够满足业务逻辑的需求，能够处理现在越来越复杂的业务逻辑需求。
2、开发架构视角，从系统开发人员的角度来考虑问题，设计的架构要易于理解，易于开发，易于单元测试，更好做到让开发人员可以用最少的代码行数完成功能的开发。
3、运行架构视角，从系统运行时的质量需求考虑问题，特别关注于系统的非功能需求，客户常常都会要求我们系统的功能画面的最长响应时间不超过4秒，能满足2023个用户同时在线使用，基于角色的系统资源的安全控制等。
4、物理架构视角，关注系统安装和部署在什么样的环境上，例如现在更流行的企业应用服务解决方案IBM Http Server ＋ WebSphere Application Server ＋ DB2，WebLogic + Oracle等。
5、数据架构视角，如今我们开发的各类系统，如MIS，ERP，SAP，基本上都是对各类数据的操作，把一堆不太好懂的数据展现成用户容易看懂的数据，自动处理各类数据的运算等，所以数据的持久化是十分重要的一件事情。
1、分析需求和理解业务模型（或领域建模），并选定关键Use case。
软件的需求，可以分为从用户视角和开发人员视角来看，从用户的角度看，又可以分为功能性和非功能性需求，我们必须从不同的视角和级别去全面的认识需求并分析需求，理解业务模型。实践表明，常常被我们忽视的非功能性需求常常会导致整个项目失败。
理解业务需求更好的方式莫过于进行领域建模，领域建模与需求分析往往是交替穿叉进行的，领域建模主要有以下三个方面的作用：
◆探索复杂问题，弄清领域知识。Martin Fowler曾经说过，他采用面向对象方法更大的好处就是它有助于解决更为复杂的问题。领域建模本身作为辅助思维的工具，帮助我们将注意力始终保持在最为重要的业务概念及其关系上，使我们能够不断深入地，系统的对需求进行分析和认识。领域建模往往是一个从模糊到清晰，从零散到系统的过程。
◆决定功能范围，影响可扩展性。任何模型都是对现实世界某种程序的抽象，这种抽象就会忽略某一些东西，例如忽略对象的属性和对象间的关系，而这些忽略往往都是带有一定的目的性的，这种忽略就决定了功能的范围。模型揭示了各种功能背后的结构，如果说定义功能相当于“拍照片”的话，那么领域建模就相当于“做透视”，更加关注问题领域的内在结构，相当于对问题领域进行了一定的抽象，良好的领域模型不仅能很好的支持现有的功能，而且还可以在一定程度上支持未来可能出现的新需求，体现良好的可扩展性。
◆提供交流基础，促进有效沟通。领域建模通常会使用UML图作为呈现的方式，这样为我们的沟通提供了方便。当然，有时候文字在描述某些特定领域的问题时可能更适合，可以灵活运用。
在我们公司的实际软件开发流程中，往往领域建模缺少这一环节，这可能是在以后的工作中需要进一步提高之处。
虽然我们总是期望架构设计师能全面掌握需求，但由于时间和精力的限制，摆在我们面前的现实就是架构设计师没有时间对所有需求进行深入分析，所以我们的策略就是“把好钢用在刀刃上”，即把大部分时间和精力花在对决定架构最重要的关键需求上。在选择关键需求时要注意：高优先级的需求往往是从用户的角度来看的，可能并不是真正的关键需求。在《RUP实践者指南》一书中向我们讲述了如何确定关键功能需求？A.作为应用程序的核心或实现了系统的主要接口的功能，B.必须被实现的功能，即如果这些功能不被实现，则开发出来的软件就失去了价值，C.覆盖了系统架构的一些方面，但没有被其他重要的Use case覆盖到的功能。
2、分别从各个视角来考虑软件架构的方方面面。
软件的架构设计必须考虑到各方面，根据前期工作确立的领域模型，关键需求，系统约束等进行设计，必须从系统用户，开发人员，系统管理员，部署管理员，数据管理员等人员的角度去分析并解决问题。比如说，如果我们的运行架构采用Cluster方式时，就必须小心Cache和Session等的使用；如果我们的业务逻辑要求我们要操作多个数据库时，就要考虑采用支持二阶段事务提交的方式。
只有将这些方方面面的问题都考虑到了，这样的架构设计才是完整的。至于每一个视图中，我们应该设计到什么细节这一问题，实际上与整个项目的过程定义有关。例如，如果我们有专门安排数据库概要设计的活动，那我们在架构设计的过程中就可以只需要关注更高层次的数据库特性及数据库之间的关系，而每一张表的数据字典可以在后续的相关活动中进行设计，但如果没有这样的活动，那我们就要细化到每一张表的每一个栏位，以及表之间的关系。
3、解决技术面的重点问题和难题
在软件架构设计的过程中，我们往往会需要攻克一些技术面的重点问题和难题，这完全是一项极其需要扎实的理论知识和丰富的实践经验支撑的工作。例如，我们如何提高整个系统的性能？如何能很好的导出极其复杂的“中国式报表”（一般比西方国家产出的报表要复杂很多，而且很多开源的BI类的框架并不能完全解决问题）？
当遇到确实是很困难的问题，可以去百度一下或Google一下，也可以去请教公司的资深技术人员或专家，或者召开小范围的技术专题讨论会议，采用脑力激荡的方法试着找找答案，这样才能提高工作的效率。
4、召开架构设计评审会议进行同行评审。
架构设计评审是极其重要的一环，我曾将其形容为“七种武器”中的离别钩，就是因为在会议上，同行们可能会提很多问题或意见，而且很多意见很尖锐，所以一定要虚心接受，并做好记录，正所谓“良药苦口利于病，忠言逆耳利于行”。
在评审会议之前，我们要完成很多准备工作，更好是能准备一份简明扼要的电子简报，把最重要的问题列出来，这样在进行评审会议时，就不会漫无目的，在会议前就将这些资料发给与会人员，请他们抽空先了解一下，在会议进行时，要学会控制会议的进度，提高会议的效率。
5、针对关键Use case在设计的架构上实现功能来验证架构。
对于架构设计的验证也是一项十分重要的工作，其验证技术有很多种，在我们公司通常会采用Sample的形式，即XP中所说的迭代0，RUP中所说的切片。这样做的好处是既可以从实际的产品角度出发来有效的验证架构是否满足要求，又可以比抛弃型原型验证技术节省成本。
这个Sample绝不是我们在解决架构设计中的问题时拿来做实验的一些代码的拼凑，而是完整的实现某一关键Use case的符合架构设计和一系列规范的可交付的代码及相关文档。同时，这个Sample可以作为你在给大家讲解或培训架构时的教材，也可以作为开发人员使用此架构进行开发的蓝本，甚至是只需要复制粘贴，加上简单的修改即可。
6、交付给客户Review。
这一环节，在很多公司可能并不存在，因为他们的软件架构并不一定需要客户Review，但像我们这种做服务的公司，最重要的就是客尊，落实到软件架构设计这一活动，就是让客户理解并接受你的架构设计方案，同时，客户也会起到帮你验证架构的作用。通常，我们的架构得到客户的认可后，便可进入大规模的开发。
在交付给客户Review时，通常可能会以会议的形式进行Review，所以我们可以参照评审会议时好的做法来召开会议，在这里就不再冗述。
软件架构设计的常见误区及解决办法
1、架构设计的常常会“高来高去”。所谓高来高去，实际上就是我们的架构设计仅停留在模型阶段，但也绝不是产生之一支样例程式。
2、架构设计时常常会在某些方面过度设计（Over engineering）。为了一些根本不会发生的变化而进行一系列复杂的设计，这样的设计就叫过度设计，往往会带来资源的浪费并且会增加开发的工作量或难度。虽然我们必须考虑到系统的扩展性，可维护性等，但切忌过度设计。有时候或许你并不能判断出哪些设计是过度设计，此时你可以请教你的PM，让他站在整个项目的高度来帮你决策一下。
3、架构（Architecture）不是框架(Framework)，也不是简单的将几种框架或技术的组合，框架本身也是有架构的。框架一般是针对于某一方面或领域的重用性和可扩展性非常好的半成品，我们可以用一句较为经典的话来总结：框架是软件，架构不是软件，框架是一种特殊的软件。我们在工作中通过将许多方面的可重用的工具类，公共类，基础类等抽象出来，即可形成一些可重用的框架。
4、架构设计绝不是新技术展示平台，合适的技术才是对于项目有利的技术，必须考虑到开发人员的能力和维护人员的能力。作为一名架构设计师应该更多的考虑如何平衡业务需求，织织运作（主要指团队中的协作）和技术三者的关系，而不仅仅是去关注那些技术细节。
5、架构设计的成功与否决定着系统品质的好坏，因为架构设计不好而导致交付的系统Bug过多，无法满足客户非功能性需求等问题，从而导致项目取消的案例时有发生。架构设计不是架构设计师一个人的事情，也不是几天就能完成的一项工作，必须是架构设计师付出大量辛勤劳动后的成果，其成败往往与组织、主管、项目经理的支持有着密切的关系。
关于架构设计的一点通用技巧
1、分层（Layer）规则。这里的层是指逻辑上的层次（Layer），并非指物理上的层次（Tier）。目前的绝大多数的企业级应用系统中都分为三层，即表现层，领域层和数据层。在对各层次进行划分时，主要可以从以下几个方面来考虑：A、每一层是一个相对独立的部分，可以作为一个整体，无需对其它层了解；B、将层次间的依赖性降到更低，即降低耦合；C、可以从某种程度上替换掉某一层，而对其它层不会产生过多的影响；D，层次并不能封闭所有的东西，假如用户界面上增加了一个栏位，那么领域层就要增加一个数据域，数据层就要增加一个相应的字段。同时，过多的分层可能会对性能造成一定的影响。
2、包（package）之间不要产生循环依赖。通常包的划分会先按不同的逻辑层来划分，在层的包下面再按功能来划分。避免包间的循环依赖是一个比较通用的规则，这样的规则一定有其存在的价值和道理，之所以这样主要是出于以下原因：A、循环依赖会使分层失去意义；B、循环依赖会带来许多潜在的风险，如可能会产生嵌套事务（nested transaction，JavaEE标准中并不支持这种事务）的现象，我就曾遇到过这样的问题，在一个项目中，事务放在业务逻辑层统一控制，但由于开发人员忽视了架构中这样的原则，在持久层调用了展现层的公用类，形成了回圈的现象，导致了嵌套事务的发生。
3、设计模式的应用。在很多人的观念里，提供设计模式就等同于GOF的设计模式，其实设计模式是个广泛的概念，比如需求模式、领域模式、反模式等都属于设计模式。模式其实是一门工具，是人们对于过去解决某一类问题的经验总结，所以我们可以在设计活动中应用各种设计模式，但是在应用这些模式之前一定要先分析清楚问题，否则就可能出现“牛头不对马嘴”的现象。
成功的项目总有相似之处，失败的项目却各有各的失败之处。好的软件架构设计必定是成功项目的相似之处，我们有什么理由不把软件架构设计做好了？
数据库事务循环依赖的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于数据库事务循环依赖,分析数据库事务循环依赖的影响与解决方法,一篇让你学会 11个Spring 失效场景,如何运用物理识图，逻辑识图进行软件架构设计的信息别忘了在本站进行查找喔。
