再說一遍和迷迷糊糊的的區(qū)別

關于再說一遍和迷迷糊糊的的區(qū)別這個問題很多朋友還不知道，今天小六來為大家解答以上的問題，現(xiàn)在讓我們一起來看看吧！

1、如果簡單地比較Redis與Memcached的區(qū)別，大多數(shù)都會得到以下觀點：1 Redis不僅僅支持簡單的k/v類型的數(shù)據(jù)，同時還提供list，set，hash等數(shù)據(jù)結構的存儲。

2、2 Redis支持數(shù)據(jù)的備份，即master-slave模式的數(shù)據(jù)備份。

3、3 Redis支持數(shù)據(jù)的持久化，可以將內存中的數(shù)據(jù)保持在磁盤中，重啟的時候可以再次加載進行使用。

4、在Redis中，并不是所有的數(shù)據(jù)都一直存儲在內存中的。

5、這是和Memcached相比一個最大的區(qū)別（我個人是這么認為的）。

6、Redis只會緩存所有的key的信息，如果Redis發(fā)現(xiàn)內存的使用量超過了某一個閥值，將觸發(fā)swap的操作，Redis根據(jù)“swappability = age*log(size_in_memory)”計算出哪些key對應的value需要swap到磁盤。

7、然后再將這些key對應的value持久化到磁盤中，同時在內存中清除。

8、這種特性使得Redis可以保持超過其機器本身內存大小的數(shù)據(jù)。

9、當然，機器本身的內存必須要能夠保持所有的key，畢竟這些數(shù)據(jù)是不會進行swap操作的。

10、同時由于Redis將內存中的數(shù)據(jù)swap到磁盤中的時候，提供服務的主線程和進行swap操作的子線程會共享這部分內存，所以如果更新需要swap的數(shù)據(jù)，Redis將阻塞這個操作，直到子線程完成swap操作后才可以進行修改。

11、可以參考使用Redis特有內存模型前后的情況對比：VM off: 300k keys, 4096 bytes values: 1.3G usedVM on: 300k keys, 4096 bytes values: 73M usedVM off: 1 million keys, 256 bytes values: 430.12M usedVM on: 1 million keys, 256 bytes values: 160.09M usedVM on: 1 million keys, values as large as you want, still: 160.09M used 當從Redis中讀取數(shù)據(jù)的時候，如果讀取的key對應的value不在內存中，那么Redis就需要從swap文件中加載相應數(shù)據(jù)，然后再返回給請求方。

12、這里就存在一個I/O線程池的問題。

13、在默認的情況下，Redis會出現(xiàn)阻塞，即完成所有的swap文件加載后才會相應。

14、這種策略在客戶端的數(shù)量較小，進行批量操作的時候比較合適。

15、但是如果將Redis應用在一個大型的網(wǎng)站應用程序中，這顯然是無法滿足大并發(fā)的情況的。

16、所以Redis運行我們設置I/O線程池的大小，對需要從swap文件中加載相應數(shù)據(jù)的讀取請求進行并發(fā)操作，減少阻塞的時間。

17、redis、memcache、mongoDB 對比從以下幾個維度，對redis、memcache、mongoDB 做了對比，歡迎拍磚性能都比較高，性能對我們來說應該都不是瓶頸總體來講，TPS方面redis和memcache差不多，要大于mongodb2、操作的便利性memcache數(shù)據(jù)結構單一redis豐富一些，數(shù)據(jù)操作方面，redis更好一些，較少的網(wǎng)絡IO次數(shù)mongodb支持豐富的數(shù)據(jù)表達，索引，最類似關系型數(shù)據(jù)庫，支持的查詢語言非常豐富3、內存空間的大小和數(shù)據(jù)量的大小redis在2.0版本后增加了自己的VM特性，突破物理內存的限制；可以對key value設置過期時間（類似memcache）memcache可以修改最大可用內存,采用LRU算法mongoDB適合大數(shù)據(jù)量的存儲，依賴操作系統(tǒng)VM做內存管理，吃內存也比較厲害，服務不要和別的服務在一起4、可用性（單點問題）對于單點問題，redis，依賴客戶端來實現(xiàn)分布式讀寫；主從復制時，每次從節(jié)點重新連接主節(jié)點都要依賴整個快照,無增量復制，因性能和效率問題，所以單點問題比較復雜；不支持自動sharding,需要依賴程序設定一致hash 機制。

18、一種替代方案是，不用redis本身的復制機制，采用自己做主動復制（多份存儲），或者改成增量復制的方式（需要自己實現(xiàn)），一致性問題和性能的權衡Memcache本身沒有數(shù)據(jù)冗余機制，也沒必要；對于故障預防，采用依賴成熟的hash或者環(huán)狀的算法，解決單點故障引起的抖動問題。

19、mongoDB支持master-slave,replicaset（內部采用paxos選舉算法，自動故障恢復）,auto sharding機制，對客戶端屏蔽了故障轉移和切分機制。

20、5、可靠性（持久化）對于數(shù)據(jù)持久化和數(shù)據(jù)恢復，redis支持（快照、AOF）：依賴快照進行持久化，aof增強了可靠性的同時，對性能有所影響memcache不支持，通常用在做緩存,提升性能；MongoDB從1.8版本開始采用binlog方式支持持久化的可靠性6、數(shù)據(jù)一致性（事務支持）Memcache 在并發(fā)場景下，用cas保證一致性redis事務支持比較弱，只能保證事務中的每個操作連續(xù)執(zhí)行mongoDB不支持事務7、數(shù)據(jù)分析mongoDB內置了數(shù)據(jù)分析的功能(mapreduce),其他不支持8、應用場景redis：數(shù)據(jù)量較小的更性能操作和運算上memcache：用于在動態(tài)系統(tǒng)中減少數(shù)據(jù)庫負載，提升性能;做緩存，提高性能（適合讀多寫少，對于數(shù)據(jù)量比較大，可以采用sharding）MongoDB:主要解決海量數(shù)據(jù)的訪問效率問題。

本文分享完畢，希望對大家有所幫助。

標簽：