深入 ‘B+ Tree Concurrency Control’：解析如何在 Go 中通过读写锁（Latch）优化树节点的并发访问

深入B+树并发控制：Go语言中读写锁（Latch）优化树节点并发访问

各位编程爱好者、数据库架构师以及对高性能数据结构充满好奇的朋友们，大家好！

今天，我们将深入探讨一个在高性能数据库和文件系统中至关重要的话题：B+树的并发控制。具体来说，我们将聚焦如何在Go语言中，利用其强大的并发原语——读写锁（sync.RWMutex），实现对B+树节点的高效且安全的并发访问，也就是我们常说的“Latch Crabbing”或“Coupled Latching”技术。

B+树作为一种自平衡的树形数据结构，因其在磁盘IO效率上的卓越表现，成为数据库索引、文件系统目录等场景的首选。然而，当多个并发操作（如插入、删除、查找）同时对B+树进行修改时，如果没有适当的并发控制机制，轻则数据不一致，重则树结构被破坏，导致系统崩溃。

1. B+树并发访问的挑战

B+树的特性决定了其并发控制的复杂性：

1. 树结构动态变化：插入和删除操作可能导致节点分裂（split）或合并（merge），进而影响父节点甚至根节点。这些结构性变化必须是原子的，并且对其他并发操作可见且安全。
2. 多路径访问：查找操作需要从根节点遍历到叶节点。在遍历过程中，如果路径上的节点正在被修改，查找操作可能会读到不一致的数据，甚至跟随一个已经不存在的指针。
3. 读写冲突：读操作（查找）与写操作（插入、删除）之间存在冲突。写操作之间也存在冲突。
4. 死锁风险：多个并发写操作同时修改树的不同部分时，如果不遵循严格的加锁顺序，很容易发生死锁。

为了解决这些问题，我们需要引入一种轻量级的同步机制——Latch。

2. Latch与传统锁：为何选择Latch？

在并发编程中，我们通常会接触到各种锁。例如，Go语言中的sync.Mutex和sync.RWMutex。那么，Latch与它们有何区别，为何在B+树中选择Latch？

• 传统锁（Lock）：通常与事务（Transaction）相关联，用于保护逻辑数据（如行、表），其持有时间可能较长，直到事务提交或回滚。它们关注的是事务的隔离性（Isolation）和原子性（Atomicity）。
• Latch（栓锁/闩锁）：是一种轻量级的、短期的互斥机制，主要用于保护内存中的物理数据结构（如B+树节点、哈希表桶）。它的持有时间非常短，通常在几微秒到几十微秒之间，仅仅覆盖对数据结构局部修改的关键代码段。Latch不参与事务回滚，也不保证事务隔离性。它们关注的是数据结构本身的完整性（Integrity）。

在B+树并发控制中，我们正是需要这种能够快速获取和释放，保护单个节点内存结构的机制。Go语言的sync.RWMutex由于其读写分离的特性，非常适合作为B+树节点的Latch：

• RLock() / RUnlock()：允许多个读取者同时访问节点，提高了并发读的性能。
• Lock() / Unlock()：只允许一个写入者访问节点，确保了写入操作的原子性和互斥性。

3. B+树基本结构与Go语言表示

在深入探讨并发控制之前，我们先定义B+树的基本结构。为简化问题，我们假设B+树存储整数键（int）和字符串值（string），且只关注内部节点和叶节点。

package btree

import (
    "fmt"
    "sort"
    "sync"
)

const (
    // B+树的最小度数 (minimum degree)
    // 一个节点（除了根节点）至少有 minDegree-1 个键和 minDegree 个子节点
    // 根节点至少有1个键
    // 叶节点至少有 minDegree-1 个键
    // 最大键数 = 2*minDegree - 1
    // 最大子节点数 = 2*minDegree
    defaultMinDegree = 2 // 示例用，实际应用中通常更大
)

// KeyValue represents a key-value pair
type KeyValue struct {
    Key   int
    Value string
}

// Node represents a B+ tree node
type Node struct {
    isLeaf   bool           // 是否为叶节点
    keys     []int          // 存储键
    values   []string       // 仅用于叶节点，存储值
    children []*Node        // 仅用于内部节点，存储子节点指针
    parent   *Node          // 父节点指针，方便向上操作
    rwLatch  sync.RWMutex   // 节点Latch
}

// BTree represents the B+ tree itself
type BTree struct {
    root       *Node          // 根节点
    minDegree  int            // 最小度数
    rootChange sync.Mutex     // 保护根节点指针变化的全局Latch
    size       int            // 树中键值对的数量
}

// NewBTree creates a new B+ tree
func NewBTree(minDegree int) *BTree {
    if minDegree < 2 {
        minDegree = defaultMinDegree
    }
    // 初始时，树是空的，根节点为nil。
    // 第一次插入时创建根节点。
    return &BTree{
        minDegree: minDegree,
    }
}

// maxKeys returns the maximum number of keys a node can hold
func (t *BTree) maxKeys() int {
    return 2*t.minDegree - 1
}

// minKeys returns the minimum number of keys a non-root node can hold
func (t *BTree) minKeys() int {
    return t.minDegree - 1
}

// newNode creates a new B+ tree node
func (t *BTree) newNode(isLeaf bool) *Node {
    return &Node{
        isLeaf:   isLeaf,
        keys:     make([]int, 0, t.maxKeys()),
        values:   make([]string, 0, t.maxKeys()), // Only used by leaf nodes, but pre-allocate capacity
        children: make([]*Node, 0, t.maxKeys()+1), // Only used by internal nodes, pre-allocate capacity
    }
}

// utility function to find the index of a key in a node's keys slice
func findKeyIndex(keys []int, key int) int {
    return sort.SearchInts(keys, key)
}

4. 并发查找操作：读Latch Crabbing

查找操作是B+树中最频繁的读操作。为了最大化并发性，我们采用“读Latch Crabbing”（Read Latch Crabbing）协议。其核心思想是：自上而下，逐级获取读锁，并在获取到子节点的读锁后，立即释放父节点的读锁。

这样，只有当前正在访问的节点及其子节点（短暂）被锁住，其他goroutine可以自由访问树的其他部分。

// Search finds the value associated with a key.
// It uses read latch crabbing for high concurrency.
func (t *BTree) Search(key int) (string, bool) {
    t.rootChange.Lock() // Protect root pointer for a moment
    root := t.root
    t.rootChange.Unlock()

    if root == nil {
        return "", false
    }

    // Start crabbing from the root
    node := root
    node.rwLatch.RLock() // Acquire read latch on the root

    for !node.isLeaf {
        idx := findKeyIndex(node.keys, key)
        if idx < len(node.keys) && node.keys[idx] == key {
            // If key is found in internal node, we still need to go to the rightmost child for that key.
            // In B+ tree, all keys are in leaf nodes. Internal nodes only guide the path.
            // So, if key == node.keys[idx], we go to children[idx+1]
            // Otherwise (key < node.keys[idx]), we go to children[idx]
            // This logic is simplified: always go to the right child if key is matched in an internal node.
            // More precisely, for B+ tree, if key == node.keys[idx], the actual value is in the leaf
            // pointed to by children[idx+1] (or children[idx] if the internal key is a copy).
            // Let's assume standard B+ tree where internal keys are separators.
            // So, if key <= node.keys[idx], go to children[idx]. If key > node.keys[idx], go to children[idx+1].
            // The findKeyIndex handles this by returning the index where 'key' would be inserted.
            // So, we always go to children[idx].
        }

        nextChild := node.children[idx]

        nextChild.rwLatch.RLock() // Acquire read latch on the child
        node.rwLatch.RUnlock()     // Release read latch on the parent

        node = nextChild
    }

    // Now 'node' is a leaf node, with its read latch held
    defer node.rwLatch.RUnlock() // Ensure leaf latch is released

    // Search within the leaf node
    idx := findKeyIndex(node.keys, key)
    if idx < len(node.keys) && node.keys[idx] == key {
        return node.values[idx], true
    }

    return "", false
}

代码解析：

1. t.rootChange.Lock(): 在访问根节点前，先短暂地获取rootChange锁。这是因为根节点指针本身可能会在分裂或合并时发生变化。我们需要确保在读取t.root时，它是一个稳定的指针。
2. node.rwLatch.RLock(): 获取当前节点的读锁。
3. findKeyIndex(node.keys, key): 找到键在当前节点中的位置，以决定下一个要访问的子节点。
4. nextChild.rwLatch.RLock(): 在移动到子节点之前，先获取子节点的读锁。
5. node.rwLatch.RUnlock(): 在成功获取子节点的读锁后，立即释放当前父节点的读锁。这是“Crabbing”的关键。
6. defer node.rwLatch.RUnlock(): 当遍历到叶节点时，确保在函数返回前释放叶节点的读锁。

这个协议保证了查找路径上任何时刻都只有至多两个节点（当前节点和它的父节点或子节点）被读锁保护，极大地提高了读取并发性。

5. 并发插入操作：写Latch Crabbing

插入操作更为复杂，因为它可能导致节点分裂，进而影响父节点，甚至导致根节点分裂。这需要更精细的Latch管理，通常采用“写Latch Crabbing”（Write Latch Crabbing）协议。

写Latch Crabbing的核心思想是：在从根节点向下遍历时，尝试获取读锁。但在移动到子节点之前，需要判断子节点是否“安全”（safe）。如果子节点是安全的（即它有足够的空间，即使插入新键也不会分裂），则可以释放父节点的读锁。如果子节点不安全（即它已满，插入新键会导致分裂），则必须保持父节点的读锁，以便在子节点分裂时能够直接修改父节点。

由于Go的sync.RWMutex没有直接的“升级锁”（从读锁升级到写锁）机制，我们通常需要 RUnlock() 后再 Lock()，这中间存在一个短暂的窗口。在实际的数据库系统中，会使用专门的Latch类型或更复杂的协议来处理这种情况。为了教学目的，我们将采用一种相对简洁但仍能体现Crabbing思想的策略：向下遍历时保持读锁链，在需要修改时，释放读锁，然后从下往上重新获取写锁。

考虑到篇幅和复杂性，我们先实现一个辅助函数findLeafForWrite，它会找到插入点，并返回一条包含读锁的路径。

// insertKey inserts a key-value pair into the B+ tree.
// It uses a form of write latch crabbing.
func (t *BTree) Insert(key int, value string) {
    t.rootChange.Lock() // Protect root pointer for a moment
    root := t.root
    t.rootChange.Unlock()

    if root == nil {
        // Tree is empty, create a new root
        t.rootChange.Lock() // Exclusive lock for root modification
        if t.root == nil { // Double-check
            t.root = t.newNode(true)
            t.root.rwLatch.Lock() // Latch the new root
            t.root.keys = append(t.root.keys, key)
            t.root.values = append(t.root.values, value)
            t.root.rwLatch.Unlock() // Release latch
            t.size++
        }
        t.rootChange.Unlock()
        return
    }

    // Traverse down to find the leaf node
    // This path will hold read latches on unsafe nodes
    path, leaf, err := t.findLeafForWrite(key)
    if err != nil {
        // This should not happen for insertion if the tree is correctly structured
        fmt.Printf("Error finding leaf for write: %vn", err)
        return
    }

    // Now 'leaf' is the target leaf node, and its read latch is held.
    // 'path' contains ancestors whose read latches are also held if they were "unsafe".

    // Upgrade leaf latch to write latch
    leaf.rwLatch.RUnlock() // Release read latch
    leaf.rwLatch.Lock()    // Acquire write latch

    // Check for duplicate keys in the leaf node
    idx := findKeyIndex(leaf.keys, key)
    if idx < len(leaf.keys) && leaf.keys[idx] == key {
        // Key already exists, update value
        leaf.values[idx] = value
        leaf.rwLatch.Unlock() // Release write latch
        // Release any remaining read latches on the path
        for i := len(path) - 1; i >= 0; i-- {
            path[i].rwLatch.RUnlock()
        }
        return
    }

    // Insert into the leaf
    leaf.keys = append(leaf.keys, 0)
    copy(leaf.keys[idx+1:], leaf.keys[idx:])
    leaf.keys[idx] = key

    leaf.values = append(leaf.values, "")
    copy(leaf.values[idx+1:], leaf.values[idx:])
    leaf.values[idx] = value

    t.size++

    // Check if leaf needs to split
    if len(leaf.keys) > t.maxKeys() {
        // Split current node and propagate up
        t.splitChild(leaf, path)
    } else {
        // No split, just release leaf latch and then ancestor read latches
        leaf.rwLatch.Unlock()
        for i := len(path) - 1; i >= 0; i-- {
            path[i].rwLatch.RUnlock()
        }
    }
}

// findLeafForWrite traverses the tree to find the appropriate leaf node for insertion/deletion.
// It implements the descent part of write latch crabbing.
// It returns the path of ancestors (with their read latches held if "unsafe"), the target leaf node (with its read latch held),
// and an error if the root is nil (should be handled by caller).
func (t *BTree) findLeafForWrite(key int) ([]*Node, *Node, error) {
    node := t.root
    if node == nil {
        return nil, nil, fmt.Errorf("root is nil, tree is empty")
    }

    path := make([]*Node, 0) // Stores ancestors whose read latches are held

    node.rwLatch.RLock() // Acquire read latch on the root

    for !node.isLeaf {
        idx := findKeyIndex(node.keys, key)
        nextChild := node.children[idx]

        nextChild.rwLatch.RLock() // Acquire read latch on the child

        // Check if the current node (parent) is "safe" to release its latch
        // A node is "safe" if its child (nextChild) won't cause it to split.
        // nextChild is safe if it has room for one more key without splitting.
        // If nextChild is full, then 'node' (current parent) is NOT safe,
        // because a split in nextChild would require modifying 'node'.
        if len(nextChild.keys) < t.maxKeys() {
            // nextChild is safe, so we can release current node's latch
            node.rwLatch.RUnlock()
        } else {
            // nextChild is full, current node is NOT safe, keep its read latch
            path = append(path, node) // Add current node to the path of held read latches
        }
        node = nextChild
    }
    // 'node' is now the target leaf node, and its read latch is held.
    return path, node, nil
}

// splitChild splits a full child node into two and propagates the median key up to the parent.
// This function assumes the parent (if not nil) is write-latched.
func (t *BTree) splitChild(child *Node, path []*Node) {
    // child is already write-latched from the caller (Insert/Delete)

    medianKeyIndex := t.minDegree - 1 // Index of the median key

    // Create new right sibling node
    newRightSibling := t.newNode(child.isLeaf)
    newRightSibling.parent = child.parent // Set parent link

    // Median key to be promoted to parent
    promotedKey := child.keys[medianKeyIndex]

    // Move keys and values (or children) to the new right sibling
    newRightSibling.keys = append(newRightSibling.keys, child.keys[medianKeyIndex+1:]...)
    if child.isLeaf {
        newRightSibling.values = append(newRightSibling.values, child.values[medianKeyIndex+1:]...)
        // For leaf nodes, the median key is copied to the new right sibling as well
        // and promoted to the parent.
        // The original leaf node keeps keys up to medianKeyIndex.
        newRightSibling.keys = append([]int{promotedKey}, newRightSibling.keys...)
    } else {
        newRightSibling.children = append(newRightSibling.children, child.children[medianKeyIndex+1:]...)
        for _, grandChild := range newRightSibling.children {
            grandChild.parent = newRightSibling
        }
    }

    // Truncate original child node
    child.keys = child.keys[:medianKeyIndex]
    if child.isLeaf {
        child.values = child.values[:medianKeyIndex]
    } else {
        child.children = child.children[:medianKeyIndex+1]
    }

    // Release write latch on child, it's done with its local modification
    child.rwLatch.Unlock()

    // Handle parent insertion
    if child.parent == nil {
        // Child was the root, so create a new root
        t.rootChange.Lock() // Lock for root pointer change
        newRoot := t.newNode(false)
        newRoot.rwLatch.Lock() // Latch new root
        newRoot.keys = append(newRoot.keys, promotedKey)
        newRoot.children = append(newRoot.children, child, newRightSibling)
        child.parent = newRoot
        newRightSibling.parent = newRoot
        t.root = newRoot // Update global root pointer
        newRoot.rwLatch.Unlock() // Release new root latch
        t.rootChange.Unlock() // Release root pointer lock
    } else {
        // Parent already has a read latch held (from path)
        parent := child.parent
        // Upgrade parent latch to write latch
        // This is the tricky RUnlock()/Lock() part.
        // In a real system, you'd ensure this is safe (e.g., by ensuring consistent order or retry)
        parent.rwLatch.RUnlock() // Release read latch on parent
        parent.rwLatch.Lock()    // Acquire write latch on parent

        // Find where to insert the new key and child pointer in the parent
        idx := findKeyIndex(parent.keys, promotedKey)
        parent.keys = append(parent.keys, 0)
        copy(parent.keys[idx+1:], parent.keys[idx:])
        parent.keys[idx] = promotedKey

        parent.children = append(parent.children, nil)
        copy(parent.children[idx+2:], parent.children[idx+1:])
        parent.children[idx+1] = newRightSibling

        // Check if parent needs to split
        if len(parent.keys) > t.maxKeys() {
            // Parent is now full, it also needs to split
            // Recursively call splitChild for the parent
            // Before recursive call, we need to release ancestor read latches
            // that are higher than parent.
            var newPath []*Node
            for _, pNode := range path {
                if pNode != parent {
                    newPath = append(newPath, pNode)
                } else {
                    break // parent is the highest node in the path we're currently processing
                }
            }
            t.splitChild(parent, newPath)
        } else {
            // Parent did not split, release its write latch and then ancestor read latches
            parent.rwLatch.Unlock()
            // Release any remaining read latches on the path
            for i := len(path) - 1; i >= 0; i-- {
                path[i].rwLatch.RUnlock()
            }
        }
    }
}

代码解析（Insert & findLeafForWrite & splitChild）：

1. 根节点处理：如果树为空，Insert会先获取rootChange的全局锁来创建并初始化根节点。
2. findLeafForWrite (Descent Phase)：
   • 从根节点开始，node.rwLatch.RLock()获取读锁。
   • 遍历时，先获取nextChild.rwLatch.RLock()。
   • “安全”判断：if len(nextChild.keys) < t.maxKeys()。如果子节点还有空间，那么即使它被写入，也不会导致分裂并影响当前父节点。此时，node.rwLatch.RUnlock()释放当前父节点的读锁。
   • “不安全”处理：如果子节点已满，则当前父节点是不安全的，因为子节点的分裂会影响父节点。此时，不释放父节点的读锁，并将其加入path切片，记录所有“不安全”的祖先节点。
   • 最终，findLeafForWrite返回时，目标叶节点及其所有“不安全”的祖先节点都持有读锁。
3. Latch升级与修改：
   • leaf.rwLatch.RUnlock()然后leaf.rwLatch.Lock()：这是从读锁到写锁的“升级”。在sync.RWMutex中，这并不是一个原子操作，而是先释放读锁，再尝试获取写锁。这个短暂的窗口是并发控制的难点，可能会有其他goroutine在此期间获取读锁。然而，由于我们已经通过crabbing确保了路径的稳定性，并且写操作是自下而上地进行，这种风险在很多实际场景中是可控的。更严谨的实现会引入重试机制或使用支持原子升级的Latch。
   • 在叶节点进行实际的键值插入。
4. splitChild (Split Propagation Phase)：
   • 如果叶节点已满，调用splitChild。splitChild处理节点的实际分裂，并将中间键提升到父节点。
   • 根节点分裂：如果被分裂的是根节点，需要获取rootChange全局锁来原子地更新t.root指针。
   • 内部节点分裂：如果父节点存在，父节点会先升级其Latch为写锁 (parent.rwLatch.RUnlock() -> parent.rwLatch.Lock())，然后插入被提升的键和新的子节点。
   • 递归分裂：如果父节点也因此变满，splitChild会递归调用自身，将分裂操作继续向上层传播。
   • Latch释放：无论是叶节点还是内部节点，在完成自身修改后，会立即释放其写锁。最后，所有在path中记录的祖先读锁也从上到下依次释放。

6. 并发删除操作：挑战与简化

删除操作比插入操作更为复杂，因为它可能导致节点下溢（underflow），需要从兄弟节点“借”键，或者与兄弟节点“合并”。这两种情况都可能影响到父节点，甚至导致父节点下溢并进一步传播。

删除的Latching策略：

1. Descent Phase (similar to Insert):
   • 使用与插入类似的写Latch Crabbing协议，从根节点向下遍历，找到目标叶节点。
   • 在findLeafForWrite中，判断节点是否“安全”的条件会稍有不同：一个节点在删除操作中是“安全”的，如果它有足够的键，即使删除一个键，也不会导致下溢（len(node.keys) > t.minKeys()）。如果节点不安全，则保留父节点的读锁。
2. Modification Phase:
   • 在叶节点获取写锁，执行删除。
   • 处理下溢：如果叶节点下溢，它需要从兄弟节点借键或与兄弟节点合并。这要求同时获取叶节点、其兄弟节点和父节点的写锁。这是最复杂的部分，需要严格的死锁避免策略（例如，总是先锁定左兄弟，再锁定右兄弟）。
   • 传播下溢：如果合并或借键操作导致父节点也下溢，则需要递归向上处理。
   • Latch释放：在完成修改后，自下而上释放所有写锁和读锁。

为了保持本文的重点和长度，我们不会提供完整的删除操作代码，因为它引入了兄弟节点查找、左右兄弟的锁顺序、合并/借键逻辑等额外复杂性。但其核心思想与插入类似：向下遍历获取读锁，识别“不安全”路径，在需要修改时，升级Latch为写锁，自下而上处理结构变化，并最终释放所有Latch。

7. 根节点Latch与全局树结构保护

前面在Search和Insert中，我们都使用了t.rootChange.Lock()来保护对t.root指针的访问。这是因为：

• 根节点分裂：当根节点满时，插入操作会导致根节点分裂，生成一个新的根节点，t.root指针需要更新。
• 根节点合并：当根节点只有一个子节点且该子节点下溢并与兄弟节点合并时，根节点可能会被移除，其唯一的子节点成为新的根，t.root指针需要更新。

t.rootChange是一个普通的sync.Mutex，它是一个全局的写锁。任何涉及修改t.root指针的操作（通常是根节点分裂或合并的末尾阶段）都需要获取这个锁。查找操作在读取t.root指针时也会短暂获取其读锁（这里用Lock()/Unlock()来模拟对指针的原子读取）。由于根节点的变化是相对罕见的事件，这种全局锁的开销通常是可以接受的。

8. 死锁预防、Latch粒度与Go语言特性

死锁预防：

• 统一的加锁顺序：这是预防死锁的关键。在B+树中，通常遵循从上到下（父节点到子节点）的加锁顺序。在我们的写Latch Crabbing中，如果需要同时持有父子节点的锁，我们总是先获取父节点的锁，再获取子节点的锁。
• Latch的粒度：
  • 树级Latch（Tree-level Latch）：整个B+树只有一个全局Latch。简单，但并发性极差。
  • 节点级Latch（Node-level Latch）：每个节点都有一个Latch。这是最常见的做法，如本文所示。提供了良好的并发性和合理的实现复杂度。
  • 键范围Latch（Key-range Latch）：更细粒度，但实现极其复杂，通常在高级数据库系统中才考虑。

Go语言sync.RWMutex的挑战：

• sync.RWMutex不提供原子性的“升级锁”操作（从RLock到Lock）。这意味着我们必须RUnlock()后Lock()。这个短暂的窗口可能会引入其他并发问题，例如：
  1. 在一个goroutine释放读锁后，另一个goroutine可能在此期间获取了写锁，导致第一个goroutine无法获取写锁，甚至死锁。
  2. 在释放读锁到获取写锁之间，节点内容可能已经被其他goroutine修改，导致之前基于读锁的判断失效。

在本文的splitChild中，我们通过parent.rwLatch.RUnlock()后parent.rwLatch.Lock()来模拟升级。在我们的crabbing协议中，由于我们持有了“不安全”路径上的读锁，并沿着路径自下而上进行写操作，且对根节点变化有全局锁保护，这种简单的RUnlock()/Lock()在一定程度上是安全的。然而，在生产级数据库中，通常会采用更复杂的策略，例如：

• 重试机制：如果升级失败或发现数据已变，重新从根节点开始操作。
• 专门的Latch类型：某些操作系统或库会提供支持原子升级的Latch。
• 乐观并发控制：不加锁进行遍历，只在修改时检查版本号，如果版本冲突则重试。

9. 总结：B+树并发控制的艺术

B+树的并发控制是数据库系统中最具挑战性但也是最核心的工程之一。通过引入轻量级的Latch机制，特别是Go语言中的sync.RWMutex，我们能够实现对B+树节点的高效并发访问。

Latch Crabbing协议允许在保证数据结构完整性的前提下，最大化并发读和写操作的性能。它要求开发者对树的结构、操作的原子性以及死锁预防有深刻的理解。虽然Go语言的sync.RWMutex在某些高级Latch协议（如原子升级）上有所限制，但通过精心设计的Crabbing策略，结合全局锁对根节点变化的保护，我们依然可以构建出高效且健壮的B+树并发控制方案。理解并掌握这些技术，是构建高性能数据存储系统不可或缺的一环。