前言

在多個(gè)客戶端并發(fā)訪問Redis的時(shí)候，雖然Redis是單線程執(zhí)行指令，但是由于客戶端指令達(dá)到Redis的時(shí)序無法保證，所以可能出現(xiàn)如下的情況，導(dǎo)致并發(fā)問題。

2個(gè)客戶端都執(zhí)行 get, set指令，期望將key的值設(shè)置為3，結(jié)果因?yàn)椴l(fā)問題，導(dǎo)致結(jié)果為2
client1 get x => 1
client2 get x => 1
client1 set x => 2
client2 set x => 2

本文介紹 Redis 并發(fā)方面的解決方案。

Redis 的單個(gè)命令是原子的，但是一個(gè)業(yè)務(wù)操作可能包含多條命令，比如以下場景：客戶端查詢值，并遞增，在高并發(fā)場景下就可能出現(xiàn)并發(fā)問題，導(dǎo)致數(shù)據(jù)不一致。

為了保證并發(fā)訪問的正確性，Redis 提供了三種方法，原子操作、分布式鎖、事務(wù)。

1.分布式鎖

與分布式鎖相對的是本地鎖，假如只有一個(gè)服務(wù)實(shí)例，就可以直接在該單應(yīng)用本地使用鎖變量來控制多個(gè)客戶端的訪問。

如果使用的是多實(shí)例的分布式系統(tǒng)，就需要使用分布式鎖，即將鎖保存在一個(gè)第三方的共享存儲(chǔ)系統(tǒng)中，可以被多個(gè)客戶端共享訪問和獲取。通常將一個(gè) Redis 實(shí)例作為分布式鎖的存儲(chǔ)系統(tǒng)。

實(shí)現(xiàn)分布式鎖的關(guān)鍵在于：

• 保證每個(gè)加鎖、釋放鎖操作都是原子的；
• 保證共享存儲(chǔ)系統(tǒng)的可靠性，即鎖的可靠性；

分布式鎖相較于 Lua 腳本，更簡單易用，但是可能存在死鎖問題。分布式鎖的性能不如 Lua 腳本。

1.基于單個(gè)節(jié)點(diǎn)

Redis 提供了 SETNX 命令（在 SET 命令后加上 NX 選項(xiàng)也能達(dá)到同樣的效果），保證了加鎖操作的原子性。

同時(shí)，為了避免客戶端加鎖后不釋放，應(yīng)該給鎖變量設(shè)置過期時(shí)間(set NX EX)，且在過期釋放鎖時(shí)，判斷業(yè)務(wù)代碼是否執(zhí)行完成，如果未完成則給鎖續(xù)期。如果多次續(xù)期后，業(yè)務(wù)仍然未完成，再釋放鎖。（仍然存在風(fēng)險(xiǎn)）

為了區(qū)分不同客戶端的操作，應(yīng)該將鎖變量設(shè)置為隨機(jī)值或唯一值，在釋放鎖時(shí)進(jìn)行驗(yàn)證。

釋放鎖的邏輯包含了讀取鎖變量、判斷值、刪除鎖變量的多個(gè)操作，所以應(yīng)該使用 Lua 腳本來保證互斥執(zhí)行。

單個(gè)節(jié)點(diǎn)可以實(shí)現(xiàn)分布式鎖的功能，但是無法保證可靠性。

2.基于多個(gè)節(jié)點(diǎn)

為了避免 Redis 實(shí)例故障而導(dǎo)致的鎖無法工作的問題，Redis 的開發(fā)者 Antirez 提出了分布式鎖算法 Redlock。

Redlock 算法的基本思路，是讓客戶端和多個(gè)獨(dú)立的 Redis 實(shí)例依次請求加鎖，如果客戶端能夠和半數(shù)以上的實(shí)例成功地完成加鎖操作，就認(rèn)為客戶端成功地獲得分布式鎖了，否則加鎖失敗。這樣一來，即使有單個(gè)實(shí)例發(fā)生故障，因?yàn)殒i變量在其它實(shí)例上也有保存，所以客戶端仍然可以正常地進(jìn)行鎖操作，鎖變量并不會(huì)丟失。

加鎖過程：

• 客戶端獲取當(dāng)前時(shí)間；
• 客戶端按順序依次向 N 個(gè) Redis 實(shí)例執(zhí)行加鎖操作。同樣使用 SETNX 命令，并設(shè)置超時(shí)時(shí)間。如果請求加鎖一直超時(shí)，則視為加鎖失敗，向下一個(gè)實(shí)例執(zhí)行加鎖操作。
• 客戶端完成所有加鎖操作后，計(jì)算整個(gè)加鎖過程的總耗時(shí)。

客戶端只有在滿足下面的這兩個(gè)條件時(shí)，才能認(rèn)為是加鎖成功：

• 從超過半數(shù)（大于等于 N/2+1）的實(shí)例上成功獲取到了鎖；
• 獲取鎖的總耗時(shí)沒有超過鎖的有效時(shí)間。

在滿足了這兩個(gè)條件后，還需要重新計(jì)算這把鎖的有效時(shí)間，計(jì)算的結(jié)果是鎖的最初有效時(shí)間減去客戶端為獲取鎖的總耗時(shí)。如果鎖的有效時(shí)間已經(jīng)來不及完成共享數(shù)據(jù)的操作了，可以釋放鎖，以免出現(xiàn)還沒完成數(shù)據(jù)操作，鎖就過期了的情況。
如果沒能同時(shí)滿足這兩個(gè)條件，則視為加鎖失敗，執(zhí)行釋放鎖的過程：客戶端會(huì)向所有節(jié)點(diǎn)發(fā)起釋放鎖的操作，執(zhí)行釋放鎖的 Lua 腳本。

判斷是否加鎖時(shí)，需要查詢所有節(jié)點(diǎn)，以半數(shù)以上節(jié)點(diǎn)的鎖狀態(tài)來判斷整個(gè)分布式鎖的狀態(tài)。在釋放鎖之前，需要先判斷分布式鎖的狀態(tài)。

為了避免 Redis 節(jié)點(diǎn)發(fā)生崩潰重啟后造成鎖丟失，從而影響鎖的安全性，antirez 還提出了延時(shí)重啟的概念，即一個(gè)節(jié)點(diǎn)崩潰后不要立即重啟，而是等待一段時(shí)間后再進(jìn)行重啟，這段時(shí)間應(yīng)該大于鎖的有效時(shí)間。優(yōu)點(diǎn)是保證了鎖不會(huì)被多個(gè)客戶端獲取；缺點(diǎn)是延長了重啟時(shí)間，可能對系統(tǒng)造成影響。

性能和一致性是沖突的，如果為了分布式鎖的高可用性，可以開啟持久化，但是會(huì)有額外的性能開銷，需要根據(jù)實(shí)際場景進(jìn)行選擇。

3.watch(樂觀鎖) 

watch通常跟redis事務(wù)配合使用，watch某個(gè)key在操作過程中有沒有被其他指令改變，進(jìn)而做出相應(yīng)的處理。底層利用了CAS操作，后面講Redis事務(wù)會(huì)講到。

2.原子操作

為了實(shí)現(xiàn)并發(fā)控制要求的臨界區(qū)代碼互斥執(zhí)行，Redis 的原子操作采用了兩種方法：單命令操作和 Lua 腳本。

1.單命令操作

Redis 的每個(gè)操作都是原子性的。

Redis 是使用單線程來串行處理客戶端的請求操作命令的，所以，當(dāng) Redis 執(zhí)行某個(gè)命令操作時(shí)，其他命令是無法執(zhí)行的，這相當(dāng)于單個(gè)操作是原子的。雖然 Redis 的單個(gè)操作是原子的，但是通常修改數(shù)據(jù)是包含多個(gè)操作的，至少包括讀數(shù)據(jù)、修改數(shù)據(jù)、寫回?cái)?shù)據(jù)這三個(gè)操作，此時(shí)仍然可能出現(xiàn)并發(fā)問題。

針對常用的修改數(shù)據(jù)場景，Redis 提供了 INCR/DECR 命令，可以對數(shù)據(jù)進(jìn)行簡單的遞增/遞減操作，它們本身就是單個(gè)命令操作，在執(zhí)行時(shí)，具有互斥性。但是如果要執(zhí)行更復(fù)雜的操作，Redis 的單命令操作就無法保證互斥執(zhí)行了。

2.Lua 腳本(多命令操作)

Redis 可以將多個(gè)操作寫在 Lua 腳本中，然后把整個(gè) Lua 腳本作為一個(gè)整體執(zhí)行，在執(zhí)行的過程中不會(huì)被其他命令打斷，從而保證了 Lua 腳本中操作的原子性。

為什么是 Lua 腳本，而不是其他語言的腳本？
Lua 是一種高效的輕量級 腳本語言，用標(biāo)準(zhǔn) C 語言編寫并以源代碼形式開放。其設(shè)計(jì)目的就是為了嵌入應(yīng)用程序中，從而為應(yīng)用程序提供靈活的擴(kuò)展和定制功能。

Lua 腳本可以在服務(wù)器端執(zhí)行，不需要將數(shù)據(jù)傳輸?shù)娇蛻舳嗽龠M(jìn)行處理，可以減少網(wǎng)絡(luò)傳輸?shù)拈_銷，因此性能較高。

使用 Lua 腳本不僅可以實(shí)現(xiàn)將多個(gè)操作原子執(zhí)行，還能夠復(fù)用 Lua 腳本。但是使用 Lua 腳本需要額外的語言學(xué)習(xí)成本，還有調(diào)試?yán)щy、可讀性較差的問題。

如果把很多操作都放在 Lua 腳本中原子執(zhí)行，會(huì)導(dǎo)致 Redis 執(zhí)行腳本的時(shí)間增加，同樣也會(huì)降低 Redis 的并發(fā)性能。所以，在編寫 Lua 腳本時(shí)，要避免把不需要做并發(fā)控制的操作寫入腳本中。

在 Lua 腳本執(zhí)行過程中崩潰怎么辦？
Redis 會(huì)在內(nèi)部維護(hù)一個(gè)已經(jīng)加載腳本的 哈希表，記錄了每個(gè)腳本的 SHA1 值和對應(yīng)的 Lua 腳本代碼。當(dāng) Redis 服務(wù)器重啟時(shí)，Redis 會(huì)自動(dòng)重新加載這個(gè)哈希表中記錄的所有腳本，再重新執(zhí)行，此時(shí)可能導(dǎo)致部分修改被應(yīng)用。所以 Lua 腳本并不能嚴(yán)格保證原子性。如果對數(shù)據(jù)一致性非常嚴(yán)格，可以使用 Lua 腳本+事務(wù) WATCH 的辦法。

3.事務(wù)

Redis 事務(wù)的本質(zhì)是一組命令的集合。事務(wù)支持一次執(zhí)行多個(gè)命令，一個(gè)事務(wù)中所有命令都會(huì)被序列化。在事務(wù)執(zhí)行過程，會(huì)按照順序串行化執(zhí)行隊(duì)列中的命令，其他客戶端提交的命令請求不會(huì)插入到事務(wù)執(zhí)行命令序列中。

Redis 提供了實(shí)現(xiàn)事務(wù)的幾個(gè)命令：

• MULTI ：開啟事務(wù)，redis 會(huì)將后續(xù)的命令逐個(gè)放入隊(duì)列中，然后使用 EXEC 命令來原子化執(zhí)行這個(gè)命令系列。
• EXEC：執(zhí)行事務(wù)中的所有操作命令。
• DISCARD：取消事務(wù)，放棄執(zhí)行事務(wù)塊中的所有命令。
• WATCH：在開啟事務(wù)之前監(jiān)視一個(gè)或多個(gè) key，如果事務(wù)在執(zhí)行前，這個(gè) key （或多個(gè) key）被其他命令修改，則事務(wù)被中斷，不會(huì)執(zhí)行事務(wù)中的任何命令（一般需要在 EXEC 執(zhí)行失敗后重新執(zhí)行整個(gè)函數(shù)）。

UNWATCH：取消 WATCH 對所有 key 的監(jiān)視。

為什么 WATCH 是中斷事務(wù)，而不是阻塞其他進(jìn)程？這樣不會(huì)導(dǎo)致并發(fā)量高的時(shí)候，被 WATCH 的事務(wù)一直得不到執(zhí)行嗎？
這種機(jī)制稱為 樂觀鎖，因?yàn)樵诖蠖鄶?shù)情況下，碰撞的概率很小，所以選用了更容易實(shí)現(xiàn)的方式（且影響不大）。

在使用事務(wù)時(shí)，可以配合 Pipeline 使用：一次性將所有命令打包好，再全部發(fā)送到服務(wù)端。
相比于事務(wù)的入隊(duì)，同樣是一次性執(zhí)行，這樣不僅能減少網(wǎng)絡(luò) IO，還能保證在開啟 WATCH 時(shí)不會(huì)被其他操作打斷。

1.執(zhí)行步驟

• 開啟事務(wù)：使用 MULTI 命令開啟事務(wù)；
• 入隊(duì)：接收到命令后并不會(huì)立即執(zhí)行，而是放到等待執(zhí)行的事務(wù)隊(duì)列里；
• 執(zhí)行：由 EXEC 命令觸發(fā)事務(wù)執(zhí)行。

當(dāng)客戶端切換到事務(wù)狀態(tài)之后， 服務(wù)器會(huì)根據(jù)這個(gè)客戶端發(fā)來的不同命令執(zhí)行不同的操作：

• 如果客戶端發(fā)送的命令為 EXEC 、DISCARD、WATCH、MULTI 四個(gè)命令的其中一個(gè)， 那么服務(wù)器立即執(zhí)行這個(gè)命令；
• 如果是其他命令， 那么服務(wù)器并不立即執(zhí)行命令， 而是將這個(gè)命令放入一個(gè)事務(wù)隊(duì)列里面， 然后向客戶端返回 QUEUED 回復(fù)；

2.錯(cuò)誤處理

在事務(wù)執(zhí)行過程中可能遇到兩種不同類型的錯(cuò)誤，會(huì)有不同的應(yīng)對方案：

• 編譯器錯(cuò)誤：命令在編譯時(shí)出錯(cuò)，會(huì)導(dǎo)致整個(gè)事務(wù)提交失敗，即所有命令執(zhí)行不成功；
• 運(yùn)行時(shí)錯(cuò)誤：命令在運(yùn)行時(shí)檢測到錯(cuò)誤，最終會(huì)導(dǎo)致事務(wù)提交失敗，但是事務(wù)并不會(huì)回滾，而是跳過錯(cuò)誤命令繼續(xù)執(zhí)行并保留結(jié)果；

為什么 Redis 不支持 事務(wù)回滾？
Redis 命令只會(huì)因?yàn)殄e(cuò)誤的語法而失敗（并且這些問題不能在入隊(duì)時(shí)發(fā)現(xiàn)），或是命令用在了錯(cuò)誤類型的鍵上面：這也就是說，從實(shí)用性的角度來說，失敗的命令是由編程錯(cuò)誤造成的，而這些錯(cuò)誤應(yīng)該在開發(fā)的過程中被發(fā)現(xiàn)，而不應(yīng)該出現(xiàn)在生產(chǎn)環(huán)境中。
不需要對回滾進(jìn)行支持，所以 Redis 的內(nèi)部可以保持簡單且快速。

3.崩潰處理

Redis 在執(zhí)行事務(wù)時(shí)會(huì)使用一個(gè)單獨(dú)的內(nèi)存空間來保存事務(wù)中的所有修改操作，只有當(dāng)事務(wù)成功提交時(shí)，這些修改操作才會(huì)被應(yīng)用到 Redis 中。因此，如果事務(wù)被中止，所有的修改操作也都會(huì)被撤銷，從而保證了數(shù)據(jù)的一致性。

如果開啟了 AOF 持久化，會(huì)先將事務(wù)中的所有命令寫入 AOF 緩沖區(qū)，然后執(zhí)行事務(wù)中的命令，再將 AOF 緩沖區(qū)中的數(shù)據(jù)寫入到 AOF 文件。

如果在寫入 AOF 文件前崩潰，則持久化失敗，相當(dāng)于事務(wù)沒有發(fā)生，不會(huì)出現(xiàn)數(shù)據(jù)不一致。

另外，RDB 快照不會(huì)在事務(wù)執(zhí)行途中進(jìn)行。

總結(jié)

本文介紹了 Redis 應(yīng)對并發(fā)問題的三種方案，Redis 中的單條命令都是原子操作，而且還有 INCR/DECR 來應(yīng)對簡單的場景。對于復(fù)雜的場景，Redis 可以使用 Lua 腳本、分布式鎖、事務(wù)來實(shí)現(xiàn)操作的原子性。Lua 腳本是將一系列操作放在一個(gè)腳本中原子執(zhí)行。分布式鎖是通過共享的鎖變量來限制客戶端的并發(fā)訪問。事務(wù)是將一系列操作放到執(zhí)行隊(duì)列中，再按順序原子執(zhí)行。

到此這篇關(guān)于Redis并發(fā)問題解決方案的文章就介紹到這了,更多相關(guān)Redis并發(fā)內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論