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