mongodb，redis，memcached，mysql對比

 

 

一、性能
都比較高，性能對咱們來講應該都不是瓶頸
整體來說，TPS方面redis和memcache差很少，要大於mongodb

二、操做的便利性
memcache數據結構單一
redis豐富一些，數據操做方面，redis更好一些，較少的網絡IO次數
mongodb支持豐富的數據表達，索引，最相似關係型數據庫，支持的查詢語言很是豐富
mysql是持久化存儲，存放在磁盤裏面，檢索的話，會涉及到必定的IO瓶頸。
推理到redis+mysql，它是內存+磁盤關係的一個映射，mysql放在磁盤，redis放在內存，這樣的話，web應用每次只訪問redis，若是沒有找到的數據，纔去訪問Mysql。

三、內存空間的大小和數據量的大小
redis在2.0版本後增長了本身的VM特性，突破物理內存的限制；能夠對key value設置過時時間（相似memcache）
memcache能夠修改最大可用內存,採用LRU算法
mongoDB適合大數據量的存儲，依賴操做系統VM作內存管理，採用鏡像文件存儲，吃內存也比較厲害，服務不要和別的服務在一塊兒，官方建議獨立部署在64位系統（32位有最大2.5G文件限制，64位沒有改限制）

當物理內存不夠用的時候，redis和mongodb都會使用虛擬內存。當物理內存和虛擬內存都不夠用的時候，估計除了mysql你沒什麼好選擇了。其實，從數據存儲原理來看，我更傾向於將mongodb歸類爲硬盤數據庫，可是使用了mmap做爲加速的手段而已。

四、可用性（單點問題）
對於單點問題，
redis，依賴客戶端來實現分佈式讀寫；主從複製時，每次從節點從新鏈接主節點都要依賴整個快照,無增量複製，因性能和效率問題，因此單點問題比較複雜；不支持自動sharding,須要依賴程序設定一致hash 機制。
一種替代方案是，不用redis自己的複製機制，採用本身作主動複製（多份存儲），或者改爲增量複製的方式（須要本身實現），一致性問題和性能的權衡。
Memcache自己沒有數據冗餘機制，也不必；對於故障預防，採用依賴成熟的hash或者環狀的算法，解決單點故障引發的抖動問題。
mongoDB支持master-slave,replicaset（內部採用paxos選舉算法，自動故障恢復）,auto sharding機制，對客戶端屏蔽了故障轉移和切分機制。MongoDB優於Redis；單點問題上，MongoDB應用簡單，相對用戶透明，Redis比較複雜，須要客戶端主動解決。（MongoDB 通常會使用replica sets和sharding功能結合，replica sets側重高可用性及高可靠性，而sharding側重於性能、易擴展）

五、可靠性（持久化）
對於數據持久化和數據恢復，
redis支持（快照、AOF）：依賴快照進行持久化，aof加強了可靠性的同時，對性能有所影響
memcache不支持，一般用在作緩存,提高性能；
MongoDB從1.8版本開始採用binlog方式（MySQL一樣採用該方式）支持持久化的可靠性,mongodb的全部數據其實是存放在硬盤的，全部要操做的數據經過mmap的方式映射到內存某個區域內。mmap數據flush到硬盤以前，系統宕機了，數據就會丟失。

六、數據一致性（事務支持）
Memcache 在併發場景下，用cas保證一致性
redis事務支持比較弱，只能保證事務中的每一個操做按順序連續執行
mongoDB不支持事物，靠客戶端自身保證

七、數據分析
mongoDB內置了數據分析的功能(mapreduce),其餘不支持

八、應用場景
redis：數據量較小的更性能操做和運算上，
memcache：用於在動態系統中減小數據庫負載，提高性能;作緩存，提升性能（適合讀多寫少，對於數據量比較大，能夠採用sharding）
MongoDB:主要解決海量數據的訪問效率問題

11.數據結構：
memcache只是提供了簡單的數據結構，好比 string存儲。
Redis不只僅支持簡單的k/v類型的數據，同時還提供 string（字符串）、 list(雙向鏈表)、dict(hash表)、set(集合）、zset(排序set)、hyperloglog（基數估算）等數據結構的存儲。。

 

 

 

 

 

 

Mongodb和Memcached不是一個範疇內的東西。Mongodb是文檔型的非關係型數據庫，其優點在於查詢功能比較強大，能存儲海量數據。Mongodb 和 Memcached不存在誰替換誰的問題。 

Memcached 和 Redis它們都是內存型數據庫，數據保存在內存中，經過tcp直接存取，優點是速度快，併發高。 

Memcached 是一個高性能的分佈式內存對象緩存系統，用於動態Web應用以減輕數據庫負載。它經過在內存中緩存數據和對象來減小讀取數據庫的次數，從而提供動態、數據庫驅動網站的速度。 

Memcached 的分佈式不是在服務器端實現的，而是在客戶端應用中實現的，即經過內置算法制定目標數據的節點，Memcached 的分佈式是基於客戶端的Key的hash來作均衡，是個僞分佈式的系統。 

Redis是一個key-value存儲系統。和 Memcached 相似，它支持存儲的value類型相對更多，包括string(字符串)、 list(鏈表)、set(集合)和zset(有序集合)。這些數據類型都支持push/pop、add/remove及取交集並集和差集及更豐富的操做，並且這些操做都是原子性的。在此基礎上，Redis支持各類不一樣方式的排序。與 Memcached 同樣，爲了保證效率，數據都是緩存在內存中。區別的是Redis會週期性的把更新的數據寫入磁盤或者把修改操做寫入追加的記錄文件。 

 

 

 

 

總結： 
    • 沒有必要過於關注性能，由於兩者的性能都已經足夠高了。因爲Redis只使用單核，而Memcached可使用多核，Memcached能夠利用多核優點，單實例吞吐量極高，能夠達到幾十萬QPS（取決於key、value的字節大小以及服務器硬件性能，平常環境中QPS高峯大約在4-6w左右），適用於最大程度扛量，因此兩者比較起來，平均每個核上，Redis在存儲小數據時比Memcached性能更高。而在100k以上的數據中，Memcached性能要高於Redis。雖然Redis最近也在存儲大數據的性能上進行優化，可是比起Memcached，仍是稍有遜色。說了這麼多，結論是，不管你使用哪個，每秒處理請求的次數都不會成爲瓶頸。 
    • 在內存使用效率上，若是使用簡單的key-value存儲，Memcached的內存利用率更高。而若是Redis採用hash結構來作key-value存儲，因爲其組合式的壓縮，其內存利用率會高於Memcached。固然，這和你的應用場景和數據特性有關。 
    • 若是你對數據持久化和數據同步有所要求，那麼推薦你選擇Redis。由於這兩個特性Memcached都不具有。即便你只是但願在升級或者重啓系統後緩存數據不會丟失，選擇Redis也是明智的。 
    • 固然，最後還得說到你的具體應用需求。Redis相比Memcached來講，擁有更多的數據結構，並支持更豐富的數據操做。一般在Memcached裏，你須要將數據拿到客戶端來進行相似的修改再set回去。這大大增長了網絡IO的次數和數據體積。在Redis中，這些複雜的操做一般和通常的GET/SET同樣高效。因此，若是你須要緩存可以支持更復雜的結構和操做，那麼Redis會是不錯的選擇。

    • memcached支持直接配置爲session handle

 

 

 

 

>>Memcached的侷限性：
只支持簡單的key/value數據結構，不像Redis能夠支持豐富的數據類型。
沒法進行持久化，數據不能備份，只能用於緩存使用，且重啓後數據所有丟失。
沒法進行數據同步，不能將MC中的數據遷移到其餘MC實例中。
Memcached內存分配採用Slab Allocation機制管理內存，value大小分佈差別較大時會形成內存利用率下降，並引起低利用率時依然出現踢出等問題。須要用戶注重value設計。

>>Redis的侷限性：
Redis只能使用單線程，性能受限於CPU性能，故單實例CPU最高才可能達到5-6wQPS每秒（取決於數據結構，數據大小以及服務器硬件性能，平常環境中QPS高峯大約在1-2w左右）,併發狀況下不須要考慮數據一致性問題，。
支持簡單的事務需求，但業界使用場景不多，並不成熟，既是優勢也是缺點。
Redis在string類型上會消耗較多內存，可使用dict（hash表）壓縮存儲以下降內存耗用。
Mc和Redis都是Key-Value類型，不適合在不一樣數據集之間創建關係，也不適合進行查詢搜索。好比redis的keys pattern這種匹配操做，對redis的性能是災難。

>>mongoDB
mongoDB 是一種文檔性的數據庫。先解釋一下文檔的數據庫，便可以存放xml、json、bson類型系那個的數據。
這些數據具有自述性（self-describing），呈現分層的樹狀數據結構。redis能夠用hash存放簡單關係型數據。
mongoDB 存放json格式數據。
適合場景：事件記錄、內容管理或者博客平臺，好比評論系統。

 

 

 

 

 

MongoDB和Redis區別
MongoDB更相似Mysql，支持字段索引、遊標操做，其優點在於查詢功能比較強大，擅長查詢xml、json、bson數據，能存儲海量數據，可是不支持事務。
Mysql在大數據量時效率顯著降低，MongoDB更多時候做爲關係數據庫的一種替代。

內存管理機制
Redis數據所有存在內存，按期寫入磁盤，當內存不夠時，能夠選擇指定的LRU算法刪除數據。
MongoDB數據存在內存，由linux系統mmap實現，當內存不夠時，只將熱點數據放入內存，其餘數據存在磁盤。

支持的數據結構
Redis支持的數據結構豐富，包括hash、set、list等。
MongoDB數據結構比較單一，可是支持豐富的數據表達，索引，最相似關係型數據庫，支持的查詢語言很是豐富。

性能
兩者性能都比較高，應該說都不會是瓶頸。

可靠性
兩者均支持持久化。

集羣
MongoDB集羣技術比較成熟，Redis從3.0開始支持集羣。

不適用場景
Ø 須要使用複雜sql的操做
Ø 事務性系統

 

 

 

 

Redis很適合用來作緩存，但除此以外，它實際上還能夠在一些「讀寫分離」的場景下做爲「讀庫」來用，特別是用來存放Hadoop或Spark的分析結果。
Redis的讀寫性能在100,000 ops/s左右，時延通常爲10～70微妙左右；而HBase的單機讀寫性能通常不會超過1,000ops/s，時延則在1～5毫秒之間。
Redis的魅力還在於它不像HBase只支持簡單的字符串，他還支持集合set，有序集合zset和哈希hash
Redis適合存儲全局變量，好比微信token每兩小時刷新一次，就比較適合用redis存儲，讀也比較方便。
hbase是列數據庫，不支持二級索引，寫性能高，適合寫多讀少的業務場景，可用來存儲BI數據。
mongodb 適合存儲json類型數據，不常常變化，好比排行榜，天天刷新一次，remove一次再從db更新過去。Hbase暫時沒用過。
mongodb主要是作社交這一類的應用。redis是個in memory cache，主要做爲軟件裏一個部件來提高總體性能的。

MongoDB在A:{B,C}上創建索引，查詢A:{B,C}和A:{C,B}都會使用索引嗎？不會，只會在A:{B,C}上使用索引。
爲何MongoDB的數據文件很大？MongoDB採用的預分配空間的方式來防止文件碎片。

Redis的侷限性：
(1)Redis只能使用單線程，性能受限於CPU性能，故單實例CPU最高才可能達到5-6wQPS每秒（取決於數據結構，數據大小以及服務器硬件性能，平常環境中QPS高峯大約在1-2w左右）。
(2)支持簡單的事務需求，但業界使用場景不多，並不成熟，既是優勢也是缺點。
(3)Redis在string類型上會消耗較多內存，可使用dict（hash表）壓縮存儲以下降內存耗用。
(4)Mc和Redis都是Key-Value類型，不適合在不一樣數據集之間創建關係，也不適合進行查詢搜索。好比redis的keys pattern這種匹配操做，對redis的性能是災難。

 

 

MongoDB 與 MySQL 的適用場景：
MongoDB 的適用場景爲：數據不是特別重要（例如通知，推送這些），數據表結構變化較爲頻繁，數據量特別大，數據的併發性特別高，數據結構比較特別（例如地圖的位置座標），這些狀況下用 MongoDB ， 其餘狀況就仍是用 MySQL ，這樣組合使用就能夠達到最大的效率。
1.若是須要將 MongoDB 做爲後端 db 來代替MySQL使用，即這裏 MySQL 與 MongoDB 屬於平行級別，那麼，這樣的使用可能有如下幾種狀況的考量：
(1)MongoDB 所負責部分以文檔形式存儲，可以有較好的代碼親和性，json 格式的直接寫入方便。(如日誌之類)
(2)從 data models 設計階段就將原子性考慮於其中，無需事務之類的輔助。開發用如 nodejs 之類的語言來進行開發，對開發比較方便。
(3)MongoDB 自己的 failover 機制，無需使用如 MHA 之類的方式實現。

2.將 MongoDB 做爲相似 Redis，memcache 來作緩存db，爲 MySQL 提供服務，或是後端日誌收集分析。 考慮到 MongoDB 屬於 No SQL 型數據庫，SQL 語句與數據結構不如 MySQL 那麼親和 ，也會有不少時候將 MongoDB 作爲輔助MySQL 而使用的類 Redis memcache 之類的緩存db來使用。 亦或是僅做日誌收集分析。
MongoDB 有一個最大的缺點，就是它佔用的空間很大，由於它屬於典型空間換時間原則的類型。那麼它的磁盤空間比普通數據庫會浪費一些，並且到目前爲止它尚未實如今線壓縮功能，在 MongoDB 中頻繁的進行數據增刪改時，若是記錄變了，例如數據大小發生了變化，這時候容易產生一些數據碎片，出現碎片引起的結果，一個是索引會出現性能問題。
另一個就是在必定的時間後，所佔空間會莫明其妙地增大，因此要按期把數據庫作修復，按期從新作索引，這樣會提高MongoDB 的穩定性和效率。

1.MySQL 來自女兒的名字； MongoDB 來自 humongous
2.MySQL 使用 Table/Row/Column； MongoDB 使用 Collection/Document
3.MySQL 須要指定 table 的 schema； MongoDB的 collection 的每一個 document 的 schema 能夠自由修改
4.MySQL 支持 join； MongoDB 沒有 join
5.MySQL 使用 SQL 語言； MongoDB 使用相似 JavaScript 的函數

命令對比
MongoDB 與 MySQL 命令對比 傳統的關係數據庫通常由數據庫（database）、表（table）、記錄（record）三個層次概念組成，MongoDB 是由數據庫（database）、集合（collection）、文檔對象（document）三個層次組成。MongoDB對於關係型數據庫裏的表，可是集合中沒有列、行和關係概念，這體現了模式自由的特色。
MongoDB (文檔型數據庫)：提供可擴展的高性能數據存儲
一、基於分佈式文件存儲
二、高負載狀況下添加更多節點，能夠保證服務器性能
三、將數據存儲爲一個文檔
MongoDB 與 MySQL 的比較
一、穩定性
二、索引，索引放在內存中，可以提高隨機讀寫的性能。若是索引不能徹底放在內存，一旦出現隨機讀寫比較高的時候，就會頻繁地進行磁盤交換，MongoDB 的性能就會急劇降低
三、佔用的空間很大，由於它屬於典型空間換時間原則的類型。那麼它的磁盤空間比普通數據庫會浪費一些，並且到目前爲止它尚未實如今線壓縮功能，
在 MongoDB 中頻繁的進行數據增刪改時，若是記錄變了，例如數據大小發生了變化，這時候容易產生一些數據碎片，出現碎片引起的結果，
一個是索引會出現性能問題，
另一個就是在必定的時間後，所佔空間會莫明其妙地增大，因此要按期把數據庫作修復，按期從新作索引，這樣會提高MongoDB 的穩定性和效率。
在最新的版本里，它已經在實如今線壓縮，估計應該在2.0版左右，應該可以實如今線壓縮，能夠在後臺執行如今repair DataBase 的一些操做。若是那樣，就解決了目前困擾咱們的大問題。
四、MongoDB 對數據間的事務關係支持比較弱
五、運維不方便
MongoDB 相對於 MySQL 的優點
1. 適合那些對數據庫具體數據格式不明確或者數據庫數據格式常常變化的需求模型，並且對開發者十分友好。
2. 自帶一個分佈式文件系統，能夠很方便地部署到服務器機羣上。
MongoDB 裏有一個Shard的概念，就是方便爲了服務器分片使用的。每增長一臺Shard，MongoDB 的插入性能也會以接近倍數的方式增加，磁盤容量也很能夠很方便地擴充。
3. 自帶了對map-reduce運算框架的支持，這也很方便進行數據的統計。相似於group by
MongoDB 與 MySQL 命令對比 傳統的關係數據庫通常由數據庫（database）、表（table）、記錄（record）三個層次概念組成，
MongoDB 是由數據庫（database）、集合（collection）、文檔對象（document）三個層次組成。
MongoDB 對於關係型數據庫裏的表，可是集合中沒有列、行和關係概念，這體現了模式自由的特色。

 

MongoDB優勢：
1.MongoDB很是容易被擴展，這也爲寫代碼帶來了極大的方便。
1.性能優越:快速！在適量級的內存的 MongoDB 的性能是很是迅速的，它將熱數據存儲在物理內存中，使得熱數據的讀寫變得十分快，
2.高擴展:第三方支持豐富(這是與其餘的 No SQL 相比，MongoDB 也具備的優點)
3.自身的 Failover 機制！
4.弱一致性（最終一致），更能保證用戶的訪問速度
5.文檔結構的存儲方式，可以更便捷的獲取數據: json 的存儲格式
6.支持大容量的存儲,內置 GridFS
7.內置 Sharding

 

MongoDB 缺點：
主要是無事物機制！
① MongoDB 不支持事務操做(最主要的缺點)
② MongoDB 佔用空間過大
③ MongoDB 沒有如 MySQL 那樣成熟的維護工具，這對於開發和IT運營都是個值得注意的地方

MongoDB 的應用場景

主要特色：
MongoDB 的提供了一個面向文檔存儲，操做起來比較簡單和容易。
你能夠在 MongoDB 記錄中設置任何屬性的索引 (如：FirstName="Sameer",Address="8 Gandhi Road")來實現更快的排序。
你能夠經過本地或者網絡建立數據鏡像，這使得 MongoDB 有更強的擴展性。
若是負載的增長（須要更多的存儲空間和更強的處理能力） ，它能夠分佈在計算機網絡中的其餘節點上這就是所謂的分片。
MongoDB支持豐富的查詢表達式。查詢指令使用 JSON 形式的標記，可輕易查詢文檔中內嵌的對象及數組。
MongoDB使用update() 命令能夠實現替換完成的文檔（數據）或者一些指定的數據字段 。
MongoDB中的Map/reduce 主要是用來對數據進行批量處理和聚合操做。
Map和Reduce。Map 函數調用 emit(key,value) 遍歷集合中全部的記錄，將 key 與 value 傳給 Reduce 函數進行處理。
Map 函數和 Reduce 函數是使用 JavaScript 編寫的，並能夠經過 db.runCommand 或 mapreduce 命令來執行 MapReduce 操做。
GridFS 是 MongoDB 中的一個內置功能，能夠用於存放大量小文件。
MongoDB 容許在服務端執行腳本，能夠用 Javascript 編寫某個函數，直接在服務端執行，也能夠把函數的定義存儲在服務端，下次直接調用便可。
MongoDB支持各類編程語言:RUBY，PYTHON，JAVA，C++，PHP，C# 等多種語言。

1. 它裏面自帶了一個名叫 GirdFS 的分佈式文件系統，這就爲 MongoDB 的部署提供了很大便利。而像 MySQL 這種比較早的數據庫，雖然市面上有不少不一樣的分表部署的方案，但這種終究不如 MongoDB 直接官方支持來得便捷實在。
2. 另外，MongoDB 內部還自建了對 map-reduce運算框架的支持，雖然這種支持從功能上看還算是比較簡單的，至關於MySQL裏 GroupBy 功能的擴展版，不過也爲數據的統計帶來了方便。
3. MongoDB 在啓動後會將數據庫中的數據以文件映射的方式加載到內存中。若是內存資源至關豐富的話，這將極大地提升數據庫的查詢速度，畢竟內存的 I/O 效率比磁盤高多了。
MongoDB 以 BSON 結構（二進制）進行存儲，對海量數據存儲有着很明顯的優點。

監控
MongoDB提供了網絡和系統監控工具Munin，它做爲一個插件應用於MongoDB中。
Gangila是MongoDB高性能的系統監視的工具，它做爲一個插件應用於MongoDB中。
基於圖形界面的開源工具 Cacti, 用於查看CPU負載, 網絡帶寬利用率,它也提供了一個應用於監控 MongoDB 的插件。
查詢語句：是獨特的 MongoDB 的查詢方式。
適合場景：事件的記錄，內容管理或者博客平臺等等。
架構特色：能夠經過副本集，以及分片來實現高可用。
數據處理：數據是存儲在硬盤上的，只不過須要常常讀取的數據會被加載到內存中，將數據存儲在物理內存中，從而達到高速讀寫。
成熟度與普遍度：新興數據庫，成熟度較低，No SQL 數據庫中最爲接近關係型數據庫，比較完善的 DB 之一，適用人羣不斷在增加。

 

 

 

 

 

 

 

 

 

 

 

 

 

mongodb倒是一個「存儲數據」的系統，增刪改查數據的時候有「與或非」條件，查詢數據的方式也能像SQL數據庫同樣靈活，這是redis所不具有的。
在個人項目中，redis做爲session、任務隊列的存儲器，而mongodb做爲數據（包括用戶信息等）的存儲器。
memcached能夠隨時執行「save」命令將當前redis的數據保存到硬盤上，另外redis也會根據配置自動存儲數據到硬盤上。能夠設置讓redis再指定時間、指定更改次數時進行備份，生成RDB文件；而設置AOF，能夠在操做或時間過程後將「日誌」寫入一個文件的最末，當操做愈來愈多，則AOF文件愈來愈大。

Mongodb與Redis應用指標對比
MongoDB和Redis都是NoSQL，採用結構型數據存儲。兩者在使用場景中，存在必定的區別，這也主要因爲
兩者在內存映射的處理過程，持久化的處理方法不一樣。MongoDB建議集羣部署，更多的考慮到集羣方案，Redis
更偏重於進程順序寫入，雖然支持集羣，也僅限於主-從模式。

 

 

在使用Redis過程當中，咱們發現了很多Redis不一樣於Memcached，也不一樣於MySQL的特徵。
(本文主要討論Redis未啓用VM支持狀況)

1. Schema
MySQL: 需事先設計
Memcached: 無需設計
Redis: 小型系統能夠不用，可是若是要合理的規劃及使用Redis，須要事先進行相似以下一些規劃

數據項: value保存的內容是什麼，如用戶資料
Redis數據類型: 如String, List
數據大小: 如100字節
記錄數: 如100萬條(決定是否須要拆分)
⋯⋯
上面的規劃就是一種schema，爲何Redis在大型項目須要事先設計schema？由於Redis服務器有容量限制，數據容量不能超出物理內存大小，同時考慮到業務數據的可擴充性，記錄數會持續增多、單條記錄的內容也都會增加，所以須要提早規劃好容量，數據架構師就是經過schema來判斷當前業務的Redis是否須要「分庫分表」以知足可擴展需求。

2. 容量及帶寬規劃
容量規劃
MySQL: < 硬盤大小
Memcached: < RAM
Redis: < RAM

帶寬規劃
因爲Redis比MySQL快10倍以上，所以帶寬也是須要事先規劃，避免帶寬跑滿而出現瓶頸。

3. 性能規劃(QPS)
當系統讀寫出現瓶頸，一般如何解決？
MySQL
寫: 拆分到多服務器
讀: (1) 拆分 (2) 寫少也能夠經過增長Slave來解決

Memcached
讀寫: 都經過hash拆分到更多節點。

Redis:
寫：拆分
讀: (1) 拆分 (2) 寫少也能夠經過增長Slave來解決

4. 可擴展性
MySQL: 分庫分表
Memcached: hash分佈
Redis：也能夠分庫，也能夠hash分佈

小結
經過以上分析，Redis在不少方面同時具有MySQL及Memcached使用特徵，在某些方面則更像MySQL。
因爲Redis數據不能超過內存大小，一方面須要進行事先容量規劃，保證容量足夠；另一方面設計上須要防止數據規模無限制增長，進而致使Redis不可擴展。
Redis須要象MySQL同樣預先設計好拆分方案。

小問題
在MySQL中，經過預先創建多表或者庫能夠在業務增加時候將這些表或庫一分爲二部署到更多服務器上。
在Redis中，「分庫分表」應當如何實現？有什麼好的設計模式？

 

 

redis讀寫原理：　　　　Redis只會緩存全部的key的信息，若是Redis發現內存的使用量超過了某一個閥值，將觸發swap的操做，Redis根據「swappability = age*log(size_in_memory)」計算出哪些key對應的value須要swap到磁盤。而後再將這些key對應的value持久化到磁盤中，同時在內存中清除。這種特性使得Redis能夠保持超過其機器自己內存大小的數據。固然，機器自己的內存必需要可以保持全部的key，畢竟這些數據是不會進行swap操做的。　　　　當從Redis中讀取數據的時候，若是讀取的key對應的value不在內存中，那麼Redis就須要從swap文件中加載相應數據，而後再返回給請求方。這裏就存在一個I/O線程池的問題。在默認的狀況下，Redis會出現阻塞，即完成全部的swap文件加載後纔會相應。這種策略在客戶端的數量較小，進行批量操做的時候比較合適。可是若是將Redis應用在一個大型的網站應用程序中，這顯然是沒法知足大併發的狀況的。因此Redis運行咱們設置I/O線程池的大小，對須要從swap文件中加載相應數據的讀取請求進行併發操做，減小阻塞的時間。