[[404462]]

Redis 作為一個非常成功的數(shù)據(jù)庫，提供了非常豐富的數(shù)據(jù)類型和命令，使用這些，我們可以輕易而高效地完成很多緩存操作，可是總有一些比較特殊問題或需求需要解決，這時候可能就需要我們自己定制自己的 Redis 數(shù)據(jù)結(jié)構(gòu)和命令。

Redis命令問題

“線程安全”問題

我們都知道 Redis 是單線程的，可是它怎么會有線程安全問題呢？

我們正常理解的線程安全問題是指單進(jìn)程多線程模型內(nèi)部多個線程操作進(jìn)程內(nèi)共享內(nèi)存導(dǎo)致的數(shù)據(jù)資源充突。而 Redis 的線程安全問題的產(chǎn)生，并不是來自于 Redis 服務(wù)器內(nèi)部。

Redis 作為數(shù)據(jù)服務(wù)器，就相當(dāng)于多個客戶端的共享內(nèi)存，多個客戶端就相當(dāng)于同一進(jìn)程下的多個線程，如果多個客戶端之間沒有良好的數(shù)據(jù)同步策略，就會產(chǎn)生類似線程安全的問題。

典型場景是：

•  Redis 內(nèi)存儲了一個用戶的狀態(tài)：user5277=idle；
•  客戶端連接 A 讀取了用戶狀態(tài)，獲取到用戶的空閑狀態(tài) status = get("user5277")；
•  客戶端連接 B 也同樣讀取了用戶狀態(tài)；
•  客戶端連接 A 給用戶安排了一個任務(wù)，并將 Redis 內(nèi)用戶狀態(tài)置為忙碌 set("user5277", "busy")；
•  客戶端連接 B 同樣設(shè)置用戶為忙碌狀態(tài)。
•  可是此時用戶卻被同時分配了兩個任務(wù)。

導(dǎo)致這個問題的原因就是雖然 Redis 是單線程的，能保證命令的序列化，但由于其執(zhí)行效率很高，多個客戶端的命令之間不做好請求同步，同樣會造成命令的順序錯亂。

當(dāng)然這個問題也很好解決，給用戶狀態(tài)加鎖就行了，使同一時間內(nèi)只能有一個客戶端操作用戶狀態(tài)。不過加鎖我們就需要考慮鎖粒度、死鎖等問題了，無疑添加了程序的復(fù)雜性，不利于維護(hù)。

效率問題

Redis 作為一個極其高效的內(nèi)存數(shù)據(jù)服務(wù)器，其命令執(zhí)行速度極快，之前看過阿里云 Redis 的一個壓測結(jié)果，執(zhí)行效率可以達(dá)到 10W寫QPS， 60W讀QPS，那么，它的效率問題又來自何處呢？

答案是網(wǎng)絡(luò)，做 Web 的都知道，效率優(yōu)化要從網(wǎng)絡(luò)做起，服務(wù)端又是優(yōu)化代碼，又是優(yōu)化數(shù)據(jù)庫，不如網(wǎng)絡(luò)連接的一次優(yōu)化，而網(wǎng)絡(luò)優(yōu)化最有效的就是減少請求數(shù)。我們要知道執(zhí)行一次內(nèi)存訪問的耗時約是 100ns，而不同機(jī)房之間來回一次約需要 500000ns，其中的差距可想而知。

Redis在單機(jī)內(nèi)效率超高，但工業(yè)化部署總不會把服務(wù)器和 Redis 放在同一臺機(jī)器上，如果觸碰到效率瓶頸的話，那就是網(wǎng)絡(luò)。Spring Boot 學(xué)習(xí)筆記，推薦看下。

典型場景就是我們從 Redis 里讀出一條數(shù)據(jù)，再使用這條數(shù)據(jù)做鍵，讀取另外一條數(shù)據(jù)。這樣來來回回，便有兩次網(wǎng)絡(luò)往返。

導(dǎo)致這種問題的原因就是 Redis 的普通命令沒有服務(wù)端計(jì)算的能力，無法在服務(wù)器進(jìn)行復(fù)合命令操作，雖然有 Redis 也提供了 pipeline 的特性，但它需要多個命令的請求和響應(yīng)之間沒有依賴關(guān)系。想簡化多個相互依賴的命令就只能將數(shù)據(jù)拉回客戶端，由客戶端處理后再請求 Redis。

綜上，我們要更高效更方便的使用 Redis 就需要自己“定制”一些命令了。另外，Redis 面試題和答案都整理好了，微信搜索公眾號：Java技術(shù)棧，在后臺回復(fù)面試獲致。

內(nèi)嵌Lua的執(zhí)行

萬幸 Redis 內(nèi)嵌了 Lua 執(zhí)行環(huán)境，支持 Lua 腳本的執(zhí)行，通過執(zhí)行 Lua 腳本，我們可以把多個命令復(fù)合為一個 Lua 腳本，通過 Lua 腳本來實(shí)現(xiàn)上文中提到的 Redis 命令的次序性和 Redis 服務(wù)端計(jì)算。

Lua

Lua 是一個簡潔、輕量、可擴(kuò)展的腳本語言，它的特性有：

•  輕量：源碼包只有核心庫，編譯后體積很小。
•  高效：由 ANSI C 寫的，啟動快、運(yùn)行快。
•  內(nèi)嵌：可內(nèi)嵌到各種編程語言或系統(tǒng)中運(yùn)行，提升靜態(tài)語言的靈活性。如 OpenResty 就是將 Lua 嵌入到 nginx 中執(zhí)行。

而且完全不需要擔(dān)心語法問題，Lua 的語法很簡單，分分鐘使用不成問題。

執(zhí)行步驟

Redis 在 2.6 版本后，啟動時會創(chuàng)建 Lua 環(huán)境、載入 Lua 庫、定義 Redis 全局表格、存儲 redis.pcall 等 Redis 命令，以準(zhǔn)備 Lua 腳本的執(zhí)行。

一個典型的 Lua 腳本執(zhí)行步驟如下：

1.  檢查腳本是否執(zhí)行過，沒執(zhí)行過使用腳本的 sha1 校驗(yàn)和生成一個 Lua 函數(shù)；
2.  為函數(shù)綁定超時、錯誤處理勾子；
3.  創(chuàng)建一個偽客戶端，通過這個偽客戶端執(zhí)行 Lua 中的 Redis 命令；
4.  處理偽客戶端的返回值，最終返回給客戶端；

雖然 Lua 腳本使用的是偽客戶端，但 Redis 處理它會跟普通客戶端一樣，也會將執(zhí)行的 Redis 命令進(jìn)行 rdb aof 主從復(fù)制等操作。

使用

Lua 腳本的使用可以通過 Redis 的 EVAL 和 EVALSHA 命令。

EVAL 適用于單次執(zhí)行 Lua 腳本，執(zhí)行腳本前會由腳本內(nèi)容生成 sha1 校驗(yàn)和，在函數(shù)表內(nèi)查詢函數(shù)是否已定義，如未定義執(zhí)行成功后 Redis 會在全局表里緩存這個腳本的校驗(yàn)和為函數(shù)名，后續(xù)再次執(zhí)行此命令就不會再創(chuàng)建新的函數(shù)了。

而要使用 EVALSHA 命令，就得先使用 SCRIPT LOAD 命令先將函數(shù)加載到 Redis，Redis 會返回此函數(shù)的 sha1 校驗(yàn)和， 后續(xù)就可以直接使用這個校驗(yàn)和來執(zhí)行命令了。

以下是使用上述命令的例子： 

127.0.0.1:6379> EVAL "return 'hello'" 0 0  
"hello"  
127.0.0.1:6379> SCRIPT LOAD "return redis.pcall('GET', ARGV[1])"  
"20b602dcc1bb4ba8fca6b74ab364c05c58161a0a"  
127.0.0.1:6379> EVALSHA 20b602dcc1bb4ba8fca6b74ab364c05c58161a0a 0 test  
"zbs" 

EVAL 命令的原型是 EVAL script numkeys key [key ...] arg [arg ...]，在 Lua 函數(shù)內(nèi)部可以使用 KEYS[N] 和 ARGV[N] 引用鍵和參數(shù)，需要注意 KEYS 和 ARGV 的參數(shù)序號都是從 1 開始的。

還需要注意在 Lua 腳本中，Redis 返回為空時，結(jié)果是 false，而 不是 nil；

Lua 腳本實(shí)例

下面寫幾個 Lua 腳本的實(shí)例，用來介紹語法的，僅供參考。

Redis 里 hashSet A 的 字段 B 的值是 C，取出 Redis 里鍵為 C 的值。 

// 使用: EVAL script 2 A B  
local tmpKey = redis.call('HGET', KEYS[1], KEYS[2]);  
return redis.call('GET', tmpKey); 

一次 lpop 出多個值，直到值為 n，或 list 為空（pipeline 也可輕易實(shí)現(xiàn)）； 

// 使用: EVAL script 2 list count  
local list = {};  
local item = false;  
local num = tonumber(KEYS[2]);  
while (num > 0)  
do  
    item = redis.call('LPOP', KEYS[1]);  
    if item == false then  
        break;  
    end;  
    table.insert(list, item);  
    numnum = num - 1;  
end;  
return list; 

獲取 zset 內(nèi) score 最多的 n 個元素 對應(yīng) hashset 中的詳細(xì)信息； 

local elements = redis.call('ZRANK', KEYS[1], 0, KEY[2]);  
local detail = {};  
for index,ele in elements do  
 local info = redis.call('HGETALL', ele);  
 table.insert(detail, info);  
end;  
return detail; 

基本使用語法就是如此，更多應(yīng)用就看各個具體場景了。

一些思考

實(shí)現(xiàn)之外，還要一些東西要思考：

使用場景

首先來總結(jié)一下 Redis 中 Lua 的使用場景：

•  可以使用 Lua 腳本實(shí)現(xiàn)原子性操作，避免不同客戶端訪問 Redis 服務(wù)器造成的數(shù)據(jù)沖突。
•  在前后多次請求的結(jié)果有依賴時，可以使用 Lua 腳本把多個請求整合為一個請求。

注意點(diǎn)

使用 Lua 腳本，我們還需要注意：

•  要保證安全性，在 Lua 腳本中不要使用全局變量，以免污染 Lua 環(huán)境，雖然使用全局變量全報錯，Lua 腳本停止執(zhí)行，但還是在定義變量時添加 local 關(guān)鍵字。
•  要注意 Lua 腳本的時間復(fù)雜度，Redis 的單線程同樣會阻塞在 Lua 腳本的執(zhí)行中。
•  使用 Lua 腳本實(shí)現(xiàn)原子操作時，要注意如果 Lua 腳本報錯，之前的命令同樣無法回滾。
•  一次發(fā)出多個 Redis 請求，但請求前后無依賴時，使用 pipeline，比 Lua 腳本方便。

小結(jié)

最近工作有了較大的變動，從業(yè)務(wù)到技術(shù)棧都跟原來完全不同了，所有代碼和業(yè)務(wù)都脫離了自己掌控的感覺真的很不爽，工作中全是“開局一個搜索引擎，語法全靠查”，每天還要熬到很晚熟悉新的東西，有點(diǎn)小累，果然換工作就是找罪受啊。

不過走出舒適區(qū)后的充實(shí)感也在提醒自己正在不停進(jìn)步，倒也挺有成就感的。另外，關(guān)注公眾號Java技術(shù)棧，在后臺回復(fù)：面試，可以獲取我整理的 Redis 系列面試題和答案，非常齊全。