前言

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

Redis命令問題

線程安全問題

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

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

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

典型場景是：

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

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

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

效率問題

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

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

Redis在單機內(nèi)效率超高，但工業(yè)化部署總不會把服務器和 Redis 放在同一臺機器上，如果觸碰到效率瓶頸的話，那就是網(wǎng)絡。

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

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

綜上，我們要更高效更方便的使用 Redis 就需要自己“定制”一些命令了。

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

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

Lua

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

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

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

執(zhí)行步驟

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

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

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

交互時序如圖

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

使用

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

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

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

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

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 腳本實例

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

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

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

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

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

一些思考

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

使用場景

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

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

注意點

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

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

小結(jié)

最近工作有了較大的變動，從業(yè)務到技術棧都跟原來完全不同了，所有代碼和業(yè)務都脫離了自己掌控的感覺真的很不爽，工作中全是“開局一個搜索引擎，語法全靠查”，每天還要熬到很晚熟悉新的東西，有點小累，果然換工作就是找罪受啊。不過走出舒適區(qū)后的充實感也在提醒自己正在不停進步，倒也挺有成就感的。

剛接觸新的東西沒什么沉淀，又不想寫一些《帶你三天精通 Java》這種水文，工作之余的時間都被拿去補充工作需要的技術棧了，也沒時間研究些自己覺得有意思的東西，寫文章需要素材啊，為了不自砸招牌，最近可能會少更。。

總結(jié)

以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對大家的學習或者工作具有一定的參考學習價值，如果有疑問大家可以留言交流，謝謝大家對服務器之家的支持。

原文鏈接：http://www.cnblogs.com/zhenbianshu/p/8416162.html