面試題：「選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網卡丟包的問題，以後已經進行較大規模的優化和拆分。