面試題：“選redis還是memcache”

有時，面試官並沒有對自己的提問，預設任何答案，只要候選人的思路是清晰的，邏輯是自洽的，即使給出的未必是最優的方案，也是能讓人眼前一亮。做技術方案，技術選型的時候，一定是針對業務需求來折衷的。

選型考慮因素：

• 是否需要複雜的資料結構選擇？若是則請使用Redis作為儲存，否則Redis及MC都可以考慮。若只有簡單的get/set請求，且需要較高的效能需求，可以使用MC代替Redis。
• 是否需要進行資料持久化儲存，資料不允許丟失？若是，則請使用Redis進行資料儲存，並在申請服務的時候註明需要作為儲存而非快取，需要開啟持久化儲存及資料定期備份。
• 是否需要Master/Slave機制保證服務的HA？若是，則請使用Redis進行資料儲存，平臺會預設為所有的Redis服務部署Slave從庫，以保證Master/Slave機制。
• 是否是計數服務？若是請使用Redis作為儲存，效能保證的同時開啟aof保證資料不會丟失。
• 是否需要多分片進行分散式部署？若是則請使用Twemproxy進行服務部署，使用Redis作為儲存時需考慮命令的支援程度，部分Redis的命令在Twemproxy上並不支援；否則請使用單機的Redis或MC作為儲存，或則自行在客戶端進行分片操作。平臺使用Twemproxy+MC部署的時候，會採用自動剔除異常服務例項的方式以保證整體服務的質量，剔除異常服務例項後，部分請求將會出現MISS；使用Twemproxy+Redis部署的時候會通過Redis的Master/Slave機制，在Master異常的是有自動提升Slave，以保證服務的質量。

典型使用場景：

Memcached：

• Session儲存：全站Session業務，移動WAP Session
• 移動MAPI業務

Redis：

• 計數服務
• 佇列服務：訊息佇列
• 專場列表資料（hashset，通過hashset儲存某個專場下面的所有商品）
• 集合去重：PMS用來傳送簡訊服務的Redis，使用多個集合去重以防止同一使用者收到多條簡訊，造成騷擾。

Memcached

Memcached的優點

• Memcached可以利用多核優勢，單例項吞吐量極高，可以達到幾十萬QPS（取決於key、value的位元組大小以及伺服器硬體效能，日常環境中QPS高峰大約在4-6w左右）。適用於最大程度扛量。
• 支援直接配置為session handle。
• 坑少。

Memcached的侷限性：

• 只支援簡單的key/value資料結構，不像Redis可以支援豐富的資料型別。
• 無法進行持久化，資料不能備份，只能用於快取使用，且重啟後資料全部丟失。
• 無法進行資料同步，不能將MC中的資料遷移到其他MC例項中。
• Memcached記憶體分配採用Slab Allocation機制管理記憶體，value大小分佈差異較大時會造成記憶體利用率降低，並引發低利用率時依然出現踢出等問題。需要使用者注重value設計。

Redis

Redis的優點：

• 支援多種資料結構，如 string（字串）、 list(雙向連結串列)、dict(hash表)、set(集合）、zset(排序set)、hyperloglog（基數估算）
• 支援持久化操作，可以進行aof及rdb資料持久化到磁碟，從而進行資料備份或資料恢復等操作，較好的防止資料丟失的手段。
• 支援通過Replication進行資料複製，通過master-slave機制，可以實時進行資料的同步複製，支援多級複製和增量複製，master-slave機制是Redis進行HA的重要手段。
• 單執行緒請求，所有命令序列執行，併發情況下不需要考慮資料一致性問題。
• 支援pub/sub訊息訂閱機制，可以用來進行訊息訂閱與通知。
• 支援簡單的事務需求，但業界使用場景很少，並不成熟。

Redis的侷限性：

• Redis只能使用單執行緒，效能受限於CPU效能，故單例項CPU最高才可能達到5-6wQPS每秒（取決於資料結構，資料大小以及伺服器硬體效能，日常環境中QPS高峰大約在1-2w左右）。
• 支援簡單的事務需求，但業界使用場景很少，並不成熟，既是優點也是缺點。
• Redis在string型別上會消耗較多記憶體，可以使用dict（hash表）壓縮儲存以降低記憶體耗用。

Twemproxy

Twemproxy分散式方案的優點：

• 簡單的分散式解決方案，業務方僅僅使用一個IP/PORT的對映即可（線上使用LVS+VIP+VPORT的方式部署），所有的分片資料存取都通過Twemproxy內部進行。
• Redis和Memcached都可以使用Twemproxy作為自己的分散式解決方案。
• 支援多種hash演算法，較少的效能損失。
• 可以通過擴充套件Twemproxy來解決中間層單點效能低以及HA的問題（線上業務通常使用5-10個Twemproxy，通過LVS進行負載均衡和故障轉移）
• Twemproxy內部支援簡單的後端儲存故障轉移方案，比如後端MC例項down，則可以將路由到該MC的請求轉移到其他MC例項上去。內部定製版本的Twemproxy，通過與Sentinel叢集結合，支援Redis主從方案的故障轉移，若Redis master down，則將請求路由到slave上。
• 可以簡單方便的進行後端服務的遷移、擴容等操作，不再依賴與DNS或服務配置，所有的配置變更都可以在LVS及Twemproxy上完成，對服務是透明的，業務無需關心，方便運維。

Twemproxy分散式方案的侷限性：

• 使用Redis作為後端儲存時，很多原生的Redis命令請求會受到限制，Twemproxy本身並不支援。
• Twemproxy為中間層解決方案，增加一層會導致服務請求延時增加，且Twemproxy作為中間層本身可能成為服務的瓶頸，比如CPU或流量問題，當然可以通過增加Twemproxy例項的方式解決，但響應的增加了伺服器的投入成本。
• 服務部署的難度增加，管理成本和複雜度增加，需要有快速簡單的自動化服務部署及管理方案，對運維人員的要求增大。
• Twemproxy分散式中間層多節點需要LVS的支援，LVS本身的效能限制可能造成服務瓶頸，之前發生過一次LVS網路卡丟包的問題，之後已經進行較大規模的優化和拆分。