事務管理 vs. 鎖控制：你真的分得清嗎？
分布式鎖和事務是分布式系統中兩個重要的概念，它們都用于解決分布式環境下的數據一致性問題。
一、概念
分布式鎖
分布式鎖是一種用于在分布式環境中控制對共享資源訪問的鎖。分布式鎖可以防止多個進程或線程同時訪問共享資源，從而避免數據沖突和資源競爭。
事務
事務是指一組操作要么全部執行，要么全部不執行，以保證數據的一致性。事務通常用于處理多個數據源之間的操作，例如對于跨多個數據庫的事務操作，需要保證在執行過程中的原子性、一致性和持久性。
區別
區別 | 分布式鎖 | 事務 |
作用 | 控制對共享資源的訪問 | 保證數據的一致性 |
范圍 | 單個資源 | 多個資源 |
粒度 | 細粒度 | 粗粒度 |
實現 | 基于數據庫、基于消息隊列、基于共享內存等 | 基于 ACID 原理 |
優缺點 | 優點：簡單易用、性能高；缺點：無法保證數據一致性 | 優點：保證數據一致性；缺點：實現復雜、性能低 |
使用場景 | 搶購、秒殺、數據同步等 | 銀行轉賬、訂單支付等 |
本質區別 | 分布式鎖是針對資源訪問的 | 事務是針對數據一致性的 |
二、使用場景
分布式鎖
分布式鎖通常用于以下場景：
- 搶購、秒殺：在搶購、秒殺等場景中，需要防止多個用戶同時下單，從而保證公平性。
- 數據同步：在數據同步場景中，需要防止多個服務器同時更新數據，從而保證數據的一致性。
- 資源訪問控制：在資源訪問控制場景中，需要防止多個用戶同時訪問共享資源，從而保證資源的安全性。
事務
事務通常用于以下場景：
- 銀行轉賬：在銀行轉賬場景中，需要保證轉賬金額的正確性，從而避免資金損失。
- 訂單支付：在訂單支付場景中，需要保證訂單的狀態正確，從而避免訂單丟失。
- 數據庫操作：在數據庫操作場景中，需要保證數據的完整性和一致性。
三、本質區別
分布式鎖可以防止多個進程或線程同時訪問共享資源，從而避免數據沖突和資源競爭。事務可以保證數據在操作過程中的一致性，即使在發生異常的情況下，也不會導致數據不一致。
在實際應用中，可以根據具體的需求選擇合適的方案。如果需要保證數據的一致性，可以使用事務。如果只需要防止資源競爭，可以使用分布式鎖。
四、鎖與事務實現
1、鎖方案
分布式鎖的實現方法有很多，常見的有以下幾種：
- 數據庫鎖：使用數據庫中的行鎖或表鎖來實現分布式鎖。
- 文件鎖：使用文件來實現分布式鎖。
- Zookeeper鎖：使用Zookeeper來實現分布式鎖。
- Redis鎖：使用Redis來實現分布式鎖。
- 消息隊列鎖：使用消息隊列來實現分布式鎖。
Redisson 是一個基于 Redis 的 Java 分布式框架。Redisson 提供了豐富的功能，包括分布式鎖、分布式集合、分布式隊列等。
以下是使用 Redisson 實現分布式鎖的示例：
@Autowired
private RedissonClient redissonClient;
public String lock() {
// 獲取鎖
RLock lock = redissonClient.getLock("lock");
boolean acquired = lock.tryLock(10,-1,TimeUnit.SECONDS);
if (acquired) {
// 獲取鎖成功，執行業務邏輯
return "獲取鎖成功，執行業務邏輯...";
} else {
// 獲取鎖失敗，重試
return "獲取鎖失敗，重試...";
}
}
public String unlock() {
// 釋放鎖
RLock lock = redissonClient.getLock("lock");
lock.unlock();
return "釋放鎖成功...";
}另外，redisson支持鎖續期。即在鎖鍵值過期后任務還沒執行完成，此時需要把鎖鍵值的時間自動延長。
Redisson提供了的續期機制，只要客戶端加鎖成功，就會啟動一個Watch Dog。可以看到源代碼的實現leaseTime不設置為-1時開啟監聽。如果任務沒完成就調用scheduleExpirationRenewal續期方法。
tryLock() 方法用于嘗試獲取分布式鎖，該方法有三個參數：
- key：鎖的鍵值。
- waitTime：等待獲取鎖的時間，單位為毫秒。
- leaseTime：鎖的過期時間，單位為毫秒。
waitTime 參數表示客戶端最多等待多長時間來獲取鎖。如果在 waitTime 時間內沒有獲取到鎖，則會返回 false。
leaseTime 參數表示鎖的過期時間。如果鎖在 leaseTime 時間內沒有被釋放，則會自動釋放。如果 leaseTime 設置為 -1，則表示鎖的過期時間由 renew() 方法來控制。這樣，在業務邏輯執行過程中，可以定期調用 lock.renew() 方法來續期鎖的過期時間。
tryLock() 方法的返回值是一個 Boolean 值，表示是否成功獲取到鎖。如果成功獲取到鎖，則返回 true。否則，返回 false。
2、事務方案
以下是一些常見的分布式事務解決方案：
兩階段提交(2PC)
2PC是一種經典的分布式事務解決方案，它將分布式事務分為兩個階段：準備階段和提交階段。在準備階段，協調者向所有參與者發送預提交請求；如果所有參與者都同意預提交，則進入提交階段；否則，所有參與者都將回滾事務。2PC的優點是可以保證原子性、一致性和隔離性，但是實現復雜度較高。
三階段提交(3PC)
3PC是在2PC的基礎上發展而來的一種改進方案，它引入了超時機制和預提交響應等新特性。在3PC中，協調者會向所有參與者發送預提交請求，并等待參與者的響應。如果所有參與者都同意預提交，則進入預提交階段；否則，進入回滾階段。在正式提交階段，如果所有參與者都同意提交事務，則進入正式提交階段；否則，所有參與者都將回滾事務。3PC的優點是可以更好地處理節點故障等問題，但是實現復雜度仍然較高。
TCC(Try-Confirm-Cancel)
TCC是一種基于補償機制的分布式事務解決方案。它將分布式事務分為三個階段：嘗試階段、確認階段和取消階段。在嘗試階段，參與者嘗試預留所需的資源，并執行一些檢查和準備工作，以確保執行事務操作的前提條件滿足；在確認階段，如果所有參與者都滿足，則所有參與者執行之前在Try階段所預留的操作，并提交實際的數據持久化。在取消階段，如果有任何一個參與者執行失敗，則執行回滾操作，將系統狀態恢復到事務開始之前的狀態。TCC的優點是可以避免阻塞情況的發生，但是實現復雜度較高。
Saga模式
Saga模式是一種基于事件驅動的分布式事務解決方案。它將分布式事務看作一系列的事件序列，每個事件都有一個唯一的ID和一個時間戳。在每個事件發生時，參與者會根據事件的內容執行相應的本地事務。如果某個參與者執行失敗，則會記錄該事件的狀態為“已失敗”，并等待其他參與者的響應。當所有的事件都被處理完畢后，再執行最終的本地事務。Saga模式的優點是可以支持復雜的業務邏輯和異常情況處理，但是實現復雜度較高。
消息隊列
消息隊列可以用于異步地處理多個任務，并且可以保證任務的順序執行。在分布式系統中使用消息隊列來處理事務時，可以將事務拆分成多個小任務，并將這些任務發布到消息隊列中進行異步處理。當所有任務都完成后，再執行最終的本地事務。這種方式可以避免阻塞情況的發生，并且可以提高系統的可擴展性和容錯能力。能保證事務的最終一致性。
最大努力通知（Best Effort Delivery）
這種解決方案通過異步通信和消息重試來實現事務的最終一致性。事務操作被封裝為消息發送到目標系統，如果消息傳遞失敗，系統會進行重試。
分布式事務中間件
Seata是一款阿里巴巴開源的分布式事務中間件，它提供了AT、TCC、SAGA和XA事務模式，為用戶打造一站式的分布式解決方案。Seata的設計思路是將一個分布式事務理解成全局事務，下面掛了若干個分支事務，而一個分支事務就是一個滿足ACID的本地事務，因此我們可以操作分布式事務像操作本地事務一樣簡單。
