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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Memcached及Redis
1、相對(duì)memcached來(lái)說(shuō)，需要保證數(shù)據(jù)不丟失的話，選擇Redis。
2、當(dāng)然，大部分情況來(lái)說(shuō)，選擇Redis是一個(gè)更好的選擇，因?yàn)樗鼜?qiáng)大、更受歡迎，并且比Memcached有更多的支持者。Memcached只是Redis功能中的一小部分。所以對(duì)于新項(xiàng)目來(lái)說(shuō)，選擇Redis。

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

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