參考
兩段鎖協議是指每個事務的執行分為兩個階段：生長階段（加鎖階段）和衰退階段（解鎖階段）。
加鎖階段：在該階段可以進行加鎖操作。在對任何資料進行讀操作之前要申請並獲得s鎖，在進行寫操作之前要申請並獲得x鎖。加鎖不成功，則事務進入等待狀態，直到加鎖成功才繼續執行。
解鎖階段：當事務釋放了乙個封鎖以後，事務進入解鎖階段，在該階段只能進行解鎖操作不能再進行加鎖操作。
兩段封鎖法可以這樣來實現：事務開始後就處於加鎖階段，一直到執行rollback和commit之前都是加鎖階段。rollback和commit使事務進入解鎖階段，即在rollback和commit模組中dbms釋放所有封鎖 。
簡單來說就是解鎖之後不能再加鎖 。
加鎖時機
當對記錄進行更新操作或者select for update(x鎖)、lock in share mode(s鎖)時，會對記錄進行加鎖。
解鎖時機
commit或者rollback時。
這道題來自牛客網，根據上面的解釋，很顯然t1是遵守兩階段封鎖協議。
下面舉個具體的例子，來講述二段鎖對應用效能的影響，我們舉個庫存扣減的例子：
方案一：
start transaction;
// 鎖定使用者賬戶表
select * from t_accout where acount_id=234 for update
//生成訂單
insert into t_trans;
// 減庫存
update t_inventory set num=num-3 where id=$ and num>=3;
commit;
方案二：
start transaction;
// 減庫存
update t_inventory set num=num-3 where id=$ and num>=3;
// 鎖定使用者賬戶表
select * from t_accout where acount_id=234 for update
//生成訂單
insert into t_trans;
commit;
由於商品庫存往往是最致命的熱點，是整個服務的熱點。如果採用第一種方案的話，tps理論上可以提公升3rt/rt=3倍。而這是在乙個事務中只有3條sql的情況，理論上多一條sql就多乙個rt時間。
另外，當更新操作到達資料庫的那個點，才算加鎖成功。commit到達資料庫的時候才算解鎖成功。所以，更新操作的前半個rt和commit操作的後半個rt都不計算在整個鎖庫存的時間內。
從上面的例子可以看出，在乙個事務操作中，將對最熱點記錄的操作放到事務的最後面，這樣可以顯著地提高服務的吞吐量。
我們可以將一些簡單的判斷邏輯寫到update操作的謂詞裡面，這樣可以減少加鎖的時間，如下：
方案一：
start transaction
num = select count from t_inventory where id=234 for update
if count >= 3:
update t_inventory set num=num-3 where id=234
commit
else:
rollback
方案二：
start transaction:
int affectedrows = update t_inventory set num=num-3 where id=234 and num>=3
if affectedrows > 0:
commit
else:
rollback
從上圖可以看出，加了update謂詞以後，乙個事務少了1rt的鎖記錄時間（update謂詞和select for update對記錄加的都是x鎖，所以效果是一樣的）。
兩階段封鎖協議
對鎖機制，保證事務可序列性的最常用協議是兩階段封鎖協議。該協議要求每個事務分兩個階段提出加鎖和解鎖申請 1 增長階段。事務可以獲得鎖，但不能釋放鎖。2 縮減階段。事務可以釋放鎖，但不能獲得鎖。一開始，事務處於增長階段，事務根據需要獲得鎖。一旦該事務釋放了鎖，它就進入縮減階段，不能再發出加鎖請求。兩階...
兩階段提交協議
閱讀次數 142次 類別 我的文章 永久鏈結 trackback 實現分布式事務的關鍵就是兩階段提交協議。在此協議中，乙個或多個資源管理器的活動均由乙個稱為事務協調器的單獨軟體元件來控制。實現分布式事務的關鍵就是兩階段提交協議。在此協議中，乙個或多個資源管理器的活動均由乙個稱為事務協調器的單獨軟體元...
兩階段提交協議
兩階段提交協議 實現分布式事務的關鍵就是兩階段提交協議。在此協議中，乙個或多個資源管理器的活動均由乙個稱為事務協調器的單獨軟體元件來控制。此協議中的五個步驟如下 應用程式呼叫事務協調器中的提交方法。事務協調器將聯絡事務中涉及的每個資源管理器，並通知它們準備提交事務 這是第一階段的開始 為 了以肯定的...