RocksDB上鎖機制

      RocksDB做爲一個開源的存儲引擎支持事務的ACID特性，而要支持ACID中的I(Isolation),併發控制這塊是少不了的，本文主要討論RocksDB的鎖機制實現，細節會涉及到源碼分析，但願經過本文讀者能夠深刻了解RocksDB併發控制原理。文章主要從如下4方面展開，首先會介紹RocksDB鎖的基本結構，而後我會介紹RocksDB行鎖數據結構設計下，鎖空間開銷，接着我會介紹幾種典型場景的上鎖流程，最後會介紹鎖機制中必不可少的死鎖檢測機制。

1.行鎖數據結構
    RocksDB鎖粒度最小是行，對於KV存儲而言，鎖對象就是key，每個key對應一個LockInfo結構。全部key經過hash表管理，查找鎖時，直接經過hash表定位便可肯定這個key是否已經被上鎖。但若是全局只有一個hash表，會致使這個訪問這個hash表的衝突不少，影響併發性能。RocksDB首先按Columnfamily進行拆分，每一個Columnfamily中的鎖經過一個LockMap管理，而每一個LockMap再拆分紅若干個分片，每一個分片經過LockMapStripe管理，而hash表(std::unordered_map<std::string, LockInfo>)則存在於Stripe結構中，Stripe結構中還包含一個mutex和condition_variable，這個主要做用是，互斥訪問hash表，當出現鎖衝突時，將線程掛起，解鎖後，喚醒掛起的線程。這種設計很簡單但也帶來一個顯而易見的問題，就是多個不相關的鎖公用一個condition_variable，致使鎖釋放時，沒必要要的喚醒一批線程，而這些線程重試後，發現仍然須要等待，形成了無效的上下文切換。對比咱們以前討論的InnoDB鎖機制，咱們發現InnoDB是一個page裏面的記錄複用一把鎖，並且複用是有條件的，同一個事務對一個page的若干條記錄加鎖才能複用；並且鎖等待隊列是精確等待，精確到記錄級別，不會致使的無效的喚醒。雖然RocksDB鎖設計比較粗糙，但也作了必定的優化，好比在管理LockMaps時，經過在每一個線程本地緩存一份拷貝lock_maps_cache_，經過全局鏈表將每一個線程的cache鏈起來，當LockMaps變動時(刪除columnfamily)，則全局將每一個線程的copy清空，因爲columnfamily改動不多，因此大部分訪問LockMaps操做都是不須要加鎖的，提升了併發效率。
相關數據結構以下：

struct LockInfo {
bool exclusive; //排它鎖或是共享鎖
autovector<TransactionID> txn_ids; //事務列表，對於共享鎖而言，同一個key能夠對應多個事務

// Transaction locks are not valid after this time in us
uint64_t expiration_time;
}

struct LockMapStripe { 
// Mutex must be held before modifying keys map
std::shared_ptr<TransactionDBMutex> stripe_mutex;

// Condition Variable per stripe for waiting on a lock
std::shared_ptr<TransactionDBCondVar> stripe_cv;

// Locked keys mapped to the info about the transactions that locked them.
std::unordered_map<std::string, LockInfo> keys;
}

struct LockMap {
const size_t num_stripes_; //分片個數
std::atomic<int64_t> lock_cnt{0}; //鎖數目
std::vector<LockMapStripe*> lock_map_stripes_; //鎖分片
}

class TransactionLockMgr {
using LockMaps = std::unordered_map<uint32_t, std::shared_ptr<LockMap>>;
LockMaps lock_maps_;

// Thread-local cache of entries in lock_maps_. This is an optimization
// to avoid acquiring a mutex in order to look up a LockMap
std::unique_ptr<ThreadLocalPtr> lock_maps_cache_;
}

2.行鎖空間代價
    因爲鎖信息是常駐內存，咱們簡單分析下RocksDB鎖佔用的內存。每一個鎖其實是unordered_map中的一個元素，則鎖佔用的內存爲key_length+8+8+1，假設key爲bigint，佔8個字節，則100w行記錄，須要消耗大約22M內存。可是因爲內存與key_length正相關，致使RocksDB的內存消耗不可控。咱們能夠簡單算算RocksDB做爲MySQL存儲引擎時，key_length的範圍。對於單列索引，最大值爲2048個字節，具體能夠參考max_supported_key_part_length實現；對於複合索引，索引最大長度爲3072個字節，具體能夠參考max_supported_key_length實現。假設最壞的狀況，key_length=3072，則100w行記錄，須要消耗3G內存，若是是鎖1億行記錄，則須要消耗300G內存，這種狀況下內存會有撐爆的風險。所以RocksDB提供參數配置max_row_locks，確保內存可控，默認RDB_MAX_ROW_LOCKS設置爲1G，對於大部分key爲bigint場景，極端狀況下，也須要消耗22G內存。而在這方面，InnoDB則比較友好，hash表的key是(space_id, page_no)，因此不管key有多大，key部分的內存消耗都是恆定的。前面我也提到了InnoDB在一個事務須要鎖大量記錄場景下是有優化的，多個記錄能夠公用一把鎖，這樣也間接能夠減小內存。

3.上鎖流程分析
    前面簡單瞭解了RocksDB鎖數據結構的設計以及鎖對內存資源的消耗。這節主要介紹幾種典型場景下，RocksDB是如何加鎖的。與InnoDB同樣，RocksDB也支持MVCC，讀不上鎖，爲了方便，下面的討論基於RocksDB做爲MySQL的一個引擎來展開，主要包括三類，基於主鍵的更新，基於二級索引的更新，基於主鍵的範圍更新等。在展開討論以前，有一點須要說明的是，RocksDB與InnoDB不一樣，RocksDB的更新也是基於快照的，而InnoDB的更新基於當前讀，這種差別也使得在實際應用中，相同隔離級別下，表現有所不同。對於RocksDB而言，在RC隔離級別下，每一個語句開始都會從新獲取一次快照；在RR隔離級別下，整個事務中只在第一個語句開始時獲取一次快照，全部語句共用這個快照，直到事務結束。

3.1.基於主鍵的更新
這裏主要接口是TransactionBaseImpl::GetForUpdate
1).嘗試對key加鎖，若是鎖被其它事務持有，則須要等待
2).建立snapshot
3).調用ValidateSnapshot，Get key,經過比較Sequence判斷key是否被更新過
4).因爲是加鎖後，再獲取snapshot，因此檢查必定成功。
5).執行更新操做
這裏有一個延遲獲取快照的機制，實際上在語句開始時，須要調用acquire_snapshot獲取快照，但爲了不衝突致使的重試，在對key加鎖後，再獲取snapshot，這就保證了在基於主鍵更新的場景下，不會存在ValidateSnapshot失敗的場景。

堆棧以下：

1-myrocks::ha_rocksdb::get_row_by_rowid
2-myrocks::ha_rocksdb::get_for_update
3-myrocks::Rdb_transaction_impl::get_for_update
4-rocksdb::TransactionBaseImpl::GetForUpdate
{
//加鎖
5-rocksdb::TransactionImpl::TryLock
  6-rocksdb::TransactionDBImpl::TryLock
    7-rocksdb::TransactionLockMgr::TryLock 

 //延遲獲取快照，與acquire_snapshot配合使用
 6-SetSnapshotIfNeeded()

 //檢查key對應快照是否過時
 6-ValidateSnapshot
  7-rocksdb::TransactionUtil::CheckKeyForConflict
    8-rocksdb::TransactionUtil::CheckKey
      9-rocksdb::DBImpl::GetLatestSequenceForKey //第一次讀取

//讀取key
5-rocksdb::TransactionBaseImpl::Get
  6-rocksdb::WriteBatchWithIndex::GetFromBatchAndDB
    7-rocksdb::DB::Get
      8-rocksdb::DBImpl::Get
        9-rocksdb::DBImpl::GetImpl //第二次讀取
}

3.2.基於主鍵的範圍更新
1).建立Snapshot，基於迭代器掃描主鍵
2).經過get_row_by_rowid，嘗試對key加鎖
3).調用ValidateSnapshot，Get key,經過比較Sequence判斷key是否被更新過
4).若是key被其它事務更新過(key對應的SequenceNumber比Snapshot要新)，觸發重試
5).重試狀況下，會釋放老的快照並釋放鎖，經過tx->acquire_snapshot(false)，延遲獲取快照(加鎖後，再拿snapshot)
5).再次調用get_for_update，因爲此時key已經被加鎖，重試必定能夠成功。
6).執行更新操做
7).跳轉到1，繼續執行，直到主鍵不符合條件時，則結束。

3.3.基於二級索引的更新
這種場景與3.2相似，只不過多一步從二級索引定位主鍵過程。
1).建立Snapshot，基於迭代器掃描二級索引
2).根據二級索引反向找到主鍵，實際上也是調用get_row_by_rowid，這個過程就會嘗試對key加鎖
3).繼續根據二級索引遍歷下一個主鍵，嘗試加鎖
4).當返回的二級索引不符合條件時，則結束

3.4 與InnoDB加鎖的區別
      前面咱們說到了RocksDB與InnoDB的一點區別是，對於更新場景，RocksDB仍然是快照讀，而InnoDB是當前讀，致使行爲上的差別。好比在RC隔離級別下的範圍更新場景，好比一個事務要更新1000條記錄，因爲是邊掃描邊加鎖，可能在掃描到第999條記錄時，發現這個key的Sequence大於掃描的快照(這個key被其它事務更新了)，這個時候會觸發從新獲取快照，而後基於這個快照拿到最新的key值。InnoDB則沒有這個問題，經過當前讀，掃描過程當中，若是第999條記錄被更新了，InnoDB能夠直接看到最新的記錄。這種狀況下，RocksDB和InnoDB看到的結果是同樣的。在另一種狀況下，假設也是掃描的範圍中，新插入了key，這key的Sequence毫無疑問會比掃描的Snapshot要大，所以在Scan過程當中這個key會被過濾掉，也就不存在所謂的衝突檢測了，這個key不會被找到。更新過程當中，插入了id爲1和900的兩條記錄，最後第900條記錄因爲不可見，因此更新不到。而對於InnoDB而言，因爲是當前讀，新插入的id爲900的記錄能夠被看到並更新，因此這裏是與InnoDB有區別的地方。
      除了更新基於快照這個區別之外，RocksDB在加鎖上也更簡潔，全部加鎖只涉及惟一索引，具體而言，在更新過程當中，只對主鍵加鎖；更新列涉及惟一約束時，須要加鎖；而普通二級索引，則不用加鎖，這個目的是爲了不惟一約束衝突。這裏面，若是更新了惟一約束(主鍵，或者惟一索引)，都須要加鎖。而InnoDB則是須要對每一個索引加鎖，好比基於二級索引定位更新，則二級索引也須要加鎖。之因此有這個區別是，是由於InnoDB爲了實現RR隔離級別。這裏稍微講下隔離級別，實際上MySQL中定義的RR隔離級別與SQL標準定義的隔離級別有點不同。SQL標準定義RR隔離級別解決不可重複讀的問題，Serializable隔離級別解決幻讀問題。不可重複讀側重講同一條記錄值不會修改；而幻讀則側重講兩次讀返回的記錄條數是固定的，不會增長或減小記錄數目。MySQL定義RR隔離級別同時解決了不可重複讀和幻讀問題，而InnoDB中RR隔離級別的實現就是依賴於GAP鎖。而RocksDB不支持GAP鎖(僅僅支持惟一約束檢查，對不存在的key加鎖)，由於基於快照的機制能夠有效過濾掉新插入的記錄，而InnoDB因爲當前讀，致使須要經過間隙鎖禁止其它插入，因此二級索引也須要加鎖，主要是爲了鎖間隙，不然兩次當前讀的結果可能不同。固然，對RC割裂級別，InnoDB普通二級索引也是沒有必要加鎖的。

4.死鎖檢測算法
      死鎖檢測採用BFS((Breadth First Search,寬度優先算法)，基本思路根據加入等待關係，繼續查找被等待者的等待關係，若是發現成環，則認爲發生了死鎖。須要說明的是InnoDB的死鎖檢測採用的DFS(Deepth First Search，深度優先算法)，邏輯都是相似的，目的是爲了找環。自己BFS和DFS兩種圖搜索算法時間複雜度也相同O(V+E)，V和E分別表示節點數目和邊的數目。主要實現區別在於，BFS通常與隊列配合使用，先進先出；DFS通常與棧配合使用，先進後出。固然在大併發系統下，鎖等待關係很是複雜，爲了將死鎖檢測帶來的資源消耗控制在必定範圍，能夠經過設置deadlock_detect_depth來控制死鎖檢測搜索的深度，或者在特定業務場景下，認爲必定不會發生死鎖，則關閉死鎖檢測，這樣在必定程度上有利於系統併發的提高。須要說明的是，若是關閉死鎖，最好配套將鎖等待超時時間設置較小，避免系統真發生死鎖時，事務長時間hang住。死鎖檢測基本流程以下：

1.定位到具體某個分片，獲取mutex
2.調用AcquireLocked嘗試加鎖
3.若上鎖失敗，則觸發進行死鎖檢測
4.調用IncrementWaiters增長一個等待者
5.若是等待者不在被等待者map裏面，則確定不會存在死鎖，返回
6.對於被等待者，沿着wait_txn_map_向下檢查等待關係(一次加入全部等待的事務列表，而後逐個分析)，看看是否成環
7.若發現成環，則將調用DecrementWaitersImpl將新加入的等待關係解除，並報死鎖錯誤。

相關的數據結構：

class TransactionLockMgr {
// Must be held when modifying wait_txn_map_ and rev_wait_txn_map_.
std::mutex wait_txn_map_mutex_;

// Maps from waitee -> number of waiters.
HashMap<TransactionID, int> rev_wait_txn_map_;

// Maps from waiter -> waitee.
HashMap<TransactionID, autovector<TransactionID>> wait_txn_map_;

DecrementWaiters //

IncrementWaiters //
}

struct TransactionOptions {
bool deadlock_detect = false; //是否檢測死鎖
int64_t deadlock_detect_depth = 50; //死鎖檢測的深度
int64_t lock_timeout = -1; //等待鎖時間，線上通常設置爲5s
int64_t expiration = -1; //持有鎖時間，
}

參考文檔
https://github.com/mdcallag/mytools/wiki/Cursor-Isolation
https://www.postgresql.org/docs/9.4/static/transaction-iso.html
https://github.com/facebook/mysql-5.6/issues/340
http://www.cnblogs.com/digdeep/p/4947694.html
http://www.cnblogs.com/digdeep/archive/2015/11/16/4968453.html