分布式事务解决方案

一、基础知识

• 事务：事务由一组操作构成，我们希望这组操作能够全部正确执行，如果这一组操作中的任意一个步骤发生错误，那么就需要回滚之前已经完成的操作。也就是同一个事务中的所有操作，要么全都正确执行，要么全都不要执行。
• 事务的四大特性ACID：

　　　　原子性：事务是一个不可分割的执行单元，事务中的所有操作要么全都执行，要么全都不执行。

　　　　隔离性：事务的执行是相互独立的，它们不会相互干扰，一个事务不会看到另一个正在运行过程中的事务的数据。

　　　　持久性：持久性要求，一个事务完成之后，事务的执行结果必须是持久化保存的。即使数据库发生崩溃，在数据库恢复后事务提交的结果仍然不会丢失。

　　　　一致性：事务在开始前和结束后，数据库的完整性约束没有被破坏。

• 脏读、幻读、虚读及不可重复读

　　　　脏读：如果一个事务中对数据进行了更新，但事务还没有提交，另一个事务可以“看到”该事务没有提交的更新结果，这样造成的问题就是，如果第一个事务回滚，那么，第二个事务在此之前所“看到”的数据就是一笔脏数据。

　　　　不可重复读：包括幻读和虚读两种情况

　　　　幻读：事务1在两次查询的过程中，事务2对该表进行了插入、删除操作，从而事务1第二次查询的结果发生了变化。

　　　　虚读：在事务1两次读取同一记录的过程中，事务2对该记录进行了修改，从而事务1第二次读到了不一样的记录。

• 数据库的四种隔离级别

　　　1、Read uncommitted 读未提交

　　　　在该级别下，一个事务对一行数据修改的过程中，不允许另一个事务对该行数据进行修改，但允许另一个事务对该行数据读。

　　　　因此本级别下，不会出现更新丢失，但会出现脏读、不可重复读。

　　　2、Read committed 读提交　　　

　　　　在该隔离级别下，不允许2个未提交的事务之间并行执行，但它允许在一个事务执行的过程中，另外一个事务得到执行并提交。这样，会出现一种情况，第一个事务前后两次select出来的某行数据，值可能不一样。值改变的原因是，穿插执行的事务2对该行数据进行了update操作。在同一个事务中，两次select出来的值不相同的问题称为不可重复读问题。要想解决不可重复读问题，需要把数据的隔离级别设置为可重复读。

　　　3、Repeatable read 重复读

　　　　在该隔离级别下，在一个事务使用某行的数据的过程中，不允许别的事务再对该行数据进行操作。可重复读应该是给数据库的行加上了锁。这种隔离级别下，依旧允许别的事务在该表中插入和删除数据，于是就会出现，在事务1执行的过程中，如果先后两次select出符合某个条件的行，如果在这两次select直接另一个事务得到了执行，insert或delete了某些行，就会出现先后两次select出来的符合同一个条件的结果不一样，第一次select好像出现了幻觉一样，因此，这个问题也被成为幻读。要想解决幻读问题，需要将数据库的隔离级别设置为串行化。

　　　4、Serializable 序列化

　　　　该级别要求所有事务都必须串行执行，因此能避免一切因并发引起的问题，但效率很低。

　　　ps：mysql默认的隔离级别是重复读级别，oracle是读提交

• 乐观锁和悲观锁

　　　　乐观锁：总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号机制和CAS算法实现。乐观锁适用于多读的应用类型，这样可以提高吞吐量。

　　　　悲观锁：总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程）。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。Java中synchronized和ReentrantLock等独占锁就是悲观锁思想的实现。

 

二、分布式事务

　　应用场景：　

　　　　当我们的系统采用了微服务架构后，一个电商系统往往被拆分成如下几个子系统：商品系统、订单系统、支付系统、积分系统等。整个下单的过程如下：

　　　　用户通过商品系统浏览商品，他看中了某一项商品，便点击下单

　　　　此时订单系统会生成一条订单

　　　　订单创建成功后，支付系统提供支付功能

　　　　当支付完成后，由积分系统为该用户增加积分

　　　　上述步骤2、3、4需要在一个事务中完成。对于传统单体应用而言，实现事务非常简单，只需将这三个步骤放在一个方法A中，再用Spring的@Transactional注解标识该方法即可。Spring通过数据库的事务支持，保证这些步骤要么全都执行完成，要么全都不执行。但在这个微服务架构中，这三个步骤涉及三个系统，涉及三个数据库，此时我们必须在数据库和应用系统之间，通过某项黑科技，实现分布式事务的支持。

　　CAP理论：

　　　　在一个分布式系统中，最多只能满足C、A、P中的两个需求。

　　　　C--Consistency 一致性，同一数据的多个副本是否实时相同。

　　　　A--Availability 可用性，一定时间内 ，系统返回一个明确的结果 则称为该系统可用。

　　　　P--Partition tolerance 分区容错性，将同一服务分布在多个系统中，从而保证某一个系统宕机，仍然有其他系统提供相同的服务。

　　BASE理论：

　　　　

//todo

语言	方法
1217	2Q7uv
cdDVt	今日头条怎么赚钱「经验分享」新手必看
2680	2008/07/17 10:31:29