緩存選型方案

本文檔用於在決定緩存選型方案時用於討論使用Memcached還是Redis，以及何時選擇使用Twemproxy+ MC/Redis的分佈式部署方案（Mongodb等NewSQL服務暫不列入考慮之中）

1.Memcached的優點：

Memcached可以利用多核優勢，單實例吞吐量極高，可以達到幾十萬QPS（取決於key、value的字節大小以及服務器硬件性能，日常環境中QPS高峯大約在4-6w左右）。適用於最大程度扛量。
支持直接配置爲session handle。
坑少。

2.Memcached的侷限性：

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

3.Redis的優點：

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

4.Redis的侷限性：

Redis只能使用單線程，性能受限於CPU性能，故單實例CPU最高才可能達到5-6wQPS每秒（取決於數據結構，數據大小以及服務器硬件性能，日常環境中QPS高峯大約在1-2w左右）。

5.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上完成，對服務是透明的，業務無需關心，方便運維。

6.Twemproxy分佈式方案的侷限性：

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

選型考慮因素：

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

典型使用場景：

Memcached：

Redis：