latch与lock区别

  【原文参考https://github.com/sdg-sysdev/bdb-study/blob/master/btree_locking.txt】
   
  B-TREE locking需要区分两种情况:
  1. 并发的数据库事务在查询或修改数据库内容时对B-TREE索引访问的并发控制
  2. 并发的线程对内存中的B-TREE数据结构进行访问时的并发控制
   
  事务并发控制使用Lock,线程并发控制使用Latch
   
  Lock和Latch的区别:
   
  Lock Latch
  分离... 用户事务 线程
  保护... 数据库内容 内存中的数据结构
  存活周期... 整个事务 临界区
  模式... Shared, exclusive, update, 读,写,
  intention, escrow, schema, etc. (可能)更新
  死锁... 检测和分解 避免
  ...通过... 分析waits-for图,超时,事务中止, 编码规范,"lock leveling"
  部分回滚,lock降级
  保存于... Lock管理器的哈希表 被保护的数据结构
   
   
  在分布式事务中,当等待全局事务协调器的决策时,需要保持Locks,以保证本地事务可以
  遵守全局协调器的最终决策。但Latches在这时不需要被保持。
   
  在没有新事务并发执行的崩溃恢复阶段,不需要Locks。因为在系统崩溃之前的并发控制已经
  保证活跃事务之间不会冲突。而Latches则总是被需要。
   
  physiological日志是根据页面中记录的标识来引用它,而不是根据字节位置。因此,在页面
  内移动记录是为数不多的不需要写恢复日志的操作。
   
  在页面内整理空闲空间和记录空间不需要写日志,除非在移除非法记录之后改变了某些记录的标识,
  例如它们在页面内的slot numbers
   
  从系统崩溃中恢复时,如果在日志分析的同时获取Lock,那么可以允许在重做操作及进行补偿操作
  的同时继续事务处理。在此过程中获取的Lock可以不同于原始事务执行过程中获取的Lock。
   
  Latch则仅限于保护那些修改B-TREE结构,但不改变其逻辑内容的操作。典型的例子就是分拆B-TREE节点
  以及在B-TREE相邻节点间均衡负载。其它影响整个B-TREE索引的例子包括压缩,碎片整理,和其它
  形式的重组。影响范围小于一整个节点的例子则是创建和移除幽灵记录。
   
  存在的问题:
  1. 当一个线程在读取缓冲池中的某个页面时,不能被另外一个线程修改。
  2. 当跟随指针(页面标识符)从一个页面到另一个时,例如从B-TREE索引中的一个父节点到一个子节点,
  该指针必须不能被另外一个线程废止(invalidate)
  3. 不仅父-子指针之间有"指针追踪"的问题,在相邻指针之间也存在。不同的线程可能根据升序或降序
  进行索引扫描,这会引起死锁。
  4. 在B-TREE中执行插入操作时,一个子节点可能会因溢出而需要在父节点中进行插入。在极端情况下,
  B-TREE的旧根节点会溢出,而不得不进行分拆,并使用一个新的根节点代替。从叶子节点往根节点
  访问在单线程环境下不会出问题,但在多线程环境下有死锁的可能。
   
   
  对于第一个问题,数据库实现了只读latch和读-写latch。
   
  解决第二个问题的方法是使用"lock coupling",即保留父节点的latch直到获取了子节点的latch。
  如果子节点当前不在缓冲池中,因而需要相对缓慢的磁盘I/O,则在从磁盘读取子节点的过程中
  应该释放父节点上的latch。这种情况下,可以通过获取缓冲池中所选页面对应的描述符结构的latch
  来实现lock coupling。
  另外,为了防止B-TREE在此期间的变化,该I/O应该重新遵循从根到叶子的遍历方式。这么做看起来会
  比较昂贵,但是通常可以直接基于之前的搜索结果。例如,验证在将子节点页面读取到缓冲池中时
  所有父页面上的LSN都没有变化。
   
  第三个问题和第二个类似,只有两点不同。从积极的一面来说,异步read-ahead可以缓解该问题的发生。
  由于B-TREE索引中的大规模read-ahead通常不能依赖于相邻指针,而必须依赖于叶子节点父节点中的指针
  来预读,甚至是祖父节点。从消极的一面来说,要避免相反方向扫描的死锁,latch代码必须提供一种立即
  失败模式。当在向前或向后遍历时发生了获取latch失败的情况,则必须释放所有叶子节点所对应页面的
  latch。
   
  第四个问题是最复杂的。它影响所有的更新,包括插入,删除,甚至记录的更新。
  一个方法是在查找受影响的叶子节点时,将从根节点到叶子节点的遍历过程中碰到的所有节点都加上排他(exclusive)latch。
  这种方法显然的问题是会碰到并发上的瓶颈,尤其在根节点。
  另一个方法是在从根到叶子的搜索过程中使用共享(shared)latch,当有需要的时候将共享latch升级成排他latch。
  在能够允许升级并且没有死锁风险的情况下这种方法很好,但是实际上由于它可能会失败,因此在实现中不能只
  使用该方法。
  第三个方法是在通常的共享和排他latch之外,使用"更新"("update")或"升级"("upgrade") latch。"更新"latch兼容共享
  latch,但是彼此之间不兼容,这导致对于多个更新来说B-TREE根节点还是一个瓶颈。
  以上三个方法可以有个改进,就是当碰到一个更低层的未满节点,如果它能保证拆分操作不会传递到更高层的节点,则可以释放
  从根到父节点这条路径上的所有latch。另一方面,变长B-TREE记录和变长键值会使得决定需要多少空闲空间才能做出该保证
  变得很困难甚至不可能。有趣的是,该问题可以通过以下方法来解决:在释放父节点的latch之前,可以知道如果子节点因为该
  插入操作而需要拆分,则哪个键值会被添加到父节点中去。
  第四个方法在为插入操作从根到叶子的遍历过程中主动拆分节点。该方法避免了第一个方法的瓶颈问题和第二个方法的升级
  失败问题。它的不利之处是在真正需要之前拆分,浪费了一些空间,更重要的是在变长记录和键值的情况下,可能不可能在任何
  情况下都能够主动拆分。
  第五个方法是在初次根到叶子的搜索过程中使用共享latch,当一个节点需要拆分的时候中止该过程。然后启动一个新的过程,
  并且在到达需要拆分的节点时,获取一个排他latch然后拆分。该方法能够受益于之前讨论过的基于之前路径的快速搜索机制。
   
  BLINK-TREE [Lehman and Yao 1981].BLINK-TREE的优势是分配一个新的节点并初始接入到树中是一个本地步骤,仅仅影响一个
  已存在的节点。劣势是搜索可能会稍微慢一点点。在密集插入的情况下,需要有方法来防止形成过长的相邻节点列表。
  (PostgreSQL实现的也是BLINK-TREE索引)
  [Jaluta et al. 2005] 中有更详细的描述。
   
  "key range locking", next-key locking"
   
  在许多B-TREE实现中,当用户事务请求删除记录时实际上并没有实际删除。它只是将该记录标记为非法记录,称为幽灵记录。
  因此,每次查询过程中如果碰到记录头中设置了"ghost bit"的记录,需要将它们从查询结果中剔除。
  在插入一个新的B-TREE键值时,如果一个拥有相同键值的幽灵记录已经存在,则该操作会转化为一个对已有(幽灵)记录的更新操作。
  对幽灵记录的回收在一个异步的清理事务中进行。在被清理之前,它们的键值像通常记录的键值一样参与并发控制和key rangelocking。
   
  Locking in non-unique indexes
  Increment lock modes
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值