成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

MySQL的兩階段加鎖協議

數據庫 MySQL
MySql本身針對性能,還有一個MVCC(多版本控制)控制,本文不考慮此種技術,僅僅考慮MySql本身的加鎖協議。什么時候會加鎖在對記錄更新操作或者(select for update、lock in share model)時,會對記錄加鎖(有共享鎖、排它鎖、意向鎖、gap鎖、nextkey鎖等等),本文為了簡單考慮,不考慮鎖的種類。

#MySql-兩階段加鎖協議 ##前言此篇博客主要是講述MySql(僅限innodb)的兩階段加鎖(2PL)協議,而非兩階段提交(2PC)協議,區別如下:

  • 2PL,兩階段加鎖協議:主要用于單機事務中的一致性與隔離性。
  • 2PC,兩階段提交協議:主要用于分布式事務。

MySql本身針對性能,還有一個MVCC(多版本控制)控制,本文不考慮此種技術,僅僅考慮MySql本身的加鎖協議。 ##什么時候會加鎖在對記錄更新操作或者(select for update、lock in share model)時,會對記錄加鎖(有共享鎖、排它鎖、意向鎖、gap鎖、nextkey鎖等等),本文為了簡單考慮,不考慮鎖的種類。 ##什么是兩階段加鎖在一個事務里面,分為加鎖(lock)階段和解鎖(unlock)階段,也即所有的lock操作都在unlock操作之前,如下圖所示:

 

##為什么需要兩階段加鎖

引入2PL是為了保證事務的隔離性,即多個事務在并發的情況下等同于串行的執行。 在數學上證明了如下的封鎖定理:

如果事務是良構的且是兩階段的,那么任何一個合法的調度都是隔離的。

具體的數學推到過程可以參照<<事務處理:概念與技術>>這本書的7.5.8.2節.

此書乃是關于數據庫事務的圣經,無需解釋(中文翻譯雖然晦澀,也能堅持讀下去,強烈推薦)

##工程實踐中的兩階段加鎖-S2PL 在實際情況下,SQL是千變萬化、條數不定的,數據庫很難在事務中判定什么是加鎖階段,什么是解鎖階段。于是引入了S2PL(Strict-2PL),即:

在事務中只有提交(commit)或者回滾(rollback)時才是解鎖階段,

其余時間為加鎖階段。

如下圖所示:

 

這樣的話,在實際的數據庫中就很容易實現了。 ##兩階段加鎖對性能的影響

上面很好的解釋了兩階段加鎖,現在我們分析下其對性能的影響。考慮下面兩種不同的扣減庫存的方案:

方案1:

  1. begin
  2. // 扣減庫存 
  3. update t_inventory set count=count-5 where id=${id} and count >= 5; 
  4. // 鎖住用戶賬戶表 
  5. select * from t_user_account where user_id=123 for update
  6. // 插入訂單記錄 
  7. insert into t_trans; 
  8. commit 

方案2:

  1. begin
  2.  
  3. // 鎖住用戶賬戶表 
  4.  
  5. select * from t_user_account where user_id=123 for update
  6.  
  7. // 插入訂單記錄 
  8.  
  9. insert into t_trans; 
  10.  
  11. // 扣減庫存 
  12.  
  13. update t_inventory set count=count-5 where id=${id} and count >= 5; 
  14.  
  15. commit 

由于在同一個事務之內,這幾條對數據庫的操作應該是等價的。但在兩階段加鎖下的性能確是有比較大的差距。兩者方案的時序如下圖所示:

 

由于庫存往往是最重要的熱點,是整個系統的瓶頸。那么如果采用第二種方案的話,

tps應該理論上能夠提升3rt/rt=3倍。這還僅僅是業務就只有三條SQL的情況下,

多一條sql就多一次rt,就多一倍的時間。

值得注意的是:

在更新到數據庫的那個時間點才算鎖成功

提交到數據庫的時候才算解鎖成功

這兩個round_trip的前半段是不會計算在內的

如下圖所示:

 

當前只考慮網絡時延,不考慮數據庫和應用本身的時間消耗。 ##依據S2PL的性能優化

從上面的例子中,可以看出,需要把最熱點的記錄,

放到事務***,這樣可以顯著的提高吞吐量。更進一步:

越熱點記錄離事務的終點越近(無論是commit還是rollback)

筆者認為,先后順序如下圖:

 

###避免死鎖這也是任何SQL加鎖不可避免的。上文提到了按照記錄Key的熱度在事務中倒序排列。那么寫代碼的時候任何可能并發的SQL都必須按照這種順序來處理,不然會造成死鎖。如下圖所示: 

 

 

###select for update和update where 謂詞計算我們可以直接將一些簡單的判斷邏輯寫到update的謂詞里面,以減少加鎖時間,考慮下面兩種方案:

方案1:

  1. begin
  2.  int count = select count from t_inventory for update
  3.  if count >= 5: 
  4.     update t_inventory set count=count-5 where id =123 
  5.     commit  
  6.  else 
  7.     rollback  

方案2:

  1. begin
  2.     int rows = update t_inventory set count=count-5 where id =123 and count >=5 
  3.     if rows > 0: 
  4.         commit
  5.     ele  
  6.         rollback 

時延如下圖所示: 

 

可以看到,通過在update中加謂詞計算,少了1rt的時間。

由于update在執行過程中對符合謂詞條件的記錄加的是和select for update一致的排它鎖

(具體的鎖類型較為復雜,不在這里描述),所以兩者效果一樣。

#總結 MySql采用兩階段加鎖協議實現隔離性和一致性,我們只有深入的去理解這種協議,才能更好的對我們的SQL進行優化,增加系統的吞吐量。 

責任編輯:龐桂玉 來源: 無毀的湖光-Al的博客
相關推薦

2022-03-28 10:44:51

MySQL日志存儲

2024-05-21 14:12:07

2024-12-06 07:10:00

2025-06-10 08:02:15

2021-10-12 19:12:15

單步實現系統

2018-10-29 08:44:29

分布式兩階段提交事務

2023-11-29 07:47:58

DDIA兩階段提交

2010-07-02 12:26:51

LEACH協議

2023-07-26 09:24:03

分布式事務分布式系統

2023-01-18 10:35:49

MySQL數據庫

2009-12-29 10:43:31

PPPOE協議

2020-02-03 12:12:28

MySQL數據庫SQL

2022-12-21 19:04:35

InnoDBMySQL

2025-06-19 08:03:03

2023-12-05 09:33:08

分布式事務

2024-01-26 08:18:03

2025-05-16 07:46:11

分布式事務服務

2023-01-17 09:38:17

模型訓練

2024-03-26 16:24:46

分布式事務2PC3PC

2024-07-22 08:57:58

點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板: 精品伊人 | 日韩精品无码一区二区三区 | 伊人狠狠干 | 一区二区三区免费看 | 国产精品久久久久久久久久久久冷 | 亚洲国产欧美在线人成 | 久久免费视频观看 | 欧洲精品码一区二区三区免费看 | 久久九精品 | 涩涩导航| 国产精品一区二区三级 | 亚洲视频精品在线 | 中文字幕精品一区 | 欧美日韩一区二区三区视频 | 国产一级毛片精品完整视频版 | 成人在线视频免费看 | 99热精品6| 男女在线网站 | 国产一区二区精品自拍 | com.色.www在线观看 | 久久精品网 | 国产福利在线播放麻豆 | 日韩视频观看 | 成人av免费在线观看 | 亚洲伊人久久综合 | 欧美福利一区 | 91久久国产精品 | 日日爽| 精品一区二区三区在线观看 | 91亚洲精华国产 | 男女激情网| 国产综合精品 | 欧美性猛片aaaaaaa做受 | 亚洲永久精品国产 | 亚洲第一区国产精品 | 国产精品永久免费视频 | 日韩一区二区在线观看视频 | 亚洲国产二区 | 成年人免费网站 | 国产不卡一区在线观看 | 国产午夜精品理论片a大结局 |