mirror of
https://github.com/DistSysCorp/ddia.git
synced 2024-12-24 20:00:51 +08:00
fix italics in ch07
This commit is contained in:
parent
b49cac7cee
commit
2684fcd8af
8
ch07.md
8
ch07.md
@ -687,9 +687,9 @@ WHERE room_id = 123 AND
|
||||
|
||||
### 乐悲观并发控制
|
||||
|
||||
2PL 是一种**悲观**(_pessimistic_)的并发控制机制,就像多线程编程中的**互斥锁**(mutual exclusion)。其背后哲学是,当可能有不好的事情(如并发)发生时,先悲观的等待到条件好转(其他事务释放锁),再进行执行。而物理上的串行执行,是将这种悲观哲学提升到了极致,等价于每个事务在执行时都持有了整个数据库级别的互斥锁。为了弥补这种悲观带来的性能损失,需要保证每个事务执行足够快。
|
||||
2PL 是一种**悲观**(*pessimistic*)的并发控制机制,就像多线程编程中的**互斥锁**(mutual exclusion)。其背后哲学是,当可能有不好的事情(如并发)发生时,先悲观的等待到条件好转(其他事务释放锁),再进行执行。而物理上的串行执行,是将这种悲观哲学提升到了极致,等价于每个事务在执行时都持有了整个数据库级别的互斥锁。为了弥补这种悲观带来的性能损失,需要保证每个事务执行足够快。
|
||||
|
||||
SSI 是一种**乐观**(_optimistic_)的并发控制机制,类比多线程编程中的乐观锁。其相应哲学是,当存在潜在危险时,仍然不做任何检查去大胆的执行。当事务提交时,再进行冲突检测,如果存在冲突,则回退重试。将乐观发展到极致,则是不上任何锁,但为了给这种乐观进行兜底,需要在执行完后进行检查。
|
||||
SSI 是一种**乐观**(*optimistic*)的并发控制机制,类比多线程编程中的乐观锁。其相应哲学是,当存在潜在危险时,仍然不做任何检查去大胆的执行。当事务提交时,再进行冲突检测,如果存在冲突,则回退重试。将乐观发展到极致,则是不上任何锁,但为了给这种乐观进行兜底,需要在执行完后进行检查。
|
||||
|
||||
乐观并发控制并不是一种新思想,其优缺点被充分的讨论过:
|
||||
|
||||
@ -706,7 +706,7 @@ SSI,顾名思义,基于快照隔离。即在 SSI 隔离级别中,所有的
|
||||
2. 决策:考察读到的数据,做出某种决策。
|
||||
3. 写入:将对应决策造成结果写回数据库。
|
||||
|
||||
即,这里面存在一个因果关系,读为因,写为果。如果在提交时,发现决策的**前提**(_premise_,如:“今天有两名医生排到了值班”)不再满足,则后面写入失去意义。因此为了提供可串行化的隔离级别,需要识别这种因果关系,并且能够在提交时检测前提是否失效,以决定是否中止事务。
|
||||
即,这里面存在一个因果关系,读为因,写为果。如果在提交时,发现决策的**前提**(*premise*,如:“今天有两名医生排到了值班”)不再满足,则后面写入失去意义。因此为了提供可串行化的隔离级别,需要识别这种因果关系,并且能够在提交时检测前提是否失效,以决定是否中止事务。
|
||||
|
||||
那如何检测前提是否失效呢?
|
||||
|
||||
@ -752,7 +752,7 @@ SSI,顾名思义,基于快照隔离。即在 SSI 隔离级别中,所有的
|
||||
1. 如果细粒度跟踪,虽然能精确的检测到真正的冲突,减少重试,但会有显著的记录开销。
|
||||
2. 如果粗粒度的跟踪,虽然性能会好,但会导致更多的冲突和重试。
|
||||
|
||||
在某些情况下,即使一个事务读到的信息被另外一个事务的写入覆盖,仍然能保证可串行化的隔离级别。这取决于事务读到这些信息后,用来做了什么,_PostgreSQL_ 便根据这个原则来减少不必要的重试。
|
||||
在某些情况下,即使一个事务读到的信息被另外一个事务的写入覆盖,仍然能保证可串行化的隔离级别。这取决于事务读到这些信息后,用来做了什么,*PostgreSQL* 便根据这个原则来减少不必要的重试。
|
||||
|
||||
和 2PL 相比,SSI 的最大优点是,不会通过锁来阻塞有依赖关系的事务并发执行。SSI 就想运行在快照隔离级别一样,读不阻塞写,写不阻塞读。只是追踪记录,在提交时决定是否提交或重试。这种设计是的查询延迟更可预测。尤其是,只读事务可以工作在一致性快照上,而不受影响,这对读负载很重的场景很有吸引力。
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user