事务的基本概念

最新推荐文章于 2022-07-04 12:45:16 发布

define_us

最新推荐文章于 2022-07-04 12:45:16 发布

阅读量218

点赞数

分类专栏：数据库

本文链接：https://blog.csdn.net/define_us/article/details/79738918

版权

数据库专栏收录该内容

38 篇文章 0 订阅

订阅专栏

事务

数据库事务必须满足4个特性（ACID）

原子性，事务中的指令要不都完成，要不都不完成
一致性
隔离性
持久性

数据库隔离级别

ANSI/ISO SQL 标准（SQL92）定义了如下事务隔离级别。

Read Uncommitted（读取未提交内容）
简而言之，就是不做事务隔离，上面的所有问题都会发生。实际中很少使用。
Read Committed（读取提交内容）
就是可以抵挡住脏读了。此时，只有事务提交后，其他事务才能看到更改
Repeatable Read（可重读）
防止了不可重复读的现象，但还是允许幻读
Serializable（可串行化）
强行通过对事务排序。可以杜绝一切的事务不一致问题。但是效率也是最低的

隔离性有几个等级。而数据的一致性是最终的目的。

脏读：一事务对数据进行了增删改，但未提交，另一事务可以读取到未提交的数据。如果第一个事务这时候回滚了，那么第二个事务就读到了脏数据。
不可重复读：一个事务中发生了两次读操作，第一次读操作和第二次操作之间，另外一个事务对数据进行了修改，这时候两次读取的数据是不一致的。
幻读：第一个事务对一定范围的数据进行批量修改，第二个事务在这个范围增加一条数据，这时候第一个事务就会丢失对新增数据的修改。
丢失更新 两个事物读取同一数据，然后进行不同操作，然后提交。那么，后提交的数据会把先提交的数据覆盖掉。

隔离级别越高，越能保证数据的完整性和一致性，但是对并发性能的影响也越大。
大多数的数据库默认隔离级别为 Read Commited，比如 SqlServer、Oracle
少数数据库默认隔离级别为：Repeatable Read 比如： MySQL InnoDB
数据库提供对一个事务或是一个会话指定隔离级别的功能。
下面我们以oracle为例讲一讲具体的隔离级别在数据库中的实际执行情况。
Oracle 支持三种事务隔离级别：已提交读取，串行化，以及 SQL92 中没有包含的只读模式（read-only mode）。已提交读取是 Oracle 默认使用的事务隔离级别。
Oracle 强制实现语句级读一致性（statement-level read consistency）。这保证了单一查询的结果集来自一个时间点——即查询开始执行的时间时已经提交的数据。因此，一个查询的结果集永远不会包含脏数据及此查询执行时其他事务提交的数据。（所以oracle不支持Read-Uncommitted的隔离级别）。
如果采用oracle的序列化等级，那么oracle还能保证事务级别的读一致性。因为oracle只支持两个隔离级别，所以oracle在这里采用了乐观锁的实现方式。具体请查看oracle介绍中关于SCN的相关知识。

当然，规则是用来打破的，实际上乱七八糟市场可见的隔离级别一共有七种。主流支持如下

SYBASE支持的隔离级别：degree 0（read uncommitted）、degree 1（read committed）、degree 2（repeatable read）、degree 3（serializable isolation）；
ORACLE支持的隔离级别：read committed（consistent read）、serializable(snapshot isolation)；
DB2支持的隔离级别：read uncommitted、cursor stability、read stability、repeatable read；
Postgresql支持的隔离级别：read committed（consistent read）、repeatable read(snapshot isolation)、serializable isolation(Serialaizable Snapshot Isolation)；
SQL Server支持的隔离级别：read uncommitted、read committed snapshot 、read committed 、repeatable read、snapshot isolation、serializable isolation；
MySQL支持的隔离级别：read uncommitted、read committed（consistent read）、repeatable read(snapshot isolation)、serializable isolation；

详细请参见https://www.jianshu.com/p/69fd2ca17cfd

CAP理论

一个经典的分布式系统理论。CAP理论告诉我们：一个分布式系统不可能同时满足一致性（C：Consistency）、可用性（A：Availability）和分区容错性（P：Partition tolerance）这三个基本需求，最多只能同时满足其中两项。
在实际情况中，二十一世纪的技术中P时一定需要容忍的，我们只能在AC之间取舍。我们最终有BASE方案。

BASE理论

BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的缩写。BASE理论是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于CAP定理逐步演化而来的。BASE理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。

基本可用

基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性----注意，这绝不等价于系统不可用。比如：

（1）响应时间上的损失。正常情况下，一个在线搜索引擎需要在0.5秒之内返回给用户相应的查询结果，但由于出现故障，查询结果的响应时间增加了1~2秒

（2）系统功能上的损失：正常情况下，在一个电子商务网站上进行购物的时候，消费者几乎能够顺利完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面

软状态

软状态指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时

最终一致性

最终一致性强调的是所有的数据副本，在经过一段时间的同步之后，最终都能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

总的来说，BASE理论面向的是大型高可用可扩展的分布式系统，和传统的事物ACID特性是相反的，它完全不同于ACID的强一致性模型，而是通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。但同时，在实际的分布式场景中，不同业务单元和组件对数据一致性的要求是不同的，因此在具体的分布式系统架构设计过程中，ACID特性和BASE理论往往又会结合在一起。