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