-
事务处理 多个事务单元谁先谁后？ 业务属性不匹配（条件不满足） 系统崩溃（事务没有执行结束） 死锁与死锁检测查看全部
-
事务-MVCC 写读场景的优化 写锁上允许并发读。查看全部
-
事务的核心：锁，并发。 事务单元之间的happen-before关系： 读写，写读，读读，写写 序列化读写： 事务排队 优化- 排他锁 （两个事务两个队列） 再优化 - 读写锁 （实现读并行，读写不并行，实现可重复读） 再优化 - 读写锁 （实现读并行，读写并行，写锁取代读锁）查看全部
-
隔离性和锁的关系
查看全部 -
事务单元之间的关系查看全部
-
这就是生活查看全部
-
将读锁和写锁分开定义，让读并行，其他的三种方式RW，WR，WW串行查看全部
-
加排它锁，并行处理无冲突的事务，串行执行有数据冲突的事务查看全部
-
串行方式执行事务查看全部
-
一致性：consistency，保证能看到系统内的所有更改，Can（happen before）
隔离性：以性能为理由，对一致性的破坏。
序列化读写（serializale）
排它锁
读写锁：可重复读（repeatable read），读锁不能被写锁升级，只能做到读读可并行
读已提交（read committed），读读并行，读写并行（写读还不可以并行）
读未提交（read uncommitted），只加写锁，读不加锁，可实现读读并行，读写并行，写读并行
问题：可能读到写过程中的数据
隔离性小结：SQL 92 标准定义隔离性，序列化，可重复读，读已提交，读未提交。
隔离性扩展：快照（snapshot isolation），多版本并发空知MVCC，multi-version concurrency control
查看全部 -
原子性：atomicity，一个事务要么同时成功，要么同时失败
查看全部 -
MVCC：multi-version concurrency control 多版本并发控制
能够做到：写不阻塞读
事务的先后顺序：逻辑时间戳，在oracle中用SCN，在Innodb中使用Trx_id，它仅仅是一个记录先后顺序，不是物理时间戳。
故障恢复：业务属性不匹配，系统崩溃，一般会有一个recovery点进行恢复
死锁与死锁检测：两个线程，不同方向，相同资源。即两个或多个线程，从不同方向，对同一个资源进行加锁控制，那么一定会产生死锁。
死锁解决方法：死锁避免；碰撞检测（最常用）；等锁超时；
查看全部 -
网络带走的：（去中心化）；共享数据困难；贡多的延迟；确定性丧失；
去中心化的结果就是共享数据困难，需要用消息传递方式进行数据共享。但是消息传递必然存在延迟，本机中进程之间消息传递的延迟还可以忍受，但是如果是在网络中进行消息传递，则会有更多的延迟，并且有确定性数据丧失，为了降低确定性丧失数据，则需要等待更多的延迟，更可靠的传递消息协议。
查看全部 -
网络带来的：（去中心化）；理论上无限的扩展能力；理论上无限的数据安全性；理论上无限的服务可用性
查看全部 -
事务：让很多步骤操作顺序发生，多进程/线程看上去就像是一步操作
事务：方便理解，不会让计算机出现故障；但是代价是有加锁和去锁的操作
进程+数据 = 图灵机操作
查看全部
举报