摘要：當重啟時，將會讀取文件進行重放以恢復(fù)到關(guān)閉前的最后時刻。伸縮性受到線程數(shù)的限制，線程數(shù)的調(diào)度對也是不小的負擔。所以允許我們設(shè)置線程池的大小，對需要從文件中加載相應(yīng)數(shù)據(jù)的讀取請求進行并發(fā)操作，減少阻塞的時間。

Mongo
Mongo的數(shù)據(jù)將會保存在底層文件系統(tǒng)，因此存儲容量遠大于redis和memcached。一個database中所有的collections以及索引信息會分散存儲在多個數(shù)據(jù)文件中，即mongodb并沒有像SQL數(shù)據(jù)庫那樣，每個表的數(shù)據(jù)、索引分別存儲；數(shù)據(jù)分塊的單位為extent（范圍，區(qū)域），即一個data file中有多個extents組成，extent中可以保存collection數(shù)據(jù)或者indexes數(shù)據(jù)，一個extent只能保存同一個collection數(shù)據(jù)，不同的collections數(shù)據(jù)分布在不同的extents中，indexes數(shù)據(jù)也保存在各自的extents中；最終，一個collection有一個或者多個extents構(gòu)成，最小size為8K，最大可以為2G，依次增大；它們分散在多個data files中。對于一個data file而言，可能包含多個collection的數(shù)據(jù)，即有多個不同collections的extents、index extents混合構(gòu)成。每個extent包含多條documents（或者index entries），每個extent的大小可能不相等，但一個extent不會跨越2個data files。

Redis
1、Redis的數(shù)據(jù)存儲在內(nèi)存中，同時可以通過兩種存儲機制，將數(shù)據(jù)持久化到磁盤。
（1）Snapshot工作原理: 是將數(shù)據(jù)先存儲在內(nèi)存，然后當數(shù)據(jù)累計達到某些設(shè)定的伐值的時候，就會觸發(fā)一次DUMP操作，將變化的數(shù)據(jù)一次性寫入數(shù)據(jù)文件（RDB文件）
（2）AOF 工作原理: 是將數(shù)據(jù)也是先存在內(nèi)存，但是固定時候會使用調(diào)用fsync來完成對本次寫操作的日志記錄，這個日志揭露文件其實是一個基于Redis網(wǎng)絡(luò)交互協(xié)議的文本文件。AOF調(diào)用fsync也不是說全部都是無阻塞的，在某些系統(tǒng)上可能出現(xiàn)fsync阻塞進程的情況，對于這種情況可以通過配置修改，但默認情況不要修改。AOF最關(guān)鍵的配置就是關(guān)于調(diào)用fsync追加日志文件的頻率，有兩種預(yù)設(shè)頻率，always每次記錄進來都添加，everysecond 每秒添加一次。當redis重啟時，將會讀取AOF文件進行“重放”以恢復(fù)到redis關(guān)閉前的最后時刻。
（3）兩種存儲原理比較：

 a.性能
 Snapshot方式的性能是要明顯高于AOF方式的，原因有兩點：
 采用2進制方式存儲數(shù)據(jù)，數(shù)據(jù)文件比較小，加載快速。存儲的時候是按照配置中的save策略來存儲，每次都是聚合很多數(shù)據(jù)批量存儲，寫入的效率很好，而AOF則一般都是工作在實時存儲或者準實時模式下。相對來說存儲的頻率高，效率卻偏低。
 
 b.數(shù)據(jù)安全
 AOF數(shù)據(jù)安全性高于Snapshot存儲，原因：
 Snapshot存儲是基于累計批量的思想，也就是說在允許的情況下，累計的數(shù)據(jù)越多那么寫入效率也就越高，但數(shù)據(jù)的累計是靠時間的積累完成的，那么如果在長時間數(shù)據(jù)不寫入RDB，但Redis又遇到了崩潰，那么沒有寫入的數(shù)據(jù)就無法恢復(fù)了，但是AOF方式偏偏相反，根據(jù)AOF配置的存儲頻率的策略可以做到最少的數(shù)據(jù)丟失和較高的數(shù)據(jù)恢復(fù)能力。

Memcached
1、Memcached不支持內(nèi)存數(shù)據(jù)的持久化操作，所以的數(shù)據(jù)都以in-momory的形成存儲。

Mongo
1、字符串、整型、布爾型、雙進度浮點型...具體參照：http://www.yiibai.com/mongodb...

Redis
1、除了簡單的key-value數(shù)據(jù)類型，同時還提供了list、hash、set、zset等數(shù)據(jù)結(jié)構(gòu)的存儲

Memcached
1、Memcached使用key-value形式存儲和訪問數(shù)據(jù)

Mongo
1、多線程，同步 IO 模型。

由主線程進行 accept 連接，然后針對每一個連接創(chuàng)建一個線程進行處理，「thread per connection」這種模型：
（1）不適合短連接服務(wù)，創(chuàng)建/刪除線程的開銷是巨大的，體現(xiàn)在創(chuàng)建線程時間和至少1MB 內(nèi)存的使用。
（2）伸縮性受到線程數(shù)的限制，200+線程數(shù)的調(diào)度對 OS 也是不小的負擔。另外隨著線程數(shù)的增加, 由于 mongo 本身業(yè)務(wù)的特性，對數(shù)據(jù)處理的并發(fā)度并不高，DB鎖和全局的原子操作造成的 context-switch 也是急劇上升，性能反而下降，頻繁的線程切換對于 cache 也不友好。

Redis
1、Redis使用 單線程的IO復(fù)用模型 ，自己封裝了一個簡單的Ae_Event事件處理框架，主要實現(xiàn)了epoll、kqueue、kvport和select，對于單存只有IO操作來說，單線程可以將速度優(yōu)勢發(fā)揮到最大，但是Redis也提供了一些簡單的計算功能，比如排序、聚合等，對于這些操作，單線程模型不能發(fā)揮多核CPU的優(yōu)勢，會嚴重影響整體吞吐率，因為在CPU的計算的過程中，整個IO調(diào)度是被阻塞的，因此 Redis不適合用于計算。

Memcached
1、Memcached是 多線程、非阻塞IO復(fù)用 的網(wǎng)絡(luò)模型，分為監(jiān)聽主線程和worker子線程，監(jiān)聽線程監(jiān)聽網(wǎng)絡(luò)連接，接受請求后，將連接描述字pipe傳遞給worker線程進行讀寫IO，網(wǎng)絡(luò)層使用libevent封裝的事件庫，多線程模型可以發(fā)揮CPU多核作用，但是引入了cache coherency(緩存一致性）和鎖的問題，比如：Memcached最常用的stats命令，實際Memcached所有操作都要對這個全局變量加鎖、進行技術(shù)工作等，帶來了性能損耗。（緩存的一致性就是指緩存中的數(shù)據(jù)是否和目標存儲中的數(shù)據(jù)是一樣的，也就是說緩存中已經(jīng)修改得數(shù)據(jù)是否已經(jīng)保存到了物理存儲中，物理存儲中已經(jīng)被修改得內(nèi)容，是否與緩存的內(nèi)容是一樣的。這就是一致性的概念。）

Redis
1、Redis的內(nèi)存管理主要通過源碼中的zmalloc.h和zmalloc.c兩個文件來實現(xiàn)。Redis為了方便內(nèi)存的管理，在分配了一塊內(nèi)存后，會將這塊內(nèi)存的大小存入內(nèi)存塊的頭部。如下圖所示，real_ptr是Redis調(diào)用malloc函數(shù)返回的指針，Redis將內(nèi)存塊的大小size存入頭部（size所占據(jù)的大小是已知的，為size_t類型的長度），然后返回ret_ptr。當需要釋放內(nèi)存的時候，ret_ptr別傳給內(nèi)存管理程序，通過ret_ptr可以很容易計算出real_ptr的值，然后將real_ptr傳給free釋放掉。

2、在Redis中，并不是所有的數(shù)組都一直存儲在內(nèi)存中的。這是和Memcached相比最大的一個區(qū)別。當物理內(nèi)存用完的時候，Redis可以將一些很久沒用到的value交換到磁盤(注：這里用到的是Redis的Virtual Memory技術(shù)，Redis2.4版本之后已經(jīng)不提倡使用了)。Redis只會緩存所有key的信息，如果Redis發(fā)現(xiàn)內(nèi)存的使用量超過了某個閾值，將觸發(fā)swap操作。swap操作根據(jù)規(guī)則計算出哪些key對應(yīng)的value需要swap到磁盤，然后再將這些key對應(yīng)的value持久化到磁盤中，同時在內(nèi)存中清除。這種特性使得Redis可以保存超過其機器物理內(nèi)存大小的數(shù)據(jù)。當然，機器本身的內(nèi)存必須要能夠保存所有的key，畢竟這部分數(shù)據(jù)是不會被swap到磁盤的。同時由于Redis將內(nèi)存中的數(shù)據(jù)swap到磁盤的時候，提供服務(wù)的主線程和進行swap的子線程會共享這部分內(nèi)存，所有如果需要更新swap的數(shù)據(jù)，Redis將阻塞這個操作，直到子線程完成swap之后才可以進行修改。當從Redis中讀取數(shù)據(jù)的時候，如果讀取的key的value不在內(nèi)存中，那么Redis需要從swap文件中加載對應(yīng)的數(shù)據(jù)，然后再返回給client，這里就存在一個I/O線程池的問題。在默認情況下，Redis會出現(xiàn)阻塞，即完成所有的swap文件加載后才會執(zhí)行相應(yīng)的操作。這種策略在client數(shù)量較小，進行批量操作的時候比較合適。但是如果Redis應(yīng)用在一個大型的網(wǎng)站應(yīng)用中，這顯示是無法滿足大并發(fā)的情況的。所以Redis允許我們設(shè)置I/O線程池的大小，對需要從swap文件中加載相應(yīng)數(shù)據(jù)的讀取請求進行并發(fā)操作，減少阻塞的時間。

Memcached
1、Memcached默認使用Slab Allocation機制來管理內(nèi)存，它的主要思想是 按照預(yù)先規(guī)定的大小，將分配的內(nèi)存分割成特定長度的塊，以存儲相應(yīng)長度的key-value數(shù)據(jù)記錄，以完全解決內(nèi)存碎片的問題。Slab Allocation機制只為存儲外部數(shù)據(jù)而設(shè)計，也就是說所有的key-value數(shù)據(jù)都存儲在slab allocation系統(tǒng)里面，但是Memcached的其他內(nèi)存請求則是通過普通的malloc/free來申請，因為這些請求的數(shù)量和頻率決定了它們不會對整個系統(tǒng)的性能造成影響。
2、slab allocation機制的原理比較簡單，如下圖所示，它首先從操作系統(tǒng)申請一大塊內(nèi)存，并將其分割成各種尺寸的chunk(塊)，并把尺寸相同的chunk分成一組組slab class。其中，chunk就是用來存儲key-value的最小單位。每個slab class的大小，可以在Memcached啟動的時候通過制定growth factor來控制。

3、當Memcached接收到客戶端發(fā)過來的數(shù)據(jù)時，會根據(jù)收到數(shù)據(jù)的大小選擇一個最合適的slab class，然后通過查詢Memcached保存著的該slab class內(nèi)空閑chunk的列表，就可以找到一個用于存儲數(shù)據(jù)的chunk。當一條數(shù)據(jù)記錄過期或者丟棄時，該記錄所占用的chunk就可以被回收，重新添加到空閑列表中。
4、從以上過程中可以看到，Memcached的內(nèi)存管理效率高，并且不會造成內(nèi)存碎片，但是它最大的不足是會造成空間浪費。因為每個chunk都分配了特定長度的內(nèi)存空間，所以變長數(shù)據(jù)無法利用這些空間。如下圖所示，將100字節(jié)的數(shù)據(jù)緩存到128字節(jié)的chunk中，剩余的28個字節(jié)就被浪費掉了。

Mongo
1、Replica Set：中文翻譯叫做副本集，就是集群當中包含了多份數(shù)據(jù)，保證主節(jié)點掛掉了，備節(jié)點能繼續(xù)提供數(shù)據(jù)服務(wù)，提供的前提就是數(shù)據(jù)需要和主節(jié)點一致。如下圖：

2、Mongodb(M)表示主節(jié)點，Mongodb(S)表示備節(jié)點，Mongodb(A)表示仲裁節(jié)點。主備節(jié)點存儲數(shù)據(jù)，仲裁節(jié)點不存儲數(shù)據(jù)?？蛻舳送瑫r連接主節(jié)點與備節(jié)點，不連接仲裁節(jié)點。
3、默認設(shè)置下，主節(jié)點提供所有增刪查改服務(wù)，備節(jié)點不提供任何服務(wù)。但是可以通過設(shè)置使備節(jié)點提供查詢服務(wù)，這樣就可以減少主節(jié)點的壓力，當客戶端進行數(shù)據(jù)查詢時，請求自動轉(zhuǎn)到備節(jié)點上。這個設(shè)置叫做Read Preference Modes，同時Java客戶端提供了簡單的配置方式，可以不必直接對數(shù)據(jù)庫進行操作。
4、仲裁節(jié)點是一種特殊的節(jié)點，它本身并不存儲數(shù)據(jù)，主要的作用是決定哪一個備節(jié)點在主節(jié)點掛掉之后提升為主節(jié)點，所以客戶端不需要連接此節(jié)點。這里雖然只有一個備節(jié)點，但是仍然需要一個仲裁節(jié)點來提升備節(jié)點級別（由備用節(jié)點提升為主節(jié)點）。仲裁節(jié)點是必須的。詳見：http://blog.csdn.net/luonanqi...

Redis
1、相比Memcached只能采用客戶端實現(xiàn)分布式存儲，Redis更偏向在服務(wù)端構(gòu)建分布式存儲。新版本的Redis已經(jīng)支持分布式存儲功能。Redis Cluster是一個實現(xiàn)了分布式并且允許單點故障的Redis高級版本，它沒有中心節(jié)點，具有線性可伸縮的功能。Redis Cluster的分布式存儲架構(gòu)，節(jié)點與節(jié)點之間通過二進制協(xié)議進行通訊，節(jié)點與客戶端之間通過ascii協(xié)議通訊。在數(shù)據(jù)的放置策略上，Redis Cluster將整個key的數(shù)值域劃分成16384(2^14)個哈希槽，每個節(jié)點上可以存儲一個或多個哈希槽，也就是說Redis Cluster支持的最大節(jié)點數(shù)是16384。
2、為了保證單點故障下得數(shù)據(jù)可用性，Redis Cluster引入了Master節(jié)點和Slave節(jié)點。在Redis Cluster中，每個Master節(jié)點都會對應(yīng)2個用于冗余的Slave節(jié)點。這樣在整個集群中，任意2個節(jié)點的宕機都不會導(dǎo)致數(shù)據(jù)的不可用。當Master節(jié)點下線后，集群會自動選擇一個Slave節(jié)點成為新的Master節(jié)點。

Memcached
1、Memcached是全內(nèi)存的數(shù)據(jù)緩沖系統(tǒng)，Redis雖然支持數(shù)據(jù)的持久化，但是全內(nèi)存才是其高性能的本質(zhì)。作為基于內(nèi)存的存儲系統(tǒng)來說，機器物理內(nèi)存的大小就是系統(tǒng)能夠容納的最大數(shù)據(jù)量。如果數(shù)據(jù)超過了單臺機器的物理內(nèi)存大小，那么就需要構(gòu)建集群來擴展存儲能力。
2、Memcached本身并不支持分布式，因此只能在客戶端通過像一致性哈希這樣的分布式算法來實現(xiàn)Memcached的分布式存儲。

Memcached及Redis
1、相對memcached來說，需要保證數(shù)據(jù)不丟失的話，選擇Redis。
2、當然，大部分情況來說，選擇Redis是一個更好的選擇，因為它更強大、更受歡迎，并且比Memcached有更多的支持者。Memcached只是Redis功能中的一小部分。所以對于新項目來說，選擇Redis。

Mongo
1、Mongo的使用和上面兩個數(shù)據(jù)庫是不沖突的，這篇文字只是做一個知識的總結(jié)。
2、日志、消息記錄；不需要事務(wù)，不需復(fù)雜join連接表；需要大容量存儲；高吞吐量；數(shù)據(jù)不丟失；高可用；使用Mongo。

http://blog.csdn.net/sun49192...
https://www.zhihu.com/questio...
https://yq.aliyun.com/article...