ACID 理论

文章目录

- - ACID 理论
  - - 什么是ACID？
    - 什么是CAP？
    - BASE 理论

ACID 理论

什么是ACID？

事务的定义和实现一直随着数据管理的发展在演进，当计算机越来越强大，它们就能够被用来管理越来越多数据，最终，多个用户可以在一台计算机上共享数据，这就导致了一个问题，当一个用户修改了数据而另外一个还在使用旧数据进行计算过程中，这里就需要一些机制来保证这种情况不会发生。　　
ACID规则原来是在1970被Jim Gray定义，ACID事务解决了很多问题，但是仍然需要和性能做平衡协调，事务越强，性能可能越低，安全可靠性和高性能是一对矛盾。　　
一个事务是指对数据库状态进行改变的一系列操作变成一个单个序列逻辑元操作，数据库一般在启动时会提供事务机制，包括事务启动停止取消或回滚。　　
但是上述事务机制并不真的实现“事务”，一个真正事务应该遵循ACID属性，ACID事务才真正解决事务，包括并发用户访问同一个数据表记录的头疼问题。

ACID的定义：

Atomic 原子性: 原子性代表一系列的操作要么全做，要么全不做。比如，在银行转账，从一个账号扣钱，另一个账号加钱，这两个操作必须同时进行。否则就会出现账目对不上的情况。
Consistent 一致性: 一致性官方的描述是，事务执行后必须是从一个一致性状态转到另一个一致性状态。通俗点说就是保证整个系统在操作完成后，虽然处于不同状态，但仍保持一致。比如在转账情境中，从一个账号转出500，转入另一个账号，那么整个系统的金额不应该有变化。
Isolate 隔离性：隔离性意味着多个并发之间是不可见的，相互隔离不被打扰。隔离性在数据库操作中还是很重要的，如果不考虑隔离性，
可能会出现下面的问题：
脏读：事务T1读取了事务T2未提交的数据，结果事务T2回滚了，T1拿到了一个脏数据
不可重复读：事务T1读取数据后，紧接着事务T2就更新了数据，事务T1再次读取的时候发现数据不一致了
幻读：这种一般发生在大批量修改的时候，比如事务T1把所有的数据从1修改到了2，结果修改的过程中，事务T2插入了一条新数据1。最后检查数据发现有一条数据没有修改过来。

针对这几种情况，数据库如Mysql提供了几种事务的隔离级别：
Serializable (串行化)：可避免脏读、不可重复读、幻读的发生。
Repeatable read (可重复读)：可避免脏读、不可重复读的发生。
Read committed (读已提交)：可避免脏读的发生。
Read uncommitted (读未提交)：最低级别，任何情况都无法保证。
Durable 持久性：一旦一个事务被提交，它应该持久保存，不会因为和其他操作冲突而取消这个事务。很多人认为这意味着事务是持久在磁盘上，但是规范没有特别定义这点。

什么是CAP？

CAP是分布式系统中进行平衡的理论，它是由 Eric Brewer发布在2000年

Consistent 一致性：强调进群节点中数据一致。在分布式中一致性又包括强一致性和弱一致性，强一致性就是指在任何时刻任何节点看到的数据都是一样的；弱一致性一般实现是最终一致性，即刚开始可能存在差异，但随着时间的推移，最终数据保持一致。
Available 可用性：所有在分布式系统活跃的节点都能够处理操作且能响应查询。强调集群在任何时间内都正常使用
Partition Tolerant 分区容错性：在两个复制系统之间，如果发生了计划之外的网络连接问题，对于这种情况，有一套容错性设计来保证。强调集群在任何时间内都正常使用

一般情况下CAP理论认为你不能同时拥有上述三种，只能同时选择两种，这是一个实践总结，当有网络分区情况下，也就是分布式系统中，你不能又要有完美一致性和100%的可用性，只能这在两者选择一个。在单机系统中，你则需要在一致性和延迟性latency之间权衡。
一般来说分布式集群都会保证P优先，即集群部分节点坏死不影响整个集群的使用，然后再去追求C和A。因为如果放弃P——分区可用性，那不如就直接使用多个传统数据库了。事实上，很多微服务分库分表就是这个道理。

如果追求强一致性，那么势必会导致可用性下降。比如在Master-Slave的场景中，Master负责数据写入，然后分发给各个节点，所有节点都写入成功，才算写入，这样保证了强一致性，但是延迟也会随之增加，导致可用性降低。因此在可用性和一致性之间，就出现了各种解决方案，如时序一致性、最终一致性等等。