redis和memcached選擇，對比分析

   memcache和redis是互聯網分層架構中，最經常使用的KV緩存。很多同窗在選型的時候會糾結，究竟是選擇memcache仍是redis？

   memcache提供的功能是redis提供的功能的子集，不用想太多，選redis準沒錯？

   

redis傾向：

   複雜的數據結構：value是哈希，列表，集合，有序集合這類複雜的數據結構時，會選擇redis，由於mc沒法知足這些需求。用戶訂單列表，用戶消息，帖子評論列表等。

   持久化： mc沒法知足持久化的需求，只得選擇redis。可是千萬不要把redis真的作數據庫用

                     a. redis的按期快照不能保證數據不丟失

                     b.redis的AOF會下降效率，而且不能支持太大的數據量

                     c.不要指望redis作固化存儲會比mysql作得好，不一樣的工具作各自擅長的事情

                     d.redis掛掉重啓後可以快速恢復熱數據，可是若是着期間有數據修改，可能致使數據不一致，所以，只讀場景，或者容許一些不一致的業務場景，能夠嘗試開啓redis的固化功能

   自帶高可用集羣： redis自身支持集羣，實現主從讀寫分離功能，官方也提供sentinal哨兵的集羣管理工具，實現主從監控，故障轉移，memcached實現集羣須要二次開發了

                            可是不少時候須要考慮，真的須要高可用麼？緩存不少時候是運行cache miss的，cache掛了能夠讀db的

  存儲的內容比較大 ： macache 單個value最大存儲 1M，超過1M只能用redis了。

            注意：純的k-v 並且數據量特別大，併發也很大 或許使用memcache更合適

                      a.內存分配：memcache使用 預分配內存池的煩事管理內存，更節省內存分配時間，redis使用臨時申請的方式，kennel致使碎片。對比看memcache更快一點

                      b.memcache把全部的數據存儲在物理內存裏。redis有本身的VM機制，理論上可以存儲比物理內存更多的數據，當數據超量時，會引起swap，把冷數據刷到磁盤上。對比看數據量大時，memcache更快一點

                      c.memcache使用非阻塞IO複用模型，redis也是使用非阻塞IO複用模型,但因爲redis還提供一些非KV存儲以外的排序，聚合功能，在執行這些功能時，複雜的CPU計算，會阻塞整個IO調度。從這一點上，因爲redis提供的功能較多，mc會更快一些。

                      d.memcache使用多線程，主線程監聽，worker子線程接受請求，執行讀寫，這個過程當中，可能存在鎖衝突。redis使用單線程，雖無鎖衝突，但難以利用多核的特性提高總體吞吐量。從這一點上，mc會快一些。

 

    代碼可讀性，代碼質量:看過mc和redis的代碼，從可讀性上說，redis是我見過代碼最清爽的軟件，甚至沒有之一，或許簡單是redis設計的初衷，編譯redis甚至不須要configure，不須要依賴第三方庫，一個make就搞定了。而memcache，多是考慮了太多的擴展性，多系統的兼容性，代碼不清爽，看起來費勁。