Redis分布式鎖介紹

redis

是一個key-value存儲系統。和Memcached類似，它支持存儲的value類型相對更多，包括string(字符串)、list(鏈表)、set(集合)、zset(sorted set --有序集合)和hash（哈希類型）。這些數據類型都支持push/pop、add/remove及取交集并集和差集及更豐富的操作，而且這些操作都是原子性的。在此基礎上，redis支持各種不同方式的排序。與memcached一樣，為了保證效率，數據都是緩存在內存中。區別的是redis會周期性的把更新的數據寫入磁盤或者把修改操作寫入追加的記錄文件，并且在此基礎上實現了master-slave(主從)同步。

Redis 分布式鎖

1. 獲取鎖的時候，使用 setnx（SETNX key val：當且僅當 key 不存在時，set 一個 key為 val 的字符串，返回 1；若 key 存在，則什么都不做，返回 0）加鎖，鎖的 value值為一個隨機生成的 UUID，在釋放鎖的時候進行判斷。并使用 expire 命令為鎖添加一個超時時間，超過該時間則自動釋放鎖。

2. 獲取鎖的時候調用 setnx，如果返回 0，則該鎖正在被別人使用，返回 1 則成功獲取鎖。 還設置一個獲取的超時時間，若超過這個時間則放棄獲取鎖。

3. 釋放鎖的時候，通過 UUID 判斷是不是該鎖，若是該鎖，則執行 delete 進行鎖釋放。

分區分表

分庫分表有垂直切分和水平切分兩種。

垂直切分(按照功能模塊)

將表按照功能模塊、關系密切程度劃分出來，部署到不同的庫上。例如，我們會建立定義數據庫 workDB、商品數據庫 payDB、用戶數據庫 userDB、日志數據庫 logDB 等，分別用于存儲項目數據定義表、商品定義表、用戶數據表、日志數據表等。

水平切分(按照規則劃分存儲)

§ 當一個表中的數據量過大時，我們可以把該表的數據按照某種規則，例如 userID 散列，進行劃分，然后存儲到多個結構相同的表，和不同的庫上。

兩階段提交協議

分布式事務是指會涉及到操作多個數據庫的事務,在分布式系統中，各個節點之間在物理上相互獨立，通過網絡進行溝通和協調。XA 就是 X/Open DTP 定義的交易中間件與數據庫之間的接口規范（即接口函數），交易中間件用它來通知數據庫事務的開始、結束以及提交、回滾等。 XA 接口函數由數據庫廠商提供。

二階段提交(Two-phaseCommit)是指，在計算機網絡以及數據庫領域內，為了使基于分布式系統架構下的所有節點在進行事務提交時保持一致性而設計的一種算法(Algorithm)。通常，二階段提交也被稱為是一種協議(Protocol))。在分布式系統中，每個節點雖然可以知曉自己的操作時成功或者失敗，卻無法知道其他節點的操作的成功或失敗。當一個事務跨越多個節點時，為了保持事務的 ACID 特性，需要引入一個作為協調者的組件來統一掌控所有節點(稱作參與者)的操作結果并最終指示這些節點是否要把操作結果進行真正的提交(比如將更新后的數據寫入磁盤等等)。因此，二階段提交的算法思路可以概括為：參與者將操作成敗通知協調者，再由協調者根據所有參與者的反饋情報決定各參與者是否要提交操作還是中止操作。

準備階段

事務協調者(事務管理器)給每個參與者(資源管理器)發送 Prepare 消息，每個參與者要么直接返回失敗(如權限驗證失敗)，要么在本地執行事務，寫本地的 redo 和 undo 日志，但不提交，到達一種“萬事俱備，只欠東風”的狀態。

提交階段

如果協調者收到了參與者的失敗消息或者超時，直接給每個參與者發送回滾(Rollback)消息；否則，發送提交(Commit)消息；參與者根據協調者的指令執行提交或者回滾操作，釋放所有事務處理過程中使用的鎖資源。(注意:必須在最后階段釋放鎖資源)

缺點

同步阻塞問題

1、執行過程中，所有參與節點都是事務阻塞型的。

單點故障

2、由于協調者的重要性，一旦協調者發生故障。參與者會一直阻塞下去。

數據不一致（腦裂問題）

3、在二階段提交的階段二中，當協調者向參與者發送 commit 請求之后，發生了局部網絡異常或者在發送 commit 請求過程中協調者發生了故障，導致只有一部分參與者接受到了commit 請求。于是整個分布式系統便出現不數據不一不性的現象(腦裂現象)。

二階段無法解決的問題（數據狀態不確定）

4、協調者再發出 commit 消息之后宕機，而唯一接收到這條消息的參與者同時也宕機了。那么即使協調者通過選舉協議產生了新的協調者，這條事務的狀態也是不確定的，沒人知道事務是否被已經提交。

三階段提交協議

三階段提交（ Three-phase commit ） ， 也 叫 三 階 段 提 交 協 議 （ Three-phase commit protocol），是二階段提交（2PC）的改進版本。

與兩階段提交不同的是，三階段提交有兩個改動點。

1、引入超時機制。同時在協調者和參與者中都引入超時機制。

2、在第一階段和第二階段中插入一個準備階段。保證了在最后提交階段之前各參與節點的狀態是一致的。也就是說，除了引入超時機制之外，3PC 把 2PC 的準備階段再次一分為二，這樣三階段

CanCommit 階段

協調者向參與者發送 commit 請求，參與者如果可以提交就返回 Yes 響應，否則返回 No 響應。

PreCommit 階段

協調者根據參與者的反應情況來決定是否可以繼續進行，有以下兩種可能。假如協調者從所有的參與者獲得的反饋都是 Yes 響應，那么就會執行事務的預執行假如有任何一個參與者向協調者發送了 No 響應，或者等待超時之后，協調者都沒有接到參與者的響應，那么就執行事務的中斷。

doCommit 階段

該階段進行真正的事務提交，主要包含 1.協調這發送提交請求 2.參與者提交事務 3.參與者響應反饋（ 事務提交完之后，向協調者發送 Ack 響應。）4.協調者確定完成事務。

柔性事務

在電商領域等互聯網場景下，傳統的事務在數據庫性能和處理能力上都暴露出了瓶頸。在分布式領域基于 CAP 理論以及 BASE 理論，有人就提出了 柔性事務 的概念。CAP（一致性、可用性、分區容忍性）理論大家都理解很多次了，這里不再敘述。說一下 BASE 理論，它是在 CAP 理論的基礎之上的延伸。包括 基本可用（Basically Available）、柔性狀態（Soft State）、最終一致性（Eventual Consistency）。

通常所說的柔性事務分為：兩階段型、補償型、異步確保型、最大努力通知型幾種。

兩階段型

1、就是分布式事務兩階段提交，對應技術上的 XA、JTA/JTS。這是分布式環境下事務處理的典型模式。

補償型

2、TCC 型事務（Try/Confirm/Cancel）可以歸為補償型

WS-BusinessActivity 提供了一種基于補償的 long-running 的事務處理模型。服務器 A 發起事務，服務器 B 參與事務，服務器 A 的事務如果執行順利，那么事務 A 就先行提交，如果事務 B 也執行順利，則事務 B 也提交，整個事務就算完成。但是如果事務 B 執行失敗，事務 B 本身回滾，這時事務 A 已經被提交，所以需要執行一個補償操作，將已經提交的事務 A 執行的操作作反操作，恢復到未執行前事務 A 的狀態。這樣的 SAGA 事務模型，是犧牲了一定的隔離性和一致性的，但是提高了 long-running 事務的可用性。

基于 Redis 分布式鎖：分區分表+兩/三階段提交協議+柔性事務+CAP

異步確保型

3、通過將一系列同步的事務操作變為基于消息執行的異步操作, 避免了分布式事務中的同步阻塞操作的影響。

基于 Redis 分布式鎖：分區分表+兩/三階段提交協議+柔性事務+CAP

最大努力通知型（多次嘗試）

4、這是分布式事務中要求最低的一種, 也可以通過消息中間件實現, 與前面異步確保型操作不同的一點是, 在消息由 MQ Server 投遞到消費者之后, 允許在達到最大重試次數之后正常結束事務。

CAP

CAP 原則又稱 CAP 定理，指的是在一個分布式系統中， Consistency（一致性）、 Availability

（可用性）、Partition tolerance（分區容錯性），三者不可得兼。

一致性（C）：

1. 在分布式系統中的所有數據備份，在同一時刻是否同樣的值。（等同于所有節點訪問同一份最新的數據副本）

可用性（A）：

1. 在集群中一部分節點故障后，集群整體是否還能響應客戶端的讀寫請求。（對數據更新具備高可用性）

分區容忍性（P）：

1. 以實際效果而言，分區相當于對通信的時限要求。系統如果不能在時限內達成數據一致性，就意味著發生了分區的情況，必須就當前操作在 C 和 A 之間做出選擇。