使用Redis之前5個必須瞭解的事情

【轉自Dataguru】
使用Redis開發應用程式是一個很愉快的過程，但是就像其他技術一樣，基於Redis的應用程式設計你同樣需要牢記幾點。在之前，你可能已經對關係型資料庫開發的那一整個套路瞭然如胸，而基於Redis的應用程式開發也有許多相似的地方，但是你必須牢記以下兩點——Redis是個記憶體資料庫，同時它是單執行緒的。因此，在使用Redis時，你需要注意以下幾點：

1. 掌控儲存在Redis中的所有鍵

資料庫的主要功能是儲存資料，但是對於開發者來說，因為應用程式需求或者資料使用方法的改變，忽略儲存在資料庫中的某些資料是非常正常的，在Redis中同樣如此。你可能忽視期滿某些鍵，也可能因為應用程式的某個模組棄用而忘掉這些資料。

無論哪種情況，Redis都儲存了一些不再使用的資料，平白無故的佔用了一些空間。Redis的弱結構資料模式讓集中儲存的內容很難被弄清，除非你為鍵使用一套非常成熟的命名法則。使用合適的命名方法會簡化你的資料庫管理，當你透過你的應用程式或者服務做鍵的名稱空間時（通常情況下是使用冒號來劃分鍵名），你就可以在資料遷移、轉換或者刪除時輕鬆的識別。

Redis另一個常見用例是作為熱資料項作的第二資料儲存，大部分的資料被儲存在其他的資料庫中，比如PostgreSQL或MongoDB。在這些用例中，當資料從主儲存移除時，開發者經常會忘記刪除Redis中對應的資料。這種存在跨資料儲存的情況下，通常需要做級聯刪除，這種情況下，可以透過在Redis配置儲存特定資料項的所有識別符來實現，從而保證資料在主資料庫被刪除後，系統會呼叫一個清理程式來刪除所有相關副本和資訊。

2. 控制所有鍵名的長度

在上文我們說過要使用合適的命名規則，並且新增字首來識別資料走向，因此這一條看起來似乎與之違背。但是，請別忘記，Redis是個記憶體資料庫，鍵越短你需要的空間就越少。理所當然，當資料庫中擁有數百萬或者數十億鍵時，鍵名的長度將影響重大。

舉個例子：在一個32位的Redis伺服器上，如果儲存一百萬個鍵，每個值的長度是32-character，那麼在使用6-character長度鍵名時，將會消耗大約96MB的空間，但是如果使用12-character長度的鍵名時，空間消耗則會提升至111MB左右。隨著鍵的增多，15%的額外開銷將產生重大的影響。

3. 使用合適的資料結構

不管是記憶體使用或者是效能，有的時候資料結構將產生很大的影響，下面是一些可以參考的最佳實踐：

取代將資料儲存為數千（或者數百萬）獨立的字串，可以考慮使用雜湊資料結構將相關資料進行分組。雜湊表是非常有效率的，並且可以減少你的記憶體使用；同時，雜湊還更有益於細節抽象和程式碼可讀。

合適時候，使用list代替set。如果你不需要使用set特性，List在使用更少記憶體的情況下可以提供比set更快的速度。

Sorted sets是最昂貴的資料結構，不管是記憶體消耗還是基本操作的複雜性。如果你只是需要一個查詢記錄的途徑，並不在意排序這樣的屬性，那麼輕建議使用雜湊表。

Redis中一個經常被忽視的功能就是bitmaps或者bitsets（V2.2之後）。Bitsets允許你在Redis值上執行多個bit-level操作，比如一些輕量級的分析。

4. 使用SCAN時別使用鍵

從Redis v2.8開始，SCAN命令已經可用，它允許使用遊標從keyspace中檢索鍵。對比KEYS命令，雖然SCAN無法一次性返回所有匹配結果，但是卻規避了阻塞系統這個高風險，從而也讓一些操作可以放在主節點上執行。

需要注意的是，SCAN命令是一個基於遊標的迭代器。SCAN命令每次被呼叫之後，都會向使用者返回一個新的遊標，使用者在下次迭代時需要使用這個新遊標作為SCAN命令的遊標引數，以此來延續之前的迭代過程。同時，使用SCAN，使用者還可以使用keyname模式和count選項對命令進行調整。

SCAN相關命令還包括SSCAN命令、HSCAN命令和ZSCAN命令，分別用於集合、雜湊鍵及有續集等。

5. 使用伺服器端Lua指令碼

在Redis使用過程中，Lua指令碼的支援無疑給開發者提供一個非常友好的開發環境，從而大幅度解放使用者的創造力。如果使用得當，Lua指令碼可以給效能和資源消耗帶來非常大的改善。取代將資料傳送給CPU，指令碼允許你在最接近資料的地方執行邏輯，從而減少網路延時和資料的冗餘傳輸。

在Redis中，Lua一個非常經典的用例就是資料過濾或者將資料聚合到應用程式。透過將處理工作流封裝到一個指令碼中，你只需要呼叫它就可以在更短的時間內使用很少的資源來獲取一個更小的答案。

專家提示：Lua確實非常棒，但是同樣也存在一些問題，比如很難進行錯誤報告和處理。一個明智的方法就是使用Redis的Pub/Sub功能，並且讓指令碼透過專用通道來推送日誌訊息。然後建立一個訂閱者程式，並進行相應的處理。