Redis分布式鎖介紹

redis

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

Redis 分布式鎖

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

2. 獲取鎖的時(shí)候調(diào)用 setnx，如果返回 0，則該鎖正在被別人使用，返回 1 則成功獲取鎖。 還設(shè)置一個(gè)獲取的超時(shí)時(shí)間，若超過(guò)這個(gè)時(shí)間則放棄獲取鎖。

3. 釋放鎖的時(shí)候，通過(guò) UUID 判斷是不是該鎖，若是該鎖，則執(zhí)行 delete 進(jìn)行鎖釋放。

分區(qū)分表

分庫(kù)分表有垂直切分和水平切分兩種。

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

將表按照功能模塊、關(guān)系密切程度劃分出來(lái)，部署到不同的庫(kù)上。例如，我們會(huì)建立定義數(shù)據(jù)庫(kù) workDB、商品數(shù)據(jù)庫(kù) payDB、用戶數(shù)據(jù)庫(kù) userDB、日志數(shù)據(jù)庫(kù) logDB 等，分別用于存儲(chǔ)項(xiàng)目數(shù)據(jù)定義表、商品定義表、用戶數(shù)據(jù)表、日志數(shù)據(jù)表等。

水平切分(按照規(guī)則劃分存儲(chǔ))

§ 當(dāng)一個(gè)表中的數(shù)據(jù)量過(guò)大時(shí)，我們可以把該表的數(shù)據(jù)按照某種規(guī)則，例如 userID 散列，進(jìn)行劃分，然后存儲(chǔ)到多個(gè)結(jié)構(gòu)相同的表，和不同的庫(kù)上。

兩階段提交協(xié)議

分布式事務(wù)是指會(huì)涉及到操作多個(gè)數(shù)據(jù)庫(kù)的事務(wù),在分布式系統(tǒng)中，各個(gè)節(jié)點(diǎn)之間在物理上相互獨(dú)立，通過(guò)網(wǎng)絡(luò)進(jìn)行溝通和協(xié)調(diào)。XA 就是 X/Open DTP 定義的交易中間件與數(shù)據(jù)庫(kù)之間的接口規(guī)范（即接口函數(shù)），交易中間件用它來(lái)通知數(shù)據(jù)庫(kù)事務(wù)的開始、結(jié)束以及提交、回滾等。 XA 接口函數(shù)由數(shù)據(jù)庫(kù)廠商提供。

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

準(zhǔn)備階段

事務(wù)協(xié)調(diào)者(事務(wù)管理器)給每個(gè)參與者(資源管理器)發(fā)送 Prepare 消息，每個(gè)參與者要么直接返回失敗(如權(quán)限驗(yàn)證失敗)，要么在本地執(zhí)行事務(wù)，寫本地的 redo 和 undo 日志，但不提交，到達(dá)一種“萬(wàn)事俱備，只欠東風(fēng)”的狀態(tài)。

提交階段

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

缺點(diǎn)

同步阻塞問(wèn)題

1、執(zhí)行過(guò)程中，所有參與節(jié)點(diǎn)都是事務(wù)阻塞型的。

單點(diǎn)故障

2、由于協(xié)調(diào)者的重要性，一旦協(xié)調(diào)者發(fā)生故障。參與者會(huì)一直阻塞下去。

數(shù)據(jù)不一致（腦裂問(wèn)題）

3、在二階段提交的階段二中，當(dāng)協(xié)調(diào)者向參與者發(fā)送 commit 請(qǐng)求之后，發(fā)生了局部網(wǎng)絡(luò)異?；蛘咴诎l(fā)送 commit 請(qǐng)求過(guò)程中協(xié)調(diào)者發(fā)生了故障，導(dǎo)致只有一部分參與者接受到了commit 請(qǐng)求。于是整個(gè)分布式系統(tǒng)便出現(xiàn)不數(shù)據(jù)不一不性的現(xiàn)象(腦裂現(xiàn)象)。

二階段無(wú)法解決的問(wèn)題（數(shù)據(jù)狀態(tài)不確定）

4、協(xié)調(diào)者再發(fā)出 commit 消息之后宕機(jī)，而唯一接收到這條消息的參與者同時(shí)也宕機(jī)了。那么即使協(xié)調(diào)者通過(guò)選舉協(xié)議產(chǎn)生了新的協(xié)調(diào)者，這條事務(wù)的狀態(tài)也是不確定的，沒(méi)人知道事務(wù)是否被已經(jīng)提交。

三階段提交協(xié)議

三階段提交（ Three-phase commit ） ， 也 叫 三 階 段 提 交 協(xié) 議 （ Three-phase commit protocol），是二階段提交（2PC）的改進(jìn)版本。

與兩階段提交不同的是，三階段提交有兩個(gè)改動(dòng)點(diǎn)。

1、引入超時(shí)機(jī)制。同時(shí)在協(xié)調(diào)者和參與者中都引入超時(shí)機(jī)制。

2、在第一階段和第二階段中插入一個(gè)準(zhǔn)備階段。保證了在最后提交階段之前各參與節(jié)點(diǎn)的狀態(tài)是一致的。也就是說(shuō)，除了引入超時(shí)機(jī)制之外，3PC 把 2PC 的準(zhǔn)備階段再次一分為二，這樣三階段

CanCommit 階段

協(xié)調(diào)者向參與者發(fā)送 commit 請(qǐng)求，參與者如果可以提交就返回 Yes 響應(yīng)，否則返回 No 響應(yīng)。

PreCommit 階段

協(xié)調(diào)者根據(jù)參與者的反應(yīng)情況來(lái)決定是否可以繼續(xù)進(jìn)行，有以下兩種可能。假如協(xié)調(diào)者從所有的參與者獲得的反饋都是 Yes 響應(yīng)，那么就會(huì)執(zhí)行事務(wù)的預(yù)執(zhí)行假如有任何一個(gè)參與者向協(xié)調(diào)者發(fā)送了 No 響應(yīng)，或者等待超時(shí)之后，協(xié)調(diào)者都沒(méi)有接到參與者的響應(yīng)，那么就執(zhí)行事務(wù)的中斷。

doCommit 階段

該階段進(jìn)行真正的事務(wù)提交，主要包含 1.協(xié)調(diào)這發(fā)送提交請(qǐng)求 2.參與者提交事務(wù) 3.參與者響應(yīng)反饋（ 事務(wù)提交完之后，向協(xié)調(diào)者發(fā)送 Ack 響應(yīng)。）4.協(xié)調(diào)者確定完成事務(wù)。

柔性事務(wù)

在電商領(lǐng)域等互聯(lián)網(wǎng)場(chǎng)景下，傳統(tǒng)的事務(wù)在數(shù)據(jù)庫(kù)性能和處理能力上都暴露出了瓶頸。在分布式領(lǐng)域基于 CAP 理論以及 BASE 理論，有人就提出了 柔性事務(wù) 的概念。CAP（一致性、可用性、分區(qū)容忍性）理論大家都理解很多次了，這里不再敘述。說(shuō)一下 BASE 理論，它是在 CAP 理論的基礎(chǔ)之上的延伸。包括 基本可用（Basically Available）、柔性狀態(tài)（Soft State）、最終一致性（Eventual Consistency）。

通常所說(shuō)的柔性事務(wù)分為：兩階段型、補(bǔ)償型、異步確保型、最大努力通知型幾種。

兩階段型

1、就是分布式事務(wù)兩階段提交，對(duì)應(yīng)技術(shù)上的 XA、JTA/JTS。這是分布式環(huán)境下事務(wù)處理的典型模式。

補(bǔ)償型

2、TCC 型事務(wù)（Try/Confirm/Cancel）可以歸為補(bǔ)償型

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

基于 Redis 分布式鎖：分區(qū)分表+兩/三階段提交協(xié)議+柔性事務(wù)+CAP

異步確保型

3、通過(guò)將一系列同步的事務(wù)操作變?yōu)榛谙?zhí)行的異步操作, 避免了分布式事務(wù)中的同步阻塞操作的影響。

基于 Redis 分布式鎖：分區(qū)分表+兩/三階段提交協(xié)議+柔性事務(wù)+CAP

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

4、這是分布式事務(wù)中要求最低的一種, 也可以通過(guò)消息中間件實(shí)現(xiàn), 與前面異步確保型操作不同的一點(diǎn)是, 在消息由 MQ Server 投遞到消費(fèi)者之后, 允許在達(dá)到最大重試次數(shù)之后正常結(jié)束事務(wù)。

CAP

CAP 原則又稱 CAP 定理，指的是在一個(gè)分布式系統(tǒng)中， Consistency（一致性）、 Availability

（可用性）、Partition tolerance（分區(qū)容錯(cuò)性），三者不可得兼。

一致性（C）：

1. 在分布式系統(tǒng)中的所有數(shù)據(jù)備份，在同一時(shí)刻是否同樣的值。（等同于所有節(jié)點(diǎn)訪問(wèn)同一份最新的數(shù)據(jù)副本）

可用性（A）：

1. 在集群中一部分節(jié)點(diǎn)故障后，集群整體是否還能響應(yīng)客戶端的讀寫請(qǐng)求。（對(duì)數(shù)據(jù)更新具備高可用性）

分區(qū)容忍性（P）：

1. 以實(shí)際效果而言，分區(qū)相當(dāng)于對(duì)通信的時(shí)限要求。系統(tǒng)如果不能在時(shí)限內(nèi)達(dá)成數(shù)據(jù)一致性，就意味著發(fā)生了分區(qū)的情況，必須就當(dāng)前操作在 C 和 A 之間做出選擇。