事务锁与并发问题是什么关系

事务锁是为了应对并发问题的一种解决机制，在事务获取数据块当前状态的依赖关系（如通过读取或修改数据）之前，它必须保护自己不受其他事务对同一数据进行修改的影响，事务通过请求锁定数据块来达到此目的。

1锁模式如果某个事务已获得特定数据的锁，则其他事务不能获得与该锁模式发生冲突的锁。如果事务请求的锁模式与已授予同一数据的锁发生冲突，则数据库引擎实例将暂停事务请求直到第一个锁被释放。锁有多种模式，包括共享锁、更新锁、排他锁等。

（1)共享锁（S锁）共享锁允许并发事务在封闭式并发事务下读取资源。有关详细信息，请参阅“213并发事务”的类型。资源上存在共享锁时，任何其他事务都不能修改数据。读取 *** 作一完成，就立即释放资源上的共享锁，除非将事务隔离级别设置为可重复读或更高级别，或者在事务持续时间内用锁定提示保留共享锁。

2）更新锁（U锁）更新锁是共享锁和排他锁的混合型锁，更新锁意味着在做一个更新时，一个共享锁在扫描完成符合条件的数据后可能会转化成排他锁。这里面有两个步骤：（（1)扫描获取Where条件时，这部分是一个更新查询，此时是一个更新锁。

（2）如果将执行写入更新，此时该锁升级到排他锁；否则，该锁转变成共享锁。

3）排他锁（X锁）排他锁可以防止并发事务对资源进行访问，不与其他任何锁兼容。使用排他锁时，任何其他事务都无法修改数据；仅在未提交读隔离级别时才会被其他事务读取占有的数据资源。

2死锁死锁是指两个或两个以上的进程在执行过程中，由于竞争资源或者彼此通信而造成的一种阻塞的现象，若无外力作用，它们将无法推进下去，此时称系统处于死锁状态或系统产生了死锁。这些永远在互相等待的进程称为死锁进程。下面从死锁产生的原因、条件及预防措施等方面来研究事务的死锁。

（1)死锁产生的原因当两个或多个进程各自具有某个资源的锁定，但其他进程尝试要锁定此资源，而造成进程永久封锁彼此时，会发生死锁。例如，事务A取得数据列1的排他锁定，事务B取得数据列2的排他锁定，事务A现在要求取得数据列2的独占锁定，事务B现在要求取得数据列1的独占锁定。事务A与事务B均需要独占数据列1与数据列2的资源，但两个资源分别被两个事务各占一个，互相等待对方的占据的资源才能完成本身的事务，就会造成事务间进程的死锁。

2）死锁产生的条件虽然进程在运行过程中可能发生死锁，但死锁的发生也必须具备一定的条件。死锁的发生必须具备以下四个必要条件。

（（1)互斥条件。互斥条件指进程对所分配到的资源进行排他性使用，即在一段时间内某资源只由一个进程占用。如果此时还有其他进程请求资源，则请求者只能等待，直至占有资源的进程用完释放。

（2）请求和保持条件。请求和保持条件指进程已经保持至少一个资源，但又提出了新的资源请求，而该资源已被其他进程占有，此时请求进程阻塞，但又对自己已获得的其他资源保持不放。

（3）不剥夺条件。不剥夺条件指进程已获得的资源在未使用完之前不能被剥夺，只能在使用完时由自己释放。

（4）环路等待条件。环路等待条件指在发生死锁时，必然存在一个进程——资源的环形链，即进程集合{P0，P1，P2，…，Pn}中的P0正在等待一个P1占用的资源；P1正在等待P2占用的资源；…；Pn正在等待已被P0占用的资源。死锁的预防措施理解了死锁的原因，尤其是产生死锁的四个必要条件，就可以最大可能地避免、预防和解除死锁。只要打破四个必要条件之一就能有效预防死锁的发生。

（（1)打破互斥条件。改造独占性资源为虚拟资源，但大部分资源已无法改造。

（2）打破不可抢占条件。当一进程占有一独占性资源后又去申请另一独占性资源而无法满足时，则退出原占有的资源。

（3）打破占有且申请条件。采用资源预先分配策略，即进程运行前申请全部资源，满足则运行，不满足就等待，这样就不会出现占有部分资源后再去申请其他资源的场景。

（4）打破循环等待条件。实现资源有序分配策略，对所有设备实现分类编号，所有进程只能采用按序号递增的形式申请资源。

所以，在系统设计、进程调度等方面要注意如何不让这四个必要条件成立，如何确定资源的合理分配算法，避免进程永久占据系统资源。此外，也要防止进程在处于等待状态的情况下占用资源，在系统运行过程中，对进程发出的每一个系统能够满足的资源申请进行动态检查，并根据检查结果决定是否分配资源，若分配后系统可能发生死锁，则不予分配；否则予以分配。因此，对资源的分配要给予合理的规划。

数据库是共享资源，通常有许多个事务同时在运行。

当多个事务并发地存取数据库时就会产生同时读取和/或修改同一数据的情况。若对并发 *** 作不加控制就可能会存取和存储不正确的数据，破坏数据库的一致性。

所以数据库管理系统必须提供并发控制机制。

1、什么是分布式事务

分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。以上是百度百科的解释，简单的说，就是一次大的 *** 作由不同的小 *** 作组成，这些小的 *** 作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小 *** 作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。

2、分布式事务的产生的原因

21、数据库分库分表

当数据库单表一年产生的数据超过1000W，那么就要考虑分库分表，具体分库分表的原理在此不做解释，以后有空详细说，简单的说就是原来的一个数据库变成了多个数据库。这时候，如果一个 *** 作既访问01库，又访问02库，而且要保证数据的一致性，那么就要用到分布式事务。

22、应用SOA化

所谓的SOA化，就是业务的服务化。比如原来单机支撑了整个电商网站，现在对整个网站进行拆解，分离出了订单中心、用户中心、库存中心。对于订单中心，有专门的数据库存储订单信息，用户中心也有专门的数据库存储用户信息，库存中心也会有专门的数据库存储库存信息。这时候如果要同时对订单和库存进行 *** 作，那么就会涉及到订单数据库和库存数据库，为了保证数据一致性，就需要用到分布式事务。

以上两种情况表象不同，但是本质相同，都是因为要 *** 作的数据库变多了！

3、事务的ACID特性

31、原子性（A）

所谓的原子性就是说，在整个事务中的所有 *** 作，要么全部完成，要么全部不做，没有中间状态。对于事务在执行中发生错误，所有的 *** 作都会被回滚，整个事务就像从没被执行过一样。

32、一致性（C）

事务的执行必须保证系统的一致性，就拿转账为例，A有500元，B有300元，如果在一个事务里A成功转给B50元，那么不管并发多少，不管发生什么，只要事务执行成功了，那么最后A账户一定是450元，B账户一定是350元。

33、隔离性（I）

所谓的隔离性就是说，事务与事务之间不会互相影响，一个事务的中间状态不会被其他事务感知。

34、持久性（D）

所谓的持久性，就是说一单事务完成了，那么事务对数据所做的变更就完全保存在了数据库中，即使发生停电，系统宕机也是如此。

4、分布式事务的应用场景

41、支付

最经典的场景就是支付了，一笔支付，是对买家账户进行扣款，同时对卖家账户进行加钱，这些 *** 作必须在一个事务里执行，要么全部成功，要么全部失败。而对于买家账户属于买家中心，对应的是买家数据库，而卖家账户属于卖家中心，对应的是卖家数据库，对不同数据库的 *** 作必然需要引入分布式事务。

42、在线下单

买家在电商平台下单，往往会涉及到两个动作，一个是扣库存，第二个是更新订单状态，库存和订单一般属于不同的数据库，需要使用分布式事务保证数据一致性。

5、常见的分布式事务解决方案

51、基于XA协议的两阶段提交

XA是一个分布式事务协议，由Tuxedo提出。XA中大致分为两部分：事务管理器和本地资源管理器。其中本地资源管理器往往由数据库实现，比如Oracle、DB2这些商业数据库都实现了XA接口，而事务管理器作为全局的调度者，负责各个本地资源的提交和回滚。XA实现分布式事务的原理如下：

总的来说，XA协议比较简单，而且一旦商业数据库实现了XA协议，使用分布式事务的成本也比较低。但是，XA也有致命的缺点，那就是性能不理想，特别是在交易下单链路，往往并发量很高，XA无法满足高并发场景。XA目前在商业数据库支持的比较理想，在mysql数据库中支持的不太理想，mysql的XA实现，没有记录prepare阶段日志，主备切换回导致主库与备库数据不一致。许多nosql也没有支持XA，这让XA的应用场景变得非常狭隘。

52、消息事务+最终一致性

所谓的消息事务就是基于消息中间件的两阶段提交，本质上是对消息中间件的一种特殊利用，它是将本地事务和发消息放在了一个分布式事务里，保证要么本地 *** 作成功成功并且对外发消息成功，要么两者都失败，开源的RocketMQ就支持这一特性，具体原理如下：

1、A系统向消息中间件发送一条预备消息

2、消息中间件保存预备消息并返回成功

3、A执行本地事务

4、A发送提交消息给消息中间件

通过以上4步完成了一个消息事务。对于以上的4个步骤，每个步骤都可能产生错误，下面一一分析：

步骤一出错，则整个事务失败，不会执行A的本地 *** 作步骤二出错，则整个事务失败，不会执行A的本地 *** 作步骤三出错，这时候需要回滚预备消息，怎么回滚？答案是A系统实现一个消息中间件的回调接口，消息中间件会去不断执行回调接口，检查A事务执行是否执行成功，如果失败则回滚预备消息步骤四出错，这时候A的本地事务是成功的，那么消息中间件要回滚A吗？答案是不需要，其实通过回调接口，消息中间件能够检查到A执行成功了，这时候其实不需要A发提交消息了，消息中间件可以自己对消息进行提交，从而完成整个消息事务基于消息中间件的两阶段提交往往用在高并发场景下，将一个分布式事务拆成一个消息事务（A系统的本地 *** 作+发消息）+B系统的本地 *** 作，其中B系统的 *** 作由消息驱动，只要消息事务成功，那么A *** 作一定成功，消息也一定发出来了，这时候B会收到消息去执行本地 *** 作，如果本地 *** 作失败，消息会重投，直到B *** 作成功，这样就变相地实现了A与B的分布式事务。原理如下：

虽然上面的方案能够完成A和B的 *** 作，但是A和B并不是严格一致的，而是最终一致的，我们在这里牺牲了一致性，换来了性能的大幅度提升。当然，这种玩法也是有风险的，如果B一直执行不成功，那么一致性会被破坏，具体要不要玩，还是得看业务能够承担多少风险。

53、TCC编程模式

所谓的TCC编程模式，也是两阶段提交的一个变种。TCC提供了一个编程框架，将整个业务逻辑分为三块：Try、Confirm和Cancel三个 *** 作。以在线下单为例，Try阶段会去扣库存，Confirm阶段则是去更新订单状态，如果更新订单失败，则进入Cancel阶段，会去恢复库存。总之，TCC就是通过代码人为实现了两阶段提交，不同的业务场景所写的代码都不一样，复杂度也不一样，因此，这种模式并不能很好地被复用。

6、总结

分布式事务，本质上是对多个数据库的事务进行统一控制，按照控制力度可以分为：不控制、部分控制和完全控制。不控制就是不引入分布式事务，部分控制就是各种变种的两阶段提交，包括上面提到的消息事务+最终一致性、TCC模式，而完全控制就是完全实现两阶段提交。部分控制的好处是并发量和性能很好，缺点是数据一致性减弱了，完全控制则是牺牲了性能，保障了一致性，具体用哪种方式，最终还是取决于业务场景。作为技术人员，一定不能忘了技术是为业务服务的，不要为了技术而技术，针对不同业务进行技术选型也是一种很重要的能力

数据库事务(Database Transaction) ，是指作为单个逻辑工作单元执行的一系列 *** 作，要么完全地执行，要么完全地不执行。

原子性（Atomic）（Atomicity) 事务必须是原子工作单元；对于其数据修改，要么全都执行，要么全都不执行。通常，与某个事务关联的 *** 作具有共同的目标，并且是相互依赖的。如果系统只执行这些 *** 作的一个子集，则可能会破坏事务的总体目标。原子性消除了系统处理 *** 作子集的可能性。

一致性（Consistent）(Consistency) 事务在完成时，必须使所有的数据都保持一致状态。在相关数据库中，所有规则都必须应用于事务的修改，以保持所有数据的完整性。事务结束时，所有的内部数据结构（如 B 树索引或双向链表）都必须是正确的。某些维护一致性的责任由应用程序开发人员承担，他们必须确保应用程序已强制所有已知的完整性约束。如，当开发用于转帐的应用程序时，应避免在转帐过程中任意移动小数点。

隔离性（Insulation）(Isolation) 由并发事务所作的修改必须与任何其它并发事务所作的修改隔离。事务查看数据时数据所处的状态，要么是另一并发事务修改它之前的状态，要么是另一事务修改它之后的状态，事务不会查看中间状态的数据。这称为隔离性，因为它能够重新装载起始数据，并且重播一系列事务，以使数据结束时的状态与原始事务执行的状态相同。当事务可序列化时将获得最高的隔离级别。在此级别上，从一组可并行执行的事务获得的结果与通过连续运行每个事务所获得的结果相同。由于高度隔离会限制可并行执行的事务数，所以一些应用程序降低隔离级别以换取更大的吞吐量。持久性（Duration）(Durability） 事务完成之后，它对于系统的影响是永久性的。该修改即使出现致命的系统故障也将一直保持。

以上就是关于事务锁与并发问题是什么关系全部的内容，包括:事务锁与并发问题是什么关系、在数据库中，如果对多个事务的并发执行不加以控制，会有哪些异像、深入理解分布式事务，高并发下分布式事务的解决方案等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！