節約記憶體：Instagram的Redis實踐

轉自：http://blog.nosqlfan.com/html/3379.html?ref=rediszt

Instagram可以說是網拍App的始祖級應用，也是當前最火熱的拍照App之一，Instagram的照片數量已經達到3億，而在Instagram裡，我們需要知道每一張照片的作者是誰，下面就是Instagram團隊如何使用Redis來解決這個問題並進行記憶體最佳化的。

首先，這個通過圖片ID反查使用者UID的應用有以下幾點需求：

• 查詢速度要足夠快
• 資料要能全部放到記憶體裡，最好是一台EC2的 high-memory 機型就能儲存（17GB或者34GB的，68GB的太浪費了）
• 要合適Instagram現有的架構（Instagram對Redis有一定的使用經驗，比如這個應用）
• 支援持久化，這樣在伺服器重啟後不需要再預熱

Instagram的開發人員首先否定了資料庫儲存的方案，他們保持了KISS原則（Keep It Simple and Stupid），因為這個應用根本用不到資料庫的update功能，事務功能和關聯查詢等等牛X功能，所以不必為這些用不到的功能去選擇維護一個資料庫。

於是他們選擇了Redis，Redis是一個支援持久化的記憶體資料庫，所有的資料都被儲存在記憶體中（忘掉VM吧），而最簡單的實現就是使用Redis的String結構來做一個key-value儲存就行了。像這樣：

SET media:1155315 939GET 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"

最佳化無止境，只要肯琢磨。希望你在使用儲存產品時也能如此愛惜記憶體。

來源：instagram-engineering.tumblr.com