RocksDB作為一個開源的存儲引擎支持事務(wù)的ACID特性，而要支持ACID中的I(Isolation),并發(fā)控制這塊是少不了的，本文主要討論RocksDB的鎖機(jī)制實現(xiàn)，細(xì)節(jié)會涉及到源碼分析，希望通過本文讀者可以深入了解RocksDB并發(fā)控制原理。文章主要從以下4方面展開，首先會介紹RocksDB鎖的基本結(jié)構(gòu)，然后我會介紹RocksDB行鎖數(shù)據(jù)結(jié)構(gòu)設(shè)計下，鎖空間開銷，接著我會介紹幾種典型場景的上鎖流程，最后會介紹鎖機(jī)制中必不可少的死鎖檢測機(jī)制。
1.行鎖數(shù)據(jù)結(jié)構(gòu)
RocksDB鎖粒度最小是行，對于KV存儲而言，鎖對象就是key，每一個key對應(yīng)一個LockInfo結(jié)構(gòu)。所有key通過hash表管理，查找鎖時，直接通過hash表定位即可確定這個key是否已經(jīng)被上鎖。但如果全局只有一個hash表，會導(dǎo)致這個訪問這個hash表的沖突很多，影響并發(fā)性能。RocksDB首先按Columnfamily進(jìn)行拆分，每個Columnfamily中的鎖通過一個LockMap管理，而每個LockMap再拆分成若干個分片，每個分片通過LockMapStripe管理，而hash表(std::unordered_map<std::string, LockInfo>)則存在于Stripe結(jié)構(gòu)中，Stripe結(jié)構(gòu)中還包含一個mutex和condition_variable，這個主要作用是，互斥訪問hash表，當(dāng)出現(xiàn)鎖沖突時，將線程掛起，解鎖后，喚醒掛起的線程。這種設(shè)計很簡單但也帶來一個顯而易見的問題，就是多個不相關(guān)的鎖公用一個condition_variable，導(dǎo)致鎖釋放時，不必要的喚醒一批線程，而這些線程重試后，發(fā)現(xiàn)仍然需要等待，造成了無效的上下文切換。對比我們之前討論的InnoDB鎖機(jī)制，我們發(fā)現(xiàn)InnoDB是一個page里面的記錄復(fù)用一把鎖，而且復(fù)用是有條件的，同一個事務(wù)對一個page的若干條記錄加鎖才能復(fù)用；而且鎖等待隊列是精確等待，精確到記錄級別，不會導(dǎo)致的無效的喚醒。雖然RocksDB鎖設(shè)計比較粗糙，但也做了一定的優(yōu)化，比如在管理LockMaps時，通過在每個線程本地緩存一份拷貝lock_maps_cache_，通過全局鏈表將每個線程的cache鏈起來，當(dāng)LockMaps變更時(刪除columnfamily)，則全局將每個線程的copy清空，由于columnfamily改動很少，所以大部分訪問LockMaps操作都是不需要加鎖的，提高了并發(fā)效率。
相關(guān)數(shù)據(jù)結(jié)構(gòu)如下：
