分布式无处不在，数据库事务弱一致性是否必然-CSDN博客

本文链接：https://blog.csdn.net/mlydaemon/article/details/106634241

在计算机系统中，指令是计算机运行的最小的功能单位。在一个多核计算机中，以指令为单位，涉及两条及以上指令的操作都将面临事物一致性的问题。因为两条以上指令涉及多个CPU协作，已经不满足事务一致性的原则了。深入计算机对机器指令的执行以计算机元器件转变为单位，其实每条指令执行，到元器件最终发生转变，这个过程也是被拆分为若干执行过程。如果我们对计算机运行机制不是很理解，那么我们把原子操作放大一点，比如数据库原子操作，比如分布式事务原子性，比如分布式应用原子性。其实基本上我们的任务计算机操作都是非原子性的，当我们在谈论原子性的时候，都是因为相应层次的操作做了相应的原子性保障措施，在这个措施下满足相对原子性。

那么在相对原子性前提下，事务的一致性是否必然是弱一致性呢？确实是这样的，根据CAP理论，相对分布式执行前提下，为了保障服务的可用性和分区容错性，分布式执行前提下，事务的一致性只能是弱一致性。

那么我们回顾到正题，既然所有的计算机执行都可以划归在分布式的范畴，那么我们是否还需要关注锁机制，关注数据的脏幻不可重复读。答案是单库操作下数据库锁可以很好的解决脏幻重读问题，但是在分布式场景下，单纯的锁机制无法妥善解决数据一致性问题。我们先来回顾一下数据库基本常识吧。

数据脏幻不重读问题

数据脏读：脏读是因为读取了为提交的数据。比如A事务读期间，B事务写但是没有提交，A事务读完后B事务回滚。这样A读取的数据和数据库的数据不一致，这种现象就是脏读。
数据幻读：幻读是多次读取的数量不一致。比如A事务两次读期间，B事务提交了数据，那么A事务读取的数量就不一致。这样A第一次读取的数量和第二次读取的数量不一致，这种现象就是幻读。
不可重复读：不可重读读是多次读取的内容不一致。比如A事务两次读期间，B事务提交的修改操作，那么A事务第一次读取的内容就和第二次读取的内容不一致，这种现象就是不可重复读。

数据库锁机制

数据库锁整体分为两类乐观锁和悲观锁，乐观锁由用户实现属于业务锁，悲观锁由数据库实现属于数据库锁。通常悲观锁根据锁的范围不同，又可以分为表锁，行锁，页锁。MyISAM中只用到表锁，不会有死锁的问题，锁的开销也很小，但是相应的并发能力很差。innodb实现了行级锁和表锁，锁的粒度变小了，并发能力变强，但是相应的锁的开销变大，很有可能出现死锁。InnoDB行锁是通过给索引上的索引项加锁来实现的，只有通过索引条件检索数据，InnoDB才使用行级锁，否则，InnoDB将使用表锁。表锁和行锁又分为共享锁和排他锁，除此之外数据库提供更新锁解决行锁升级
，提供意向锁解决表锁和行锁效率问题。

数据库隔离级别问题

数据库隔离级别基本上就是在解决读写加锁的问题，读写四种组合，读写不加锁（Read Uncommited），读不加锁写加锁（Read Commited），读加锁写不加锁（没有这种隔离级别，为什么呢，那是因为多个事务同时读这个不会出现数据不一致问题啊），读加锁写加锁（repeateble Read），不过隔离级别增加了一个Serializable事务串行化调度隔离级别，但是对于数据脏幻不重读这种多次读取过程带来的问题，色日来咋办了并没有帮助。