厦门做医院网站设计的公司,上海网站建设 app开发,溧水城市建设招标网站,wordpress崩了事务特性:acid;aid为了实现c 原子性#xff1a;一个事务要么全执行#xff0c;要么全不执行-》回滚 sqlite是备份 其他是失败执行语义的反向操作-》算法 一致性#xff1a; 完整性约束在一个事务执行后没有被破坏#xff1a;主键约束#xff0c;外键约束#xff0c;自…事务特性:acid;aid为了实现c 原子性一个事务要么全执行要么全不执行-》回滚 sqlite是备份 其他是失败执行语义的反向操作-》算法 一致性 完整性约束在一个事务执行后没有被破坏主键约束外键约束自定义约束转账两个账户余额的和应该不变 -》约束和回滚实现 持久性 无论发生什么崩溃等 都不会出现磁盘上数据的逻辑错误 其实就是无论发生什么都没有错误任何错误 隔离性 事务之间的影响问题 问题 脏读读到了其他事务正在修改过程中的临时数据 事务A正在访问并修改数据, 事务B读到了A未提交的数据(脏数据) 不可重复读 在事务A中先后读取同一个数据, 两次读取的数据不一样, 针对的是update操作 幻读 2次读取的过程中其他事务插入/删除了【有关】数据针对的是insert和delete操作 事务A按照一定条件进行数据读取, 期间事务B插入或删除了相同搜索条件的新数据, 事务A再次按照原来的条件进行读取时, 发现了事务B新插入或删除的数据. 也就是说, 在事务A中按照某个条件先后两次查询数据库, 两次查询结果的条数不同, 这种现象叫做幻读 脏写将临时无用数据写入了 第一类丢失更新事物A 回滚时 让事物B已提交的数据都被回退了 第二类丢失更新事物A读取数据后事物B修改了数据但是事物A仍然带着第一次读取的数据进行提交导致事物B的修改丢失。这个问题有点像读已提交。 解决方法-》加锁 写锁排他锁给数据加上其他事务 不能写也不能读而且数据只能加一个其实也可以读-》但是不保证【问题】的发生 但是注意写锁对于自己这个事务来说等于是不加锁的 读锁共享锁给数据加上所有事务不能写只有晋升为写锁才能写只能读数据可以加多个事务的。 晋升写锁:数据只加了一个事务的读锁 但是注意读锁对于自己这个事务也是加锁的整个事务的所有读都一样 范围锁一定操作范围内的数据不能被读取和修改用于解决幻读问题 加锁后的结果-》隔离级别 1 可串行化对事物所有读写的数据都加上读锁、写锁、和范围锁 就能实现串行化效率低 2 可重复读对事物涉及的数据加全周期的读锁写锁这样全周期读的数据都一样读锁也可以保证事务结束写操作实现写锁其他事务不能操作。 但是没有解决幻读问题 3 读已提交事物A读取数据部分加读锁但是未施加全周期的读锁但是没有解决幻读问题可重复读问题 不可重复读事务中可能有2次读取数据部分这样如果其他事务修改就2次读取数据不一致了-》不可重复读了 4 读未提交对事物涉及的数据只加全周期的写锁没有解决幻读问题可重复读问题脏读问题但是没有脏写问题 脏读全周期的写锁相当于自己不加锁自己可能读到自己的脏数据临时数据 5 完全不加锁有所有问题 出现脏写问题就已经连事物的原子性都无法保证了。所以一般隔离级别都不会包括他 完全不隔离还会导致第一类丢失更新的问题就是事物A回滚时使得事物B已提交的数据被修改。
读未提交解决第一类丢失问题 可重复读解决第二类丢失问题 MVCC 无锁的隔离场景优化方案主流的商业数据库都采用了这种方案。 全称是 Multi-Version Concurrency Control 多版本并发控制 MVCC的基本思路
MVCC的无锁是特指读取数据时不需要加锁。 MVCC的基本思路是对数据库的任何修改都不会覆盖之前的数据。而是产生一个新版本副本与老版本共存以此达到读取时可以完全不加锁的目的。 新版本和老版本可以理解为每一行记录都有两个看不见的字段CREATE_VERSION和DELETE_VERSION这两个字段记录的都是事物的ID。这里事物的ID是一个全局严格递增的数值。 数据被插入时CREATE_VERSION记录插入数据的事物ID 数据被删除时DELETE_VERSION记录删除数据的事物ID 数据被修改时将修改视为“旧数据删除、新数据新增”则原有数据的。DELETE_VERSION和新数据的CREATE_VERSION为本次修改数据的事物ID。 MVCC优化事物隔离的场景
隔离级别是可重复读总是读取CREATE_VERSION 小于等于当前事物ID的记录如果有多个就取事物ID最大的一个。这样事物A在读取数据时事物B更新了数据产生了新的事物ID的CREATE_VERSION记录也不会被读取事物A仍然读取的是其事物开始时的数据。这个数据不会被更改天然不需要加锁。 隔离级别是读已提交每次读取最新的版本即可这样每次都是读取到最后Commit的数据。 可串行化和读未提交用不上MVCC
串行化的目标是阻塞其他事物的读取和写入MVCC是做读取时无锁优化的自然是用不上。 读未提交 是需要直接读取未提交的数据这种场景下直接修改原始数据即可无需版本字段。 写入写入的场景下MVCC无能为力 MVCC针对的是“读锁”场景的优化对于“写写”的场景加锁几乎是唯一可行的解决方案。 2.3.5 乐观加锁和悲观加锁 一般来说提到的锁都是悲观锁Pessimistic Locking数据库认为需要先加锁再访问数据不然肯定会出问题。而乐观锁策略(Optimistic Locking)认为竞争是偶然情况没有竞争是普遍情况应该一开始不加锁出现竞争时在补救。这种思路是 Optimistic Concurrency ControlOCC“乐观并发控制” 乐观锁和悲观锁的性能优劣主要看并发竞争的剧烈程度如果竞争剧烈乐观锁反而更慢。
