mysql的ACID的理解

时间:2023-03-09 02:08:17
mysql的ACID的理解

这是在网上copy下来的ACID的概念,可以直接跳过看后面:

1、原子性(Atomicity):事务开始后所有操作,要么全部做完,要么全部不做,不可能停滞在中间环节。事务执行过程中出错,会回滚到事务开始前的状态,所有的操作就像没有发生一样。也就是说事务是一个不可分割的整体,就像化学中学过的原子,是物质构成的基本单位。

2、一致性(Consistency):事务开始前和结束后,数据库的完整性约束没有被破坏 。比如A向B转账,不可能A扣了钱,B却没收到。
3、隔离性(Isolation):同一时间,只允许一个事务请求同一数据,不同的事务之间彼此没有任何干扰。比如A正在从一张银行卡中取钱,在A取钱的过程结束前,B不能向这张卡转账。

4、持久性(Durability):事务完成后,事务对数据库的所有更新将被保存到数据库,不能回滚。

其中,原子性和持久性的概念比较好理解。但是最近发现老是把一致性和隔离性混淆。

个人理解,隔离性主要是针对读操作的。在不同事务之间,读操作隔离。比如另一个事务对数据修改后,会不会影响当前事务的读操作,要不要读到更新后的数据。

一致性,主要强调的是数据的更新是不是“正确”,即,是不是符合我们的预期,这个和读操作应该是要分开看待的,这里应该只强调写操作。

造成我对这俩个概念的混淆的原因是,在java的并发编程中,我们关注的似乎只有一致性,没听说过java并发编程中有什么隔离性。造成这个的原因是,我们使用锁,或者volition来保证数据的读取是“正确”的,这种“正确”性的保证是通过“排他锁“(这里加引号是因为严格来说,和排它锁可能会有轻微的区别,比如cpu的缓存锁,缓存失效机制,但是效果上还是有排他的效果)来保证的。这种锁机制,是比mysql的MVCC,或者读锁更加严格的,也就是说在java并发编程中本质上是没有读锁(或者乐观锁)这种概念的,就算是ReentrantReadWriteLock ,也是一种对mysql的读写锁的仿制,在java的底层是不存在这种东西的。

而mysql中所强调的一致性,就和java并发编程中的一致性基本是一致的了,都是通过排他锁来保证的,所以在对俩者进行编程时,他们俩者的思路是互通的,是可以相互借鉴的。

mysql为了增加并发量,引入了乐观锁,MVCC这种概念,但是也带来了隔离的问题,即因为没有排它的强制性保证,就会出现读和写并发的场景,那么就需要考虑,在俩者并发的场景下,读操作到底该做什么样约束的问题。相反,在java并发编程中,可以理解为,在排它的保证下,是不会出现读和写并发的存在的场景的,也就不会有隔离性的问题。(大家可以想一个java中的lock,还有无锁算法中依赖的CAS底层也会有lock前缀的指令)。

最后,当认识到这些问题的时候,我们在写sql的时候有什么借鉴的意义呢?

个人意见:

1.把不必要引入的隔离性问题,也就是读操作,可以省掉的就省掉。比如 我们要并发的对数据库中一条记录的值进行加一操作。也许可以先select出它的值,然后在java程序中+1,然后再update回去,为了防止并发带来的一致性问题,可以在update的where条件中带上变量的原值。 但是,如果直接update ... set variable= variable +1 这样呢,这样的话,就把读操作,也就是隔离性的问题消除了,全部都转化成了写操作,也就是一致性的问题了,而mysql使用排他策略来进行写,在这种场景下是可以保证一致性的。

2.我们在考虑要不要加事务,要什么样的隔离级别的时候,思路就会更加的清晰。在考虑隔离性的时候,我们首先就知道它强调的是读的操作,那首先就专心考虑我们对读的要求,而不会被其他操作所干扰。

其次,我们需要考虑我们对读回的值做了什么计算,然后是怎样把计算的结果又更新到数据库中的。那么,由于读得到的数据不一定是”正确的“,我们的写操作是否需要加一致性的校验(比如在where条件中加上预期的原值)。

举个例子:还是刚刚的对一个记录并发的加一,假设我们使用先select,然后update的方法,而且我们一个操作单元是多条记录。

首先,由于我们的操作单元是多条记录,所以我们需要原子性,即这批数据要么全部成功,要么全部失败,所以我们对这多次的select,update操作加上了事务。

然后,我们的select应该使用什么样的隔离级别呢?

首先考虑下可重复读,在这种隔离级别下,很有可能读到”不正确“的数据,即别的事务提交了对这个值的修改,但是我们在当前事务中读到的仍然是老的数据,那么导致计算出来的结果肯定是”不正确“的。

然后我们考虑下提交读,那么在这种隔离级别下,不会出现刚刚说的问题了,但是,由于并发的问题,在我们读完后,可能另一个事务提交了对这条记录的修改。这又造成了当前事务中计算结果的错误。

最后,是读未提交,在这种级别下,面临的就是另外一个事务在更新后,然后又回滚所造成的问题了。

那么可以发现,这三种隔离级别都没法满足我们的要求,所以,就会发现,原来我们对隔离性其实没什么必须的要求,我们这里需要的,只是数据一致性的要求。为什么我没有说串行化的隔离级别呢,因为这种隔离级别下,所有的操作都是排他的,是不存在隔离性的问题的。

上面举的这俩个例子都很简单,我们实际的场景也许会比这复杂的多,但是,如果理解了上面说的隔离性和一致性到底指的是什么,我觉得在面对复杂场景时,是可以缕出一条很好的解决思路的。