近期公司專案在使用Redis,這幾年Redis很火，Redis也常常被當作Memcached的挑戰者被提到桌面上來。關於Redis與Memcached的比較更是比比皆是。然而，Redis真的在功能、效能以及記憶體使用效率上都超越了Memcached嗎？

• You should not care too much about performances. Redis is faster per core with small values, but memcached is able to use multiple cores with a single executable and TCP port without help from the client. Also memcached is faster with big values in the order of 100k. Redis recently improved a lot about big values (unstable branch) but still memcached is faster in this use case. The point here is: nor one or the other will likely going to be your bottleneck for the query-per-second they can deliver.

• 沒有必要過多的關心效能，因為二者的效能都已經足夠高了。由於Redis只使用單核，而Memcached可以使用多核，所以在比較上，平均每一個核上Redis在儲存小資料時比Memcached效能更高。而在100k以上的資料中，Memcached效能要高於Redis，雖然Redis最近也在儲存大資料的效能上進行優化，但是比起Memcached，還是稍有遜色。說了這麼多，結論是，無論你使用哪一個，每秒處理請求的次數都不會成為瓶頸。（比如瓶頸可能會在網路卡）

• You should care about memory usage. For simple key-value pairs memcached is more memory efficient. If you use Redis hashes, Redis is more memory efficient. Depends on the use case.
• 如果要說記憶體使用效率，使用簡單的key-value儲存的話，Memcached的記憶體利用率更高，而如果Redis採用hash結構來做key-value儲存，由於其組合式的壓縮，其記憶體利用率會高於Memcached。當然，這和你的應用場景和資料特性有關。

• You should care about persistence and replication, two features only available in Redis. Even if your goal is to build a cache it helps that after an upgrade or a reboot your data are still there.
• 如果你對資料持久化和資料同步有所要求，那麼推薦你選擇Redis，因為這兩個特性Memcached都不具備。即使你只是希望在升級或者重啟系統後快取資料不會丟失，選擇Redis也是明智的。

• You should care about the kind of operations you need. In Redis there are a lot of complex operations, even just considering the caching use case, you often can do a lot more in a single operation, without requiring data to be processed client side (a lot of I/O is sometimes needed). This operations are often as fast as plain GET and SET. So if you don’t need just GEt/SET but more complex things Redis can help a lot (think at timeline caching).
• 當然，最後還得說到你的具體應用需求。Redis相比Memcached來說，擁有更多的資料結構和並支援更豐富的資料操作，通常在Memcached裡，你需要將資料拿到客戶端來進行類似的修改再set回去。這大大增加了網路IO的次數和資料體積。在Redis中，這些複雜的操作通常和一般的GET/SET一樣高效。所以，如果你需要快取能夠支援更復雜的結構和操作，那麼Redis會是不錯的選擇。

Redis是什麼？兩句話可以做下概括： 

1. 是一個完全開源免費的key-value記憶體資料庫 
2. 通常被認為是一個資料結構伺服器，主要是因為其有著豐富的資料結構 strings、map、 list、sets、 sorted sets

 

Redis不是什麼？同樣從兩個方面來做下對比： 

1. 不是sql server、mySQL等關係型資料庫，主要原因是： 
     . redis目前還只能作為小資料量儲存（全部資料能夠載入在記憶體中） ，海量資料儲存方面並不是redis所擅長的領域 
     . 設計、實現方法很不一樣.關係型資料庫通過表來儲存資料，通過SQL來查詢資料。而Redis通上述五種資料結構來儲存資料，通過命令 來查詢資料 

2.   不是Memcached等快取系統，主要原因有以下幾個： 

     .網路IO模型方面：Memcached是多執行緒，分為監聽執行緒、worker執行緒，引入鎖，帶來了效能損耗。Redis使用單執行緒的IO複用模型，將速度優勢發揮到最大，也提供了較簡單的計算功能 

     .記憶體管理方面：Memcached使用預分配的記憶體池的方式，帶來一定程度的空間浪費 並且在記憶體仍然有很大空間時，新的資料也可能會被剔除，而Redis使用現場申請記憶體的方式來儲存資料，不會剔除任何非臨時資料 Redis更適合作為儲存而不是cache 

     .資料的一致性方面：Memcached提供了cas命令來保證.而Redis提供了事務的功能，可以保證一串 命令的原子性，中間不會被任何操作打斷 

     . 儲存方式方面：Memcached只支援簡單的key-value儲存，不支援列舉，不支援持久化和複製等功能

   一句話小結一下：Redis是一個高效能的key-value資料庫。 redis的出現，很大程度補償了memcached這類key/value儲存的不足，在部分場合可以對關聯式資料庫起到很好的補充作用。

 

Redis有什麼用？只有瞭解了它有哪些特性，我們在用的時候才能揚長避短，為我們所用 

1. 速度快：使用標準C寫，所有資料都在記憶體中完成，讀寫速度分別達到10萬/20萬 

2. 持久化：對資料的更新採用Copy-on-write技術，可以非同步地儲存到磁碟上，主要有兩種策略，一是根據時間，更新次數的快照（save 300 10 ）二是基於語句追加方式(Append-only file，aof) 

3. 自動操作：對不同資料型別的操作都是自動的，很安全 

4. 快速的主--從複製，官方提供了一個資料，Slave在21秒即完成了對Amazon網站10G key set的複製。

 
5. Sharding技術： 很容易將資料分佈到多個Redis例項中，資料庫的擴充套件是個永恆的話題，在關係型資料庫中，主要是以新增硬體、以分割槽為主要技術形式的縱向擴充套件解決了很多的應用場景，但隨著web2.0、移動網際網路、雲端計算等應用的興起，這種擴充套件模式已經不太適合了，所以近年來，像採用主從配置、資料庫複製形式的，Sharding這種技術把負載分佈到多個特理節點上去的橫向擴充套件方式用處越來越多。

 

對Redis資料庫做下小結： 

    1. 提高了DB的可擴充套件性，只需要將新加的資料放到新加的伺服器上就可以了 
    2. 提高了DB的可用性，隻影響到需要訪問的shard伺服器上的資料的使用者 
    3. 提高了DB的可維護性，對系統的升級和配置可以按shard一個個來搞，對服務產生的影響較小 
    4. 小的資料庫存的查詢壓力小，查詢更快，效能更好

 

Redis與Memcached的比較

    1.Memcached是多執行緒，而Redis使用單執行緒.

    2.Memcached使用預分配的記憶體池的方式，Redis使用現場申請記憶體的方式來儲存資料，並且可以配置虛擬記憶體。

    3.Redis可以實現持久化，主從複製，實現故障恢復。

    4.Memcached只是簡單的key與value,但是Redis支援資料型別比較多。

  

 

    Redis為單程式單執行緒模式，採用佇列模式將併發訪問變為序列訪問。Redis本身沒有鎖的概念，Redis對於多個客戶端連線並不存在競爭..redis是個單執行緒的程式，為什麼會這麼快呢?

    1、大量執行緒導致的執行緒切換開銷。
    2、鎖。
    3、非必要的記憶體拷貝。

    4. Redis多樣的資料結構，每種結構只做自己愛做的事.

    

    Hash對應的Value內部實際就是一個HashMap,實際這裡會有2種不同實現，這個HashMap的成員比較少時,Redis為了節省記憶體會採用類似一維陣列的方式來緊湊儲存，而不會採用真正的HashMap結構，當成員量增大時會自動轉成真正的HashMap.

總結： 

 要進行Master-slave配置，出現服務故障時可以支援切換。 
   在master側禁用資料持久化，只需在slave上配置資料持久化。 
     實體記憶體+虛擬記憶體不足，這個時候dump一直死著，時間久了機器掛掉。這個情況就是災難！ 
       當Redis實體記憶體使用超過記憶體總容量的3/5時就會開始比較危險了，就開始做swap,記憶體碎片大 
         當達到最大記憶體時，會清空帶有過期時間的key，即使key未到過期時間. 
            redis與DB同步寫的問題，先寫DB，後寫redis，因為寫記憶體基本上沒有問題