数据库事物ACID特性和分布式系统CAP理论

蔚落 2022-05-31 13:37 312阅读 0赞

# ACID特性和分布式系统CAP理论 #

--------------------

## 事物的介绍和认识 ##

事务通常指的是数据库事务,不要把它太概念化，就是一些列操作要么都执行要么都不执行，把这些操作封装在一个不可分割的单元体里这么理解就可以。
    //备注最常见用来举例说明事务的例子应该就是银行账户转账的场景了吧。
    在mysql中只有部分数据库引擎才支持事务，推荐尽量都使用支持事务的引擎，不然给后面开发带来很多麻烦
    (切身体会，曾经在一家公司做支付系统和订单业务太痛苦了，公司每天流水有几百万搞得真是提心吊胆啊)

## ACID的介绍和理解 ##

**数据库事务所应具备的四个特性:**

1、Atomicity(原子性)
    2、Consistency(一致性)
    3、Isolation(隔离性)
    4、Durability(持久性)
    备注:这里的数据库事务通常指的是关系型数据库的事务。

--------------------

### 原子性 ###

An atomic transaction is an indivisible and irreducible seriesof database operations such that either all occur, or nothing occurs.原子性事务是一个不可分割和一系列不可约数据库操作,要么全部执行要么就都不执行。
    原子性事务:首先我们应该从表面意思去理解原子,原子是世界上最小不可分割单
    位体,原子性事务就是在事务的基础上加上原子的特性。

--------------------

**Example**

Example of atomic transaction is a monetary transfer from bank account A to account B. It consists of two operations,withdrawing the money from account A and saving it to account B. Performing these operations in an atomic transaction ensuresthat the database remains in a consistent state, that is, money is not lost nor created if either of those two operations fail.Atomicity requires that each transaction be "all or nothing": if one part of the transaction fails, then the entire transactionfails, and the database state is left unchanged.

--------------------

### 一致性 ###

Consistency in database systems refers to the requirement that any given database transaction must change affecteddata only in allowed ways. Any data written to the database must be valid according to all defined rules,including constraints,cascades, triggers, and any combination thereof.一致性,即在事务开始之前和事务结束以后,数据库的完整性约束没有被破坏
    一致性分为两个层面
        1.数据库机制层面
        数据库层面的一致性是，在一个事务执行之前和之后，数据会符合你设置的约束（唯一约束，外键约束等)和触发器设置.
        这一点是由数据库进行保证的.
        2.业务层面
        对于业务层面来说,一致性是保持业务的一致性.这个业务一致性需要由开发人员进行保证.

--------------------

### 隔离性 ###

事务的执行是互不干扰的,一个事务不可能看到其他事务运行时，中间某一时刻的数据。
    备注:隔离级别才是要好好探讨的关注点。

--------------------

### 持久性 ###

持久性，意味着在事务完成以后，该事务所对数据库所作的更改便持久的保存在数据库之中，并不会被回滚。
    即使出现了任何事故比如断电等，事务一旦提交，则持久化保存在数据库中.

--------------------

In database systems, durability is the ACID property which guarantees that transactions that havecommitted will survive permanently. For example, if a flight booking reports that a seat has successfully
    been booked, then the seat will remain booked even if the system crashes.
    Durability can be achieved by flushing the transaction's log records to non-volatile storage beforeacknowledging commitment.In distributed transactions, all participating servers must coordinate before
    commit can be acknowledged. This is usually done by a two-phase commit protocol.

## 再谈数据库隔离级别 ##

### read uncommitted(读未提交) ###

This is the lowest isolation level. In this level, dirty reads are allowed, so one transaction maysee not-yet-committed changes made by other transactions.备注:有脏读的风险,几乎不会使用这个隔离级别。

--------------------

**脏读**

脏读:通常是由于一个线程在一个事务中修改了某数据,但是还未提交。与此同时另一个线程读取该数据，
    并且上一个事务由于之后的执行出错了,导致数据回滚，那么就会引起业务上的问题了。

### read committed(读已提交) ###

In this isolation level, a lock-based concurrency control DBMS implementation keeps write locks(acquired on selected data) until the end of the transaction, but read locks are released as soon asthe SELECT operation is performed (so the non-repeatable reads phenomenon can occur in this isolationlevel, as discussed below). As in the previous level, range-locks are not managed.备注:可以防止数据脏读,但是还会产生不可重复读和幻读。

**不可重复读**

在数据库访问中一个事务范围内两个相同的查询却返回了不同数据。这是由于查询时系统中其他事务修改的提交而引起的。
    举例:事务A中需要对某个查询执行两次，当第一次执行完时，事务B对其数据进行了修改。事务A中再次查询时，数据发生了
    改变(是否会影响实际业务要看实际业务的场景决定);

### Repeatable reads(可重复读) ###

In this isolation level, a lock-based concurrency control DBMS implementation keeps read and write locks
    (acquired on selected data) until the end of the transaction. However, range-locks are not managed, so phantom reads can occur.
    备注:可以防止数据脏读和不可重复读但是还是可能会产生幻读。

**幻读**

是指当事务不是独立执行时发生的一种现象，例如第一个事务对一个表中的数据进行了修改，这种修改涉及到表中的全部数据行。
    同时，第二个事务也修改这个表中的数据，这种修改是向表中插入一行新数据。那么，以后就会发生操作第一个事务的用户发现表中
    还有没有修改的数据行，就好象发生了幻觉一样.

--------------------

**举例**

事务A
        1、更新user表所有name字段为admin,
        2、查询user表信息(包含name信息)
    事务B
        1、插入user表一条记录,name字段默认xxx
    假如在A执行完第一步之后,在执行第二部之前时候,事务B执行完成。事务A最后查询结果就不是自己期望看到的
    (有一个user的name属性不是admin,并不是所有user的name属性是admin).

### Serializable(序列化) ###

This is the highest isolation level.With a lock-based concurrency control DBMS implementation,serializability requires read and write locks (acquired on selected data) to be released at the endof the transaction. Also range-locks must be acquired when a SELECT query uses a ranged WHERE clause,especially to avoid the phantom reads phenomenon (see below).备注:序列化隔离级别可以防止任何数据读取隐患,但是性能也是非常的低的,每次只允许一个线程操作,阻塞其它所有线程的操作。

### 数据库隔离级别总结 ###

为了避免上述几种事务之间的影响,数据库通过设置不同的隔离等级来进行不同程度的避免。因为高的隔离等级意味着更多的锁，
    从而牺牲性能.所以这个选项开放给了用户根据具体的需求进行设置。不过默认的隔离等级Read Commited符合了99%的实际需求.
    总之，不同的隔离级别是通过加不同的锁，造成阻塞来实现的。

**举例说明**

模拟XXX银行转账取款场景:
    A账户余额:1000
    B账户余额:1000
    client_X执行A向B转款300元操作:
    1、A查询余额是否大于300元?true执行减200操作
    2、B执行余额加300操作
    3、业务操作,比如写日志之类的数据库操作
    client_Y执行B取钱操作(假如取1200元):
    1、查询B账户余额是否大于1200?true 就可以拿到钱了
    如果该银行应用使用的是读未提交事务隔离级别产生的问题
    client_X在t1时刻开始操作执行完第二步骤的时候,client_Y也开始执行了,假设Client_X执行第三步骤很慢,
    此时client_Y已经把1200块钱取出来了,与此同时client_x在经过漫长执行第三步过程失败了,回滚了事务,
    那么A账户还是原来的1000元,B账户还有100元(用户取出了1200元现金),因此银行损失了300元,这肯定是银行
    不想看到的。因此最基本的要保证读已提交的数据.

--------------------

## 分布式系统CAP理论介绍和理解 ##

在计算机科学理论，CAP 定理（也称为 Brewer 定理），是由计算机科学家 Eric Brewer 提出的，
    在分布式计算机系统不可能同时提供以下全部三个保证:
    Consistency(数据一致性):所有节点同一时间看到是相同的数据
    Availability(服务可用性):所有请求不管是否成功都能接收到响应。可终止、不会一直等待.
    Partition tolerance(分区容错性):系统任意分区后,在网络故障时,仍能操作.

![CAP模型][CAP]

--------------------

### CAP常见模型 ###

**CA模型**

牺牲分区容错性,保证一致性和可用性

![CA 模型][CA]

举例:
        单站点数据库
        集群数据库
        LDAP
        xFS 文件系统
    实现方式：
        两阶段提交
        缓存验证协议

--------------------

**CP模型**

牺牲可用性,保证一致性和分区容错性

![CP模型][CP]

举例:
        分布式数据库
        分布式锁定
        绝大部分协议
    实现方式:
        悲观锁
        少数分区不可用

--------------------

**AP模型**

牺牲一致性,保证可用性和分区容错性

![AP模型][AP]

举例:
        Coda
        Web 缓存
        DNS
    实现方式
        到期/租赁
        解决冲突
        乐观

--------------------

**CAP 的意义**

在系统架构时,应该根据具体的业务场景,来权衡 CAP。比如，对于大多数互联网应用来说（如门户网站）,因为机器数量庞大，部署节点分散，网络故障是常态，可用性是必须需要保证的，所以只有舍弃一致性来保证服务的 AP。而对于银行等,需要确保一致性的场景,通常会权衡 CA 和 CP 模型,CA 模型网络故障时完全不可用,CP 模型具备部分可用性。

**选择参考**

如果是做缓存那么对一致性要求就不会很高,因此可以牺牲Consistency.对于互联网行业由于用户量大、
    节点多对可用性要求就比较高,所以Availability就必须要保证.对于银行这种场景业务对一致性要求特别高,
    所以首先要保证Consistency

## 总结 ##

数据库事务的ACID特性和分布式系统的CAP理论都是比较重要的理论知识点，对我们分析和做设计架构有一定的参考思想。

## 参考 ##

1、https://en.wikipedia.org/wiki/ACID  
2、http://www.cnblogs.com/CareySon/archive/2012/01/29/2331088.html  
3、https://de.wikipedia.org/wiki/CAP-Theorem  
4、https://en.wikipedia.org/wiki/Database\_transaction  
5、https://en.wikipedia.org/wiki/Distributed\_transaction

[CAP]: /images/20220531/69abfc927d7944d594c7ecdcd9b4e88e.png
[CA]: /images/20220531/a3a91a870eb045e0b147e63acb9c8b5a.png
[CP]: /images/20220531/5fe692e2cadc436a8d5824cd211f7a3a.png
[AP]: /images/20220531/bca3d6d833974367bdba98b166df4a9d.png