有時，面試官並沒有對自己的提問，預設任何答案，只要候選人的思路是清晰的，邏輯是自洽的，即使給出的未必是最優的方案，也是能讓人眼前一亮。做技術方案，技術選型的時候，一定是針對業務需求來折衷的。
選型考慮因素：
- 是否需要複雜的資料結構選擇？若是則請使用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網路卡丟包的問題，之後已經進行較大規模的優化和拆分。