首先，這個透過圖片ID反查用戶UID的應用程式有以下幾點需求：
先否定了資料庫儲存的方案，他們保持了KISS原則（Keep It Simple and Stupid），因為這個應用根本用不到資料庫的update功能，事務功能和關聯查詢等等牛X功能，所以不必為這些用不到的功能去選擇維護一個資料庫。
於是他們選擇了Redis，Redis是一個支援持久化的記憶體資料庫，所有的資料都儲存在記憶體中（忘記VM吧），而最簡單的實作就是使用Redis的String結構來做一個key-value儲存就行了。像這樣：
SET media:1155315 939
GET media:1155315
> 939
登入後複製
其中1155315是圖片ID，939是用戶ID，我們將每一張圖片ID為作key，用戶uid作為value來存成key-value對。然後他們進行 了測試，將數據按上面的方法存儲，1,000,000數據會用掉70MB內存，300,000,000張照片就會用掉21GB的內存。比較預算的17GB 還是超支了。
（NoSQLFan：其實這裡我們可以看到一個最佳化點，我們可以將key值前面相同的media去掉，只存數字，這樣key的長度就減少了，減少key值對記憶體的開銷【註：Redis的key值不會做字串到數字的轉換，所以這裡節省的，只是media:這6個位元組的開銷】。經過實驗，記憶體佔用會降到50MB，總的記憶體佔用是15GB ，是滿足需求的，但是Instagram後面的改進任然有必要）
於是Instagram的開發者向Redis的開發者之一Pieter Noordhuis詢問優化方案，得到的回復是使用Hash結構。具體的做法就是將資料分段，每一段使用一個Hash結構存儲，由於Hash結構會在單一Hash元素在不足一定數量時進行壓縮存儲，所以可以大量節約記憶體。這一點在上面的String結構裡是不存在的。設定檔中的"hash-zipmap-max-entries"參數控制著一定數量。經過開發者們的實驗，將hash-zipmap-max-entries設定為1000時，效能比較好，超過1000後HSET指令就會導致CPU消耗變得非常大。
於是他們改變了方案，將資料存成如下結構：
HSET "mediabucket:1155" "1155315" "939"
HGET "mediabucket:1155" "1155315"
> "939"
登入後複製
透過取7位元的圖片ID的前四位為Hash結構的key值，保證了每個Hash內部只包含3位的key，也就是1000個。
在進行另一次試驗後，發現每1,000,000個key只消耗了16MB的記憶體。總記憶體使用也降到了5GB，滿足了應用需求。
（NoSQLFan： 同樣的，這裡我們還是可以再進行最佳化，首先是將Hash結構的key值變成純數字，這樣key長度減少了12個位元組，其次是將Hash結構中的subkey值變成三位數，這又減少了4個位元組的開銷，如下所示。經過實驗，記憶體佔用量會降到10MB，總記憶體佔用為3GB）
HSET "1155" "315" "939"
HGET "1155" "315"
> "939"
登入後複製
以上是Redis如何節約內存的詳細內容。更多資訊請關注PHP中文網其他相關文章！
