CMU15445 B+树 并发

多线程操作下B+树索引两方面的并发问题：

• 节点内部的数据的安全性，不能让多线程同时修改。
• 节点的安全性，保护节点间分裂合并操作。

latch crabing是B+树常用的并发策略，意思是锁的释放和获取就像螃蟹一样在节点间爬行。线程在遍历时，只有当子节点被认为是“安全”的，才释放父节点的锁。

安全：节点在进行操作后，不会触发分裂或合并，影响父节点的指针。

在查询数据时，节点必然是安全的，而插入和删除操作需要分情况讨论。

插入操作，叶子节点的安全和中间节点的安全情况不同。叶子节点一旦到达maxsize就会分裂，中间节点到达maxsize+1才会分裂。

删除操作，节点一旦小于minsize就会合并。

1. 为rootpage加锁

具体在实现的第一个坑点就是对根节点的处理，根节点是没有父节点保护的。考虑如下图的场景。如果两个线程同时访问根节点，t1线程插入1，t2线程插入4，根节点无锁保护。

1. 两个线程都获取了根节点的指针。
2. t1先加了写锁，t2阻塞在上写锁。
3. t1 完成插入操作后，解锁。
4. t2获取了写锁，误以为P1还是根节点，插入4，导致树的逻辑结构错误。

 

所以需要另外一把锁保护根节点，所有对root_page_id/root_page的访问都是需要锁保护的。只有判断根节点是安全的情况下，才能解锁。

2. 为什么要给sibling加锁

发生borrow/merge 时，要先对兄弟节点加写锁，可能疑惑，父节点不是锁住了，会有线程拿到兄弟节点的锁吗？为什么还要加写锁? 考虑如下情况。

线程t1删除20，线程t2删除5

1. t1先获取根节点的锁，发现P3是安全的，释放根节点锁，然后对P3加写锁。此时t2阻塞会在加P3加写锁阶段。
2. t1到达P2后，发现P2的删除是安全的，释放P3的写锁，开始删除操作。
3. 同时，t2获取P3写锁，到达P1后，发现P1不安全，不释放P3写锁。
4. t2删除5后，触发合并P1与P2的合并。此时t1删除可能还没有完成，所以合并必须加写锁等待t1完成删除操作。

borrow时，兄弟节点的锁要在操作完成后立刻释放并且unpin。

如何为parent解锁：

要用到transaction事务，用到PageSet、DeletedPageSet相关方法。其中PageSet是一个双端队列，DeletedPageSet是一个map。

具体做法是，对某个节点加锁后，再把它的父节点加入PageSet，然后根据情况选择释不释放PageSet中祖先们的锁，如果父节点的锁能释放全局的root锁也一定是能释放掉的（如果父节点都能释放，则父节点肯定不会变，往上可以推出root也不会变）

注意：向上递归的过程中不需要再给父节点加锁，因为在pageset中已经加了

 释放父节点锁的方法

 在findleaf中判断叶子节点是否安全的操作

Unlock / Unpin顺序

 先Unlock后Unpin。因为先Unpin可能这个页面已经被bufferpool置换出去了。

删除节点的时机

在删除过程中，会碰到要把节点删除的情况，这个节点很可能同时也在pageset中，所以要加入DeletedPageSet，等到最后删除完成时，统一的unlock , unpin, delete。

 

总结 解锁的时机

最后总结一下，插入/删除过程中三个解锁时机：

• find_leaf_page过程中，发现节点是安全的，释放所有祖先的锁。
• 删除时节点和兄弟节点发生重分布（合并、分配），不影响父节点大小，提前释放父节点所有祖先的锁。
• 插入/删除完成后，统一释放所有持有的锁。

乐观锁和悲观锁

以上的操作是悲观锁，插入删除都需要对根节点加写锁，根节点是锁的瓶颈，高并发场景下导致效率不高。

乐观锁是乐观的认为，很少的写操作会修改树结构。

实现：一路加读锁，叶子节点加写锁即可。如果发现插入或删除会导致树结构变化，立刻放弃所有锁，调用悲观锁进行修改。

CMU 15445-2022 P2 B+Tree Concurrent Control - 知乎 (zhihu.com)大佬的总结