記憶體悲觀鎖

作者：jiyf

原文來源：https://tidb.net/blog/b29eb6fd

背景

在 v6.0.0 版本，針對悲觀事務引入了記憶體悲觀鎖的優化（In-memory lock），從壓測資料來看，帶來的性能提升非常明顯（Sysbench 工具壓測 oltp_write_only 腳本）。

Tps 提升 30% 左右
減少 Latency 在 15% 左右

TiDB 事務模型從最初的樂觀事務到悲觀事務；在悲觀事務上，又針對悲觀鎖進行的 ”Pipelined 寫入“ 和 ”In-memory lock“ 優化，從功能特性上可以看出演進過程（參考TiDB 事務概覽）。

樂觀事務

樂觀事務在送出時，可能因為并發寫造成寫寫沖突，不同設定會出現以下兩種不同的現象：

關閉樂觀事務重試，事務送出失敗：也就是執行 DML 成功（不會被阻塞），但是在執行 commit 時候失敗，表現出與 MySQL 等資料庫不相容的行為。

T1	T2	說明
mysql> set session tidb_disable_txn_auto_retry = 1(或者 set session tidb_retry_limit=0;);Query OK, 0 rows affected (0.00 sec)	關閉重試
mysql> begin;Query OK, 0 rows affected (0.00 sec)	mysql> begin optimistic;Query OK, 0 rows affected (0.00 sec)	T2開啟樂觀事務
mysql> delete from t where id = 1;Query OK, 1 row affected (0.00 sec)
mysql> delete from t where id = 1;Query OK, 1 row affected (0.00 sec)	語句執行成功，沒有被 T1 阻塞，跟 MySQL 行為不相容
mysql> commit;Query OK, 0 rows affected (0.00 sec)	T1 送出成功
mysql> commit;ERROR 9007 (HY000): ......	T2 送出失敗

T2 事務送出失敗，具體的報錯資訊如下：

mysql> commit;
ERROR 9007 (HY000): Write conflict, txnStartTS=433599424403603460, conflictStartTS=433599425871872005, conflictCommitTS=433599429279744001, key={tableID=5623, handle=1} primary={tableID=5623, handle=1} [try again later]

開啟樂觀事務重試，自動重試後傳回成功，但是因為重試 DML 使用的事務 id(start_ts) 是重新擷取的，不是事務開始的事務 id(start_ts)，也就是說實際執行結果相當于同一個事務中讀和寫是使用不同的事務 id(start_ts)，執行結果可能跟預期不一緻。

T1	T2	說明
mysql> set session tidb_disable_txn_auto_retry = 0;Query OK, 0 rows affected (0.00 sec)	開啟重試
mysql> set session tidb_retry_limit = 10;Query OK, 0 rows affected (0.00 sec)	設定最大重試次數
mysql> begin;Query OK, 0 rows affected (0.00 sec)	mysql> begin optimistic;Query OK, 0 rows affected (0.00 sec)	T2開啟樂觀事務
mysql> delete from t where id = 1;Query OK, 1 row affected (0.01 sec)	T1 删除 id = 1的記錄
mysql> delete from t where id in (1, 2, 3); Query OK, 1 row affected (0.00 sec)	T2 沒有被 T1 阻塞，同樣删除了 id = 1 的記錄，affected rows 顯示為 1.
mysql> insert into t (name, age) values("lihua", 9), ("humei", 8); Query OK, 2 rows affected (0.00 sec)Records: 2 Duplicates: 0 Warnings: 0	T1 插入兩條記錄，由于自增 id，兩條新紀錄的 id 分别為 2 和 3.
mysql> commit;Query OK, 0 rows affected (0.00 sec)	T1 送出，表 t 中隻有 id 為 2 和 3 的記錄
mysql> commit;Query OK, 0 rows affected (0.01 sec)	T2 送出成功
mysql> select id, name, age from t;Empty set (0.01 sec)	mysql> select id, name, age from t;Empty set (0.01 sec)	表 t 中， id 為 2 和 3 的記錄也被删除。

這裡事務 T2 就涉及到樂觀事務重試情況下的兩個局限性：

T2 提示 affected rows 顯示為 1 行，删除的是僅有的 id = 1 的記錄，但是實際送出時候，删除的是 id 為 2 和 3 的兩條記錄，實際的 affected rows 是 2 行，參考部落格TiDB 新特性漫談：悲觀事務。
破壞可重複讀的隔離級别，參考下重試的局限性的說明，在使用重試時，要判斷好是否會影響業務的正确性。

悲觀事務

針對樂觀事務存在的問題，悲觀事務通過在執行 DML 過程中加悲觀鎖，來達到與傳統資料庫的行為：

并發執行 DML，對同一行資料進行更改，先執行者會加悲觀鎖，後執行者被鎖阻塞
讓寫沖突按順序執行，這樣可以避免樂觀事務在 commit 時遇到沖突後多次重試的問題，使得 commit 順利完成

悲觀事務寫入悲觀鎖，相對樂觀事務帶來以下開銷：

悲觀鎖寫入 TiKV，增加了 RPC 調用流程并同步等待悲觀鎖寫入成功，導緻 DML 時延增加
悲觀鎖資訊會通過 raft 寫入多個副本，給 TiKV raftstore、磁盤等帶來處理壓力

pipelined

針對悲觀鎖帶來的時延增加問題，在 TiKV 層增加了 pipelined 加鎖流程優化，優化前後邏輯對比：

優化前：滿足加鎖條件，等待 lock 資訊通過 raft 寫入多副本成功，通知 TiDB 加鎖成功
pipelined ：滿足加鎖條件，通知 TiDB 加鎖成功、異步 lock 資訊 raft 寫入多副本(兩者并發執行)

異步 lock 資訊 raft 寫入流程後，從使用者角度看，悲觀鎖流程的時延降低了；但是從 TiKV 負載的角度，并沒有節省開銷。

in-memory

pipelined 優化隻是減少了 DML 時延，lock 資訊跟優化前一樣需要經過 raft 寫入多個 region 副本，這個過程會給 raftstore、磁盤帶來負載壓力。

記憶體悲觀鎖針對 lock 資訊 raft 寫入多副本，做了更進一步優化，總結如下：

lock 資訊隻儲存在記憶體中，不用寫入磁盤
lock 資訊不用通過 raft 寫入多個副本，隻要存在于 region leader
lock 資訊寫記憶體，延遲相對于通過 raft 寫多副本，延遲極小

從優化邏輯上看，帶來的性能提升會有以下幾點：

減小 DML 時延
降低磁盤的使用帶寬
降低 raftstore CPU 消耗

實作原理

引用下記憶體悲觀鎖 RFC In-memory Pessimistic Locks 的介紹：

Here is the general idea:

Pessimistic locks are written into a region-level lock table.

Pessimistic locks are sent to other peers before a voluntary leader transfer.

Pessimistic locks in the source region are sent to the target region before a region merge.

On splitting a region, pessimistic locks are moved to the corresponding new regions.

Each region has limited space for in-memory pessimistic locks.

簡單了解就是為每個 region 單獨維護(隻在 leader peer 維護)一個記憶體 lock table，當出現 region 變動時候例如 Leader transfer、Region merge 會先将 lock table 中的悲觀鎖通過 raft 同步到其他節點，這個 lock table 有大小限制。

in-memory lock 跟非優化前相比，不會破壞資料一緻性，具體的實作細節挺複雜，但是可以簡單了解下：

in-memory 悲觀鎖正常存在 region leader lock table 情況下

對于讀寫 leader，跟普通悲觀鎖讀寫一緻
對于 follow read，基于 snapshot 讀，隻有 prewrite lock 會影響讀取結果，而 prewrite 的資料是會同步到 follower 的，是以仍然沒問題

in-memory 悲觀鎖丢失

對于 write 操作，事務送出 prewrite 階段會檢查版本沖突，有沖突會因為沖突送出失敗，沒沖突正常送出
對于 read 操作，同上面 follower read，悲觀鎖不會影響讀

鎖丢失

in-memory 悲觀鎖的設計初衷是在收益與付出之間做的權衡：

相對于樂觀事務，悲觀事務加鎖，讓寫沖突按順序執行，沖突場景下事務送出成功率更高。
相對于同步持久化的悲觀鎖，減少了 TiKV 負載的開銷，但是同時會有鎖丢失。

鎖丢失的原因：in-memory 悲觀鎖隻在 region leader 上維護，這裡的鎖丢失是指新的 region leader 沒有擷取到變更前 region 上的悲觀鎖資訊。原因主要是 TiKV 網絡隔離或者節點當機，畢竟對于 region 變更，正常會先通過 raft 将目前 region 的悲觀鎖同步給其他 region peer。感覺 in-memory 悲觀鎖比 pipelined 加鎖，當機後鎖丢失會更多。

鎖丢失的影響（參考Pipelined 加鎖流程）：

事務在 region leader 變更前上的鎖，無法阻塞修改相同資料的其他事務。如果業務邏輯依賴加鎖或等鎖機制，業務邏輯的正确性将受到影響。
有較低機率導緻事務送出失敗，但不會影響事務正确性。

在 pipelined 加鎖流程，同樣會有悲觀鎖失效的現象，因為異步寫入可能失敗，悲觀鎖沒有寫成功，但是卻通知了上鎖成功。

T1	T2	OS CLi
mysql> begin;Query OK, 0 rows affected (0.00 sec)	mysql> begin;Query OK, 0 rows affected (0.00 sec)
mysql> delete from t where id=1;Query OK, 1 row affected (0.00 sec)
mysql> delete from t where id=1;
......	kill -9 tikv
Query OK, 1 row affected (19.20 sec)
mysql> commit;Query OK, 0 rows affected (0.00 sec)
mysql> commit;ERROR 1105 (HY000)

事務 T1 送出失敗，詳細報錯資訊如下：

mysql> commit;
ERROR 1105 (HY000): tikv aborts txn: Error(Txn(Error(Mvcc(Error(PessimisticLockNotFound { start_ts: TimeStamp(433149465930498050), key: [116, 128, 0, 0, 0, 0, 0, 1, 202, 95, 114, 128, 0, 0, 0, 0, 0, 0, 1] })))))

這裡事務 T1 先加鎖成功，事務 T2 被阻塞，kill tikv 導緻 leader transfer，新的 leader 沒有事務 T1 的悲觀鎖資訊，然後事務 T2 被解除阻塞，并送出成功。事務 T1 送出失敗，但不會影響資料的一緻性。

是以如果業務中依賴這種加鎖機制，可能導緻業務正确性受影響。如下使用場景：

mysql> begin;
mysql> insert into tb values(...) 或者 select 1 from tb where id=1 for update;
...加鎖成功...
...業務依賴以上加鎖成功做業務選擇...
...在鎖丢失場景可能多個事務都能加鎖成功導緻出現不符合業務預期的行為...
mysql> commit;

如果對于成功率和事務過程中執行傳回結果有強需求或者依賴的業務，可選擇關閉記憶體鎖（以及 pipelined 寫入）模式。

開啟 in-memory

TiKV 配置檔案：

[pessimistic-txn]
pipelined = true
in-memory = true

隻有 pipelined 和 in-memory 同時打開才能開啟記憶體悲觀鎖。

可以線上動态開啟、關閉：

> set config tikv pessimistic-txn.pipelined='true';
> set config tikv pessimistic-txn.in-memory='true';

Grafana 檢視 in-memory lock 的寫入情況，在 {clusterName}-TiKV-Details->Pessimistic Locking 标簽下：

記憶體限制

每個 region 的 in-memory 鎖記憶體固定限制為 512 KiB，如果目前 region 悲觀鎖記憶體達到限制，新的悲觀鎖寫入将回退到 pipelined 加鎖流程（在典型 TP 場景下，很少會超過這個限制）。

mysql> begin;
Query OK, 0 rows affected (0.00 sec)

mysql> update sbtest1 set k=k+1 limit 10000000;
Query OK, 10000000 rows affected (3.26 sec)
Rows matched: 10000000  Changed: 10000000  Warnings: 0

由于大量悲觀鎖寫入，悲觀鎖記憶體達到限制值，監控中 full 值大量出現。

回退到 pipelined 寫入流程，通過 raft 寫入多副本，Rockdb 的 lock CF 出現 lock 資訊，在 {clusterName}-TiKV-Details->RocksDB - kv 标簽下。

性能測試

對樂觀鎖、悲觀鎖、pipelined 寫入、in-memory lock 進行壓力測試。

類型	cpu	記憶體	磁盤	網卡	NUMA	節點數	機器數
TiKV	96線程	384G	2 * 2.9T NVME	40000Mb/s	2 node	6	3

TiKV 部署：在每塊 NEME 盤上部署一個 TIKV 節點，分别綁定一個 NUMA node，單台機器 2 個 TiKV 節點，配置參數如下（變動的參數隻跟壓測的事務類型有關）。

server_configs:
  tikv:
    pessimistic-txn.in-memory: true
    pessimistic-txn.pipelined: true
    raftdb.max-background-jobs: 6
    raftstore.apply-pool-size: 6
    raftstore.store-pool-size: 6
    readpool.coprocessor.use-unified-pool: true
    readpool.storage.normal-concurrency: 16
    readpool.storage.use-unified-pool: true
    readpool.unified.max-thread-count: 38
    readpool.unified.min-thread-count: 5
    rocksdb.max-background-jobs: 8
    server.grpc-concurrency: 10
    storage.block-cache.capacity: 90G
    storage.scheduler-worker-pool-size: 12

TiDB、pd 獨立部署，均為高配置伺服器，其中 TiDB 節點足夠多，能使壓測性能瓶頸集中在 TiKV 上，使用 LVS DR 模式做負載均衡。

測試工具 sysbench，壓測腳本 oltp_write_only，64 張表，1000w 資料，直覺比較各種模式下性能差異。

壓測結果 TPS：

壓測結果 Latency:

從壓測結果上來看：

性能排行從高到底：in-memory > optimistic > pipelined > pessimistic
在壓測線程較小時，in-memory 和 optimistic 性能接近，等到并發增大，可能是 optimistic 事務沖突重試的原因導緻 in-memory 後來居上
随着并發數增大，TiKV 磁盤 iops、帶寬很快增長，pessimistic 和 pipelined 磁盤負載較早出現壓力，後面時延增加較快，對應 TPS 增長相對緩慢
當接近 TiKV 磁盤性能瓶頸時，in-memory 和 optimistic 能支撐叢集更大的 TPS。

悲觀鎖優化

對比下 in-memory、pipelined 兩個特性，對于悲觀鎖的性能提升。

TPS 提升：

in-memory 提升明顯，始終維持在一個較高值 35% 以上

同并發下 Latency 減少，對應 TPS 增長
高并發下，減少磁盤 io 壓力、減少了 raftstore 壓力

pipelined 提升在 10% 左右，在較小并發時異步寫入 Latency 減少，支撐了較大的 TPS 提升；當磁盤壓力增大，慢慢出現性能瓶頸，提升越來越小。

減少 Latency：

在并發小時，時延提升明顯，分别能到到 20%、10% 的提升。
在并發增大後，磁盤出現較大壓力，由于時延增加太大，總提升越來越不明顯

in-memory 維持在 10% 以上
pipelined 降到 5% 以下

總結

從壓測資料來看，v6.0.0 版本的記憶體悲觀鎖是非常有吸引力的新特性。

通過減少 DML 時延、避免悲觀鎖 raft 寫入多副本、減少 raftstore 處理壓力以及磁盤帶寬，能達到可觀的寫入性能提升：

Tps 提升 30% 上下
減少 Latency 在 15% 上下

在記憶體悲觀鎖的使用中，要注意鎖丢失問題，如果影響業務的正确性邏輯，應關閉 in-memory lock 與 pipelined 寫入這兩個悲觀事務特性。

參考

官方文檔：記憶體悲觀鎖

記憶體悲觀鎖

作者：jiyf

背景

樂觀事務

悲觀事務

pipelined

in-memory

實作原理

鎖丢失

開啟 in-memory

記憶體限制

性能測試

悲觀鎖優化

總結

參考

繼續閱讀

2022秋招面試總結（cpp+java+測開）百度測開一面位元組後端一面蝦皮後端一面蝦皮後端二面

資料庫之DDL操作資料庫DDL操作資料庫DDL操作資料表

資料庫之DQL操作資料庫

mysql優化（sql優化）

資料遷移方法資料遷移原則資料遷移之雙寫方案資料遷移之級聯同步方案

redis叢集資料一緻性_RedisRaft為Redis叢集帶來強大的資料一緻性

寶塔面闆mysql恢複2018.1.8更新

Centos7 MySQL 5.7 安裝MySQL 5.7 安裝

查找入職員工時間排名倒數第三的員工所有資訊

Hibernate使用Hibernate的“3個準備，7個步驟”Hibernate API簡介操作實體對象對象識别

雲計算面試題——mysql/存儲引擎/備份

SQL語言基礎：常用的資料查詢語句

Ubuntu16.04安裝Apache+MySQL+PHP1. 安裝Apache2. 安裝MySQL3. 安裝PHP4. 安裝phpMyAdmin

MySQL的4種隔離級别？出現問題

neo4j之cypher使用文檔

mysql使用source指令導入.sql檔案