Redis干貨分享 | 5個步驟構建優質Redis模塊

編寫 Redis 模塊時，請牢記以下五個步驟。雖然這份清單并不詳盡，但是如果你還沒有太多的模塊構建經驗，我還是能為你提供一個很好的入門方法的。

1、確定一個有吸引力的模塊用例

Redis 有大量的工具可以讓你構建所需的解決方案。一個例子就是鎖。通過將SET與 NX 選項一起使用，你可以創建一個鎖的 key，并將其與 EXPIRE 結合使用，即可得到一個鎖租約。這在解決協調一致問題時非常有用。當內置命令還不夠用時，你還可以使用 Lua 腳本，這些腳本為復合操作添加了完全的可編程性，然后由Redis 原子地執行這些操作。

與 Lua 相比，模塊在訪問低層次 API 的能力方面，具有更大的靈活性和更快的速度，但是它們在維護和分發方面更具挑戰性。僅在 Lua 不能完全適用你的用例時才使用模塊。

模塊可以添加新的命令

模塊可以使用 C 語言向 Redis 添加新的命令（確切地說，你也可以使用 Rust，Zig 或任何 C-ABI 兼容語言）。你在功能上做什么取決于你自己。可以從實現與現有命令相似但可以有更多功能的命令開始。SETNE（由用戶在此 GitHub Pull Request 中首次提到）就是一個示例。SETNE 的行為與 SET 完全相同，但是當新值等于當前值時，它不會修改鍵值，從而避免產生假的鍵空間通知。通常，要進行一些練習，可以考慮對現有命令添加一些附加功能，以幫助處理特定的用例。

大多數這些小的附加功能最好使用 Lua 腳本來實現，如果你剛開始想不出有吸引力的模塊，這將是一種好方式。留給讀者的幾個練習：SETEQ，HINCRDATEBY。

模塊可以添加新的數據類型

模塊向 Redis 添加功能的最有效方法是添加新的數據類型。Redis 非常注重數據結構及其相關算法和屬性的設計。盡管你可能不知道 Set 數據類型具體是怎么實現的，但是你肯定知道 SISMEMBER 命令執行很快，卻與 Set 大小無關（例如，它具有亞線性漸近復雜度）。| 有關 BigO /漸近復雜度和 Redis 數據類型的重要性的介紹，請查看 Rob Conery的演講：https://www.youtube.com/watch?v=znYgNXN98Ag

這是我們自己的模塊背后的基礎：

RediSearch 是基于倒排索引的全文本搜索模塊。

RedisGraph 是基于稀疏矩陣的圖形模塊。

RedisTimeSeries 與 Redis Streams 類似，但針對數字序列進行了優化。

RedisBloom 提供了一些不同的概率數據結構。

RedisAI 運行 Tensorflow 深度學習圖（以及其他一些類型）。

這些是很重要的模塊，但并不是每個引入新數據類型的模塊都必須如此復雜。有許多更簡單的數據類型可用作模塊。一個基本的示例就是 Redis 中已經存在的數據類型的不同實現，例如，使用 ArrayList 實現 List。

2、完善你的API

不要忘記模塊命令的錯誤用法與正確用法一樣重要。Redis 用戶喜歡手動調試命令以獲得更好的理解，并且會輸入一些錯誤的參數。你的 API 應該易于使用且難以濫用，但是當不可避免的情況出現時，請確保輸出的錯誤信息是有意義的。

查看 Redis 的標準命令是如何工作的，然后看看執行你自己的命令得到的結果是否符合相應的假設。這將減少使用命令所需的心理負擔。一個例子是，在 Redis 中，當調用一個不存在的鍵時，大多數命令都有合理的行為：INCR 會假定缺少的鍵值為 0，因此它會將其設置為 1，SADD 會假定缺少的鍵是空鍵，依此類推。

3、做一個好公民

模塊需要可以與 Redis 生態進行交互。確保閱讀文檔以了解如何正確獲取詳細信息，尤其是當你的模塊實現了新的數據類型時。這是兩個最重要的方面。

命令標志

聲明新的命令時，必須指定一些標志來告訴 Redis 調用命令時將要執行的操作。它是要讀取數據還是要寫入數據？是分配內存還是只是修改現有的數據？確保正確填寫這些選項。例如，在內存不足（OOM）的情況下，deny-oom 是一個重要標志，它將告訴 Redis 拒絕訪問分配內存的命令，否則整個進程將被 OOM 殺掉！即使是只讀標志也很重要。新的客戶端緩存功能將使用它來決定是否啟用對給定 key 的跟蹤。

命令復制

當 Redis 是主從模式時，主服務器必須知道應該將哪些命令發送給從服務器。并非每個命令都應復制，某些命令可能僅在特定條件下才需要復制。例如，我上面提到的 SETNE 命令，該命令僅在新值與當前值不同時才設置 key 和 value（否則它什么也不做）。在這種情況下，僅當命令有效地對 key 進行更改時，才應復制該命令。如果沒有執行任何寫操作，就不用讓每個從服務器都執行該命令。

4、撰寫出色的文檔

如果你的模塊都沒有人知道如何使用，那么無論它多么有用都沒有意義。因此完善 API 文檔會有很大幫助，至少你首先得說服潛在用戶該模塊是值得嘗試的。一個好的模塊應該具有好的文檔，這些文檔可以明確該模塊的總體目標并列出每個命令的詳細信息。

如果看一下 redis.io，你就會發現每個命令都列出了其相對的 BigO 復雜性，并在命令具有特別大或小的常量或有明顯邊界情況時提供了一些額外的說明。嘗試模仿這樣的格式，尤其是在命令示例的語法方面。請注意，每個示例都是用小寫字母命名占位符，大寫字母表示關鍵字，方括號之間是可選值。查看 SET 的文檔https://redis.io/commands/set 以查看此示例。

最重要的是：力求簡單

始終牢記，Redis 背后的第一個設計原則是簡單。這并不是說你的模塊就只有這一種選擇，偶爾還是可以為了其他好處而犧牲這種簡單性（模塊的存在正是為了讓 Redis 用戶體驗），但要時刻注意你所放棄的東西。

一般而言，當你為了方便使用而犧牲了簡單性時，也隱含地限制了用戶使用模塊的方式。在 Redis 中，大多數程序并不是單獨使用某個命令，而是將不同的命令組合在一起使用。更小，更清晰，更簡單的命令會更易于組合，因此在整體方案中會產生更好的效果。因此，我建議在進行這種權衡之前，通過適當地應用上述技術來提高易用性。

另一個潛在的權衡取舍可能是執行效率。這可能值得探索，也是 Redis 偶爾做的一個。某些內置數據類型具有兩種內部的優化方式：一種是在數據類型中只有幾個元素時進行優化，另一種針對 key 增長超過某個閾值時進行優化。兩種方式（加上在兩種方式之間進行切換的機制）肯定比只有一種方式更為復雜，但是這樣做是值得的。因為增加的復雜性不會顯示在用戶界面中，無論使用哪種內部優化的方式，用戶都將以相同的方式與數據類型進行交互。

----

來源：Redislabs

翻譯：Kevin

數據庫 Redis

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。