應用背景

有一個應用需要上傳一組ID到伺服器來查詢這些ID所對應的資料，資料庫中儲存的資料量是7千萬，每次上傳的ID數量一般都是幾百至上千數量級別。

以前的解決方案

1. 資料儲存在Oracle中，為ID建立了索引；
2. 查詢時，先將這些上傳的ID資料儲存到臨時表中，然後用表關聯的方法來查詢。

這樣做的優點是減少了查詢次數（不用每個ID都查詢一次），減少了解析SQL的時間（只需要執行1次查詢SQL，但是多了插入資料的SQL處理時間）。

但是這樣的設計仍然存在巨大的提升空間，當併發查詢的數量增加時，資料庫的響應就會很久。雖然建立了索引，但是每個ID查詢的時間複雜度仍是O(logn)級別的，那麼總的查詢時間複雜度就應該是m*O(logn)。不知道Oracle對錶關聯查詢有做了哪些優化，但應該也是改變不了時間複雜度的級別。

解決方法

一遇到讀資料庫存在瓶頸的問題，首先想到的就是要用記憶體資料庫，用快取來解決。首選 Redis，因為Redis是一種提供了豐富資料結構的key-value資料庫，value可以儲存STRING（字串）、HASH（雜湊），LIST（列表），ZSET（有序集）。

首先需要將資料的儲存改成 key-value 架構。簡單的做法就是一個ID對應一個字串的 Value。但是一個 ID 可以對應多條資料，而且一條資料內又可以包含多個欄位。這時候就需要將這些資料重新組合一下，拼在一起，或者是採用列表、雜湊或集合來儲存 Value。

Redis內部採用 HashTable（雜湊表）來實現key-value的資料結構，是一種空間佔用較高的資料結構。而我的應用場景又是ID有幾千萬規模的，如果按上述方法，使用每個ID作為key，那麼記憶體的消耗將是巨大的。每個key-vaulue結構，

使用兩級Hash優化記憶體

依據官方文件的記憶體優化方法，以及這篇文章 節約記憶體：Instagram的Redis實踐，建議對ID分段作為key，並使用 hash 來儲存第一級 key 的 value，第二級儲存較少的資料量（推薦1000），因此第二級的key使用ID的後3位。

為了節約記憶體，Redis預設使用ziplist（壓縮列表）來儲存HASH（雜湊），LIST（列表），ZSET（有序集）這些資料結構。當某些條件被滿足時，自動轉換成 hash table（雜湊表），linkedlist（雙端列表），skiplist（跳錶）。

ziplist是用一個數組來實現的雙向連結串列結構，顧名思義，使用ziplist可以減少雙向連結串列的儲存空間，主要是節省了連結串列指標的儲存，如果儲存指向上一個連結串列結點和指向下一個連結串列結點的指標需要8個位元組，而轉化成儲存上一個結點長度和當前結點長度在大多數情況下可以節省很多空間（最好的情況下只需2個位元組）。但是每次向連結串列增加元素都需要重新分配記憶體。—— 引用自這裡的描述

檢視 Redis 的 .conf 檔案，可以檢視到轉換條件的設定資訊。

# Hashes are encoded using a memory efficient data structure when they have a
# small number of entries, and the biggest entry does not exceed a given
# threshold. These thresholds can be configured using the following directives.
hash-max-ziplist-entries 512
hash-max-ziplist-value 64

# Similarly to hashes, small lists are also encoded in a special way in order
# to save a lot of space. The special representation is only used when
# you are under the following limits:
list-max-ziplist-entries 512
list-max-ziplist-value 64

# Similarly to hashes and lists, sorted sets are also specially encoded in
# order to save a lot of space. This encoding is only used when the length and
# elements of a sorted set are below the following limits:
zset-max-ziplist-entries 128
zset-max-ziplist-value 64

ziplist 查詢的時間複雜度是 O(N)，但是資料量較少，第二級Hash的查詢速度依然在O(1)級別。

對第二級Hash儲存的資料再編碼

在我的應用場景中每個ID對應的資料可以有很多個欄位，這些欄位有很多實際上是型別資料，儲存的也是ID。為了進一步節約記憶體，對這些使用數字作為ID的欄位，採用base62編碼（0-9，A-Z，a-z），這樣可以使這些ID的字元長度變短，進一步減少在Redis中第二級hash需要儲存的資料量，從而減少Redis佔用的記憶體。

使用Lua指令碼來處理批量操作

由於每次查詢都上傳幾百上千個ID，如果對這些ID，都單獨呼叫一次HGET命令，那麼一次查詢就需要上千次TCP通訊，速度很慢。這個時候最好的方法就是一次性將所有的查詢都發送到 Redis Server，然後在 Redis Server 處再依次執行HGET命令，這個時候就要用到 Redis 的Pipelining（管道），Lua 指令碼（需要 Redis 2.6以上版本）。這兩項功能可以用來處理批量操作。由於Lua指令碼更簡單好用，因此我就直接選用Lua指令碼。

Redis Lua 指令碼具有原子性，執行過程會鎖住 Redis Server，因此 Redis Server 會全部執行完 Lua 腳本里面的所有命令，才會去處理其他命令請求，不用擔心併發帶來的共享資源讀寫需要加鎖問題。實際上所有的 Redis 命令都是原子的，執行任何 Redis 命令，包括 info，都會鎖住 Redis Server。

不過需要注意的是：

為了防止某個指令碼執行時間過長導致Redis無法提供服務（比如陷入死迴圈），Redis提供了lua-time-limit引數限制指令碼的最長執行時間，預設為5秒鐘（見.conf配置檔案）。當指令碼執行時間超過這一限制後，Redis將開始接受其他命令但不會執行（以確保指令碼的原子性，因為此時指令碼並沒有被終止），而是會返回"BUSY"錯誤——引用自這裡的描述

遇到這種情況，就需要使用 SCRIPT KILL 命令來終止 Lua 指令碼的執行。因此，千萬要注意 Lua 指令碼不能出現死迴圈，也不要用來執行費時的操作。

效能分析

測試環境：

• 記憶體：1333MHz
• CPU：Intel Core i3 2330M 2.2GHz
• 硬碟：三星 SSD

實驗基本設定：

1. 將7000萬資料按照上面描述的方法，使用兩級Hash以及對資料再編碼，儲存到Redis中。
2. 模擬資料請求（沒有通過HTTP請求，直接函式呼叫），查詢資料，生成響應的JSON資料。

（資料僅供參考，因為未真正結合Web伺服器進行測試）

使用上述方法，對Redis的記憶體優化效果非常好。

實驗設定：

1. 模擬每次查詢500個ID，分批次連續查詢。用於模擬測試併發情況下的查詢效能。

響應速度與查詢的資料量，幾乎是線性相關。30s 的時間就可以處理2000次請求，100W個ID的查詢。由於Oracle速度實在太慢，就不做測試了。

實驗設定：

1. 連續查詢1W個ID，每次500個，分20次。用於測試Redis中儲存的資料量對查詢效能的影響。

查詢速度受儲存資料量的影響較小。當儲存的資料量較多時，第二級hash儲存的資料量就會更多，因此查詢時間會有略微的上升，但依然很快。

參考文獻