節約內存：Instagram的Redis實踐

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 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"

優化無止境，只要肯琢磨。但願你在使用存儲產品時也能如此愛惜內存。

來源：instagram-engineering.tumblr.com