为什么要有隔离级别
事务的隔离级别(4种)
- 未提交读 在读数据时不会检查或使用任何锁。因此,在这种隔离级别中可能读取到没有提交的数据。
- 已提交读 只读取提交的数据并等待其他事务释放排他锁。读数据的共享锁在读操作完成后立即释放。已提交读是SQL Server的默认隔离级别。
- 可重复读 像已提交读级别那样读数据,但会保持共享锁直到事务结束。
- 可序列化 工作方式类似于可重复读。但它不仅会锁定受影响的数据,还会锁定这个范围。这就阻止了新数据插入查询所涉及的范围,这种情况可以导致幻像读。
事务的ACID
- 原子性:一个事务要么同时成功,要么同时失败。(记录undo日志回滚到之前的版本)
-
一致性:保证能看到系统内的所有更改。Can(happen before)(加了锁)
-
隔离性:以性能为理由,对一致性的破坏。(如果都用排它锁,就可以保证一致性,但性能差。因此提出隔离级别,提高性能,无法避免地破坏了一致性)
序列化读写(排它锁)
读写锁
1. 可重复读,读锁不能被写锁升级,只能做到读读可并行
2. 读已提交,读读并行,读写并行
3. 读未提交,只加写锁,读不加锁。读读并行,读写并行,写读并行。有可能读到写过程中的数据
-
持久性:事务完成以后,该事务对数据库所作的更改便持久地保存在数据库之中
RAID的持久性
1.将一个数据写到多个磁盘上(防止磁盘损坏导致数据丢失)
2.每一次请求都要刷磁盘性能过低怎么办?
2.1直接写入内存 优点是IOPS高 缺点是可能会丢失数据
2.2Group commit(打包成块后一起发送到块存储) 优点是保证系统的持久性和吞吐量 缺点是会使请求延迟提 升
隔离性扩展:快照隔离级别(MVCC/SNAPSHOT ISOLATION)
快照隔离级别(MVCC/SNAPSHOT ISOLATION):针对读多写少场景优化,并行度能达到或超过读未提交,而隔离级别很高
核心思路: Copy on write,无锁编程。
单机事务的典型异常应对策略
- 如何回滚
- 系统down机恢复(已提交事务继续提交,未提交事务回滚)
事务的调优原则
-
在不影响业务应用的前提下,减少锁的覆盖范围
Myisam表锁->Innodb行锁
原位锁-> MVCC多版本
-
在不影响业务应用的前提下,增加锁上可并行的线程数
读锁写锁分离、允许并行读取数据
-
在不影响业务应用的前提下,选择正确锁类型
悲观锁 使线程到blocking状态,通知信息ok的状态切换回等待状态(频繁地换入换出,可能会增加系统的开销)。适合并发争抢比较严重的场景
乐观锁 适合并发争抢不严重的场景
分布式事务
- 目标:像传统单机事务一样的操作方式,可按需无限扩展
if 分布式事务=单机事务+无限扩展
then 单机事务=不存在
-
网络带来的(去中心化)
理论上无限的扩展能力
理论上无限的数据安全性
理论上无限的服务可用性
-
网络失去的
确定性丧失
超时到底是成功还是失败
共享数据困难
共享数据会导致系统有瓶颈
更多的延迟
光速并不是无限的
并发编程难度上升