說到redis就會(huì)聯(lián)想到memcached屁奏，反之亦然岩榆。了解過兩者的同學(xué)有那么個(gè)大致的印象：redis與memcached相比，比僅支持簡(jiǎn)單的key-value數(shù)據(jù)類型坟瓢，同時(shí)還提供list,set,zset,hash等數(shù)據(jù)結(jié)構(gòu)的存儲(chǔ)勇边；redis支持?jǐn)?shù)據(jù)的備份，即master-slave模式的數(shù)據(jù)備份折联；redis支持?jǐn)?shù)據(jù)的持久化粒褒，可以將內(nèi)存中的數(shù)據(jù)保持在磁盤中，重啟的時(shí)候可以再次加載進(jìn)行使用等等诚镰，這似乎看起來redis比memcached更加牛逼一些奕坟，那么事實(shí)上是不是這樣的呢祥款？存在即合理，我們來根據(jù)幾個(gè)不同點(diǎn)來一一比較一下执赡。
網(wǎng)絡(luò)IO模型
memcached是多線程镰踏，非阻塞IO復(fù)用的網(wǎng)絡(luò)模型函筋，分為監(jiān)聽主線程和worker子線程沙合，監(jiān)聽線程監(jiān)聽網(wǎng)絡(luò)連接，接受請(qǐng)求后跌帐，將連接描述字pipe傳遞給worker線程首懈，進(jìn)行讀寫IO，網(wǎng)絡(luò)層使用libevent封裝的事件庫(kù)谨敛，多線程模型可以發(fā)揮多核作用究履，但是引入了cache coherency和鎖的問題，比如：memcached最常用的stats命令脸狸，實(shí)際memcached所有操作都要對(duì)這個(gè)全局變量加鎖最仑，進(jìn)行技術(shù)等工作，帶來了性能損耗炊甲。
?redis使用單線程的IO復(fù)用模型泥彤，自己封裝了一個(gè)簡(jiǎn)單的AeEvent事件處理框架，主要實(shí)現(xiàn)了epoll, kqueue和select卿啡，對(duì)于單存只有IO操作來說吟吝，單線程可以將速度優(yōu)勢(shì)發(fā)揮到最大，但是redis也提供了一些簡(jiǎn)單的計(jì)算功能颈娜，比如排序剑逃、聚合等，對(duì)于這些操作官辽，單線程模型施加會(huì)嚴(yán)重影響整體吞吐量蛹磺，CPU計(jì)算過程中，整個(gè)IO調(diào)度都是被阻塞的同仆。
數(shù)據(jù)支持類型
memcached使用key-value形式存儲(chǔ)和訪問數(shù)據(jù)称开，在內(nèi)存中維護(hù)一張巨大的HashTable，使得對(duì)數(shù)據(jù)查詢的時(shí)間復(fù)雜度降低到O(1)乓梨，保證了對(duì)數(shù)據(jù)的高性能訪問鳖轰。
?正如開篇所說：redis與memcached相比，比僅支持簡(jiǎn)單的key-value數(shù)據(jù)類型扶镀，同時(shí)還提供list,set,zset,hash等數(shù)據(jù)結(jié)構(gòu)的存儲(chǔ)蕴侣；
內(nèi)存管理機(jī)制
對(duì)于像Redis和Memcached這種基于內(nèi)存的數(shù)據(jù)庫(kù)系統(tǒng)來說，內(nèi)存管理的效率高低是影響系統(tǒng)性能的關(guān)鍵因素臭觉。傳統(tǒng)C語(yǔ)言中的malloc/free函數(shù)是最常用的分配和釋放內(nèi)存的方法昆雀，但是這種方法存在著很大的缺陷：首先辱志，對(duì)于開發(fā)人員來說不匹配的malloc和free容易造成內(nèi)存泄露；其次頻繁調(diào)用會(huì)造成大量?jī)?nèi)存碎片無法回收重新利用狞膘，降低內(nèi)存利用率揩懒；最后作為系統(tǒng)調(diào)用，其系統(tǒng)開銷遠(yuǎn)遠(yuǎn)大于一般函數(shù)調(diào)用挽封。所以已球，為了提高內(nèi)存的管理效率，高效的內(nèi)存管理方案都不會(huì)直接使用malloc/free調(diào)用辅愿。Redis和Memcached均使用了自身設(shè)計(jì)的內(nèi)存管理機(jī)制智亮，但是實(shí)現(xiàn)方法存在很大的差異，下面將會(huì)對(duì)兩者的內(nèi)存管理機(jī)制分別進(jìn)行介紹点待。
?Memcached默認(rèn)使用Slab Allocation機(jī)制管理內(nèi)存阔蛉，其主要思想是按照預(yù)先規(guī)定的大小，將分配的內(nèi)存分割成特定長(zhǎng)度的塊以存儲(chǔ)相應(yīng)長(zhǎng)度的key-value數(shù)據(jù)記錄癞埠，以完全解決內(nèi)存碎片問題状原。Slab Allocation機(jī)制只為存儲(chǔ)外部數(shù)據(jù)而設(shè)計(jì)，也就是說所有的key-value數(shù)據(jù)都存儲(chǔ)在Slab Allocation系統(tǒng)里苗踪，而Memcached的其它內(nèi)存請(qǐng)求則通過普通的malloc/free來申請(qǐng)颠区，因?yàn)檫@些請(qǐng)求的數(shù)量和頻率決定了它們不會(huì)對(duì)整個(gè)系統(tǒng)的性能造成影響Slab Allocation的原理相當(dāng)簡(jiǎn)單。 如圖所示徒探，它首先從操作系統(tǒng)申請(qǐng)一大塊內(nèi)存瓦呼，并將其分割成各種尺寸的塊Chunk，并把尺寸相同的塊分成組Slab Class测暗。其中央串，Chunk就是用來存儲(chǔ)key-value數(shù)據(jù)的最小單位。每個(gè)Slab Class的大小碗啄，可以在Memcached啟動(dòng)的時(shí)候通過制定Growth Factor來控制质和。假定圖中Growth Factor的取值為1.25，如果第一組Chunk的大小為88個(gè)字節(jié)稚字，第二組Chunk的大小就為112個(gè)字節(jié)饲宿，依此類推。
當(dāng)Memcached接收到客戶端發(fā)送過來的數(shù)據(jù)時(shí)首先會(huì)根據(jù)收到數(shù)據(jù)的大小選擇一個(gè)最合適的Slab Class胆描，然后通過查詢Memcached保存著的該Slab Class內(nèi)空閑Chunk的列表就可以找到一個(gè)可用于存儲(chǔ)數(shù)據(jù)的Chunk瘫想。當(dāng)一條數(shù)據(jù)庫(kù)過期或者丟棄時(shí)，該記錄所占用的Chunk就可以回收昌讲，重新添加到空閑列表中国夜。從以上過程我們可以看出Memcached的內(nèi)存管理制效率高，而且不會(huì)造成內(nèi)存碎片短绸，但是它最大的缺點(diǎn)就是會(huì)導(dǎo)致空間浪費(fèi)车吹。因?yàn)槊總€(gè)Chunk都分配了特定長(zhǎng)度的內(nèi)存空間筹裕，所以變長(zhǎng)數(shù)據(jù)無法充分利用這些空間。如圖 所示窄驹，將100個(gè)字節(jié)的數(shù)據(jù)緩存到128個(gè)字節(jié)的Chunk中朝卒，剩余的28個(gè)字節(jié)就浪費(fèi)掉了。
Redis的內(nèi)存管理主要通過源碼中zmalloc.h和zmalloc.c兩個(gè)文件來實(shí)現(xiàn)的乐埠。Redis為了方便內(nèi)存的管理抗斤，在分配一塊內(nèi)存之后，會(huì)將這塊內(nèi)存的大小存入內(nèi)存塊的頭部饮戳。如圖所示豪治，real_ptr是redis調(diào)用malloc后返回的指針洞拨。redis將內(nèi)存塊的大小size存入頭部扯罐，size所占據(jù)的內(nèi)存大小是已知的，為size_t類型的長(zhǎng)度烦衣，然后返回ret_ptr歹河。當(dāng)需要釋放內(nèi)存的時(shí)候，ret_ptr被傳給內(nèi)存管理程序花吟。通過ret_ptr秸歧，程序可以很容易的算出real_ptr的值，然后將real_ptr傳給free釋放內(nèi)存衅澈。
Redis通過定義一個(gè)數(shù)組來記錄所有的內(nèi)存分配情況键菱，這個(gè)數(shù)組的長(zhǎng)度為ZMALLOC_MAX_ALLOC_STAT。數(shù)組的每一個(gè)元素代表當(dāng)前程序所分配的內(nèi)存塊的個(gè)數(shù)今布，且內(nèi)存塊的大小為該元素的下標(biāo)经备。在源碼中，這個(gè)數(shù)組為zmalloc_allocations部默。zmalloc_allocations[16]代表已經(jīng)分配的長(zhǎng)度為16bytes的內(nèi)存塊的個(gè)數(shù)侵蒙。zmalloc.c中有一個(gè)靜態(tài)變量used_memory用來記錄當(dāng)前分配的內(nèi)存總大小。所以傅蹂，總的來看纷闺，Redis采用的是包裝的mallc/free，相較于Memcached的內(nèi)存管理方法來說份蝴，要簡(jiǎn)單很多犁功。
?在Redis中，并不是所有的數(shù)據(jù)都一直存儲(chǔ)在內(nèi)存中的婚夫。這是和Memcached相比一個(gè)最大的區(qū)別浸卦。當(dāng)物理內(nèi)存用完時(shí)，Redis可以將一些很久沒用到的value交換到磁盤请敦。Redis只會(huì)緩存所有的key的信息镐躲，如果Redis發(fā)現(xiàn)內(nèi)存的使用量超過了某一個(gè)閥值储玫，將觸發(fā)swap的操作，Redis根據(jù)“swappability = age*log(size_in_memory)”計(jì)算出哪些key對(duì)應(yīng)的value需要swap到磁盤萤皂。然后再將這些key對(duì)應(yīng)的value持久化到磁盤中撒穷，同時(shí)在內(nèi)存中清除。這種特性使得Redis可以保持超過其機(jī)器本身內(nèi)存大小的數(shù)據(jù)裆熙。當(dāng)然哈垢，機(jī)器本身的內(nèi)存必須要能夠保持所有的key，畢竟這些數(shù)據(jù)是不會(huì)進(jìn)行swap操作的恕洲。同時(shí)由于Redis將內(nèi)存中的數(shù)據(jù)swap到磁盤中的時(shí)候晒夹，提供服務(wù)的主線程和進(jìn)行swap操作的子線程會(huì)共享這部分內(nèi)存，所以如果更新需要swap的數(shù)據(jù)僚稿，Redis將阻塞這個(gè)操作凡桥，直到子線程完成swap操作后才可以進(jìn)行修改。當(dāng)從Redis中讀取數(shù)據(jù)的時(shí)候蚀同，如果讀取的key對(duì)應(yīng)的value不在內(nèi)存中缅刽，那么Redis就需要從swap文件中加載相應(yīng)數(shù)據(jù)，然后再返回給請(qǐng)求方蠢络。 這里就存在一個(gè)I/O線程池的問題衰猛。在默認(rèn)的情況下，Redis會(huì)出現(xiàn)阻塞刹孔，即完成所有的swap文件加載后才會(huì)相應(yīng)啡省。這種策略在客戶端的數(shù)量較小，進(jìn)行批量操作的時(shí)候比較合適髓霞。但是如果將Redis應(yīng)用在一個(gè)大型的網(wǎng)站應(yīng)用程序中卦睹，這顯然是無法滿足大并發(fā)的情況的。所以Redis運(yùn)行我們?cè)O(shè)置I/O線程池的大小酸茴，對(duì)需要從swap文件中加載相應(yīng)數(shù)據(jù)的讀取請(qǐng)求進(jìn)行并發(fā)操作分预，減少阻塞的時(shí)間。
?Memcached使用預(yù)分配的內(nèi)存池的方式薪捍，使用slab和大小不同的chunk來管理內(nèi)存笼痹，Item根據(jù)大小選擇合適的chunk存儲(chǔ)，內(nèi)存池的方式可以省去申請(qǐng)/釋放內(nèi)存的開銷酪穿，并且能減小內(nèi)存碎片產(chǎn)生凳干，但這種方式也會(huì)帶來一定程度上的空間浪費(fèi)，并且在內(nèi)存仍然有很大空間時(shí)被济，新的數(shù)據(jù)也可能會(huì)被剔除救赐。
?Redis使用現(xiàn)場(chǎng)申請(qǐng)內(nèi)存的方式來存儲(chǔ)數(shù)據(jù)，并且很少使用free-list等方式來優(yōu)化內(nèi)存分配，會(huì)在一定程度上存在內(nèi)存碎片经磅，Redis跟據(jù)存儲(chǔ)命令參數(shù)泌绣，會(huì)把帶過期時(shí)間的數(shù)據(jù)單獨(dú)存放在一起，并把它們稱為臨時(shí)數(shù)據(jù)预厌，非臨時(shí)數(shù)據(jù)是永遠(yuǎn)不會(huì)被剔除的阿迈，即便物理內(nèi)存不夠，導(dǎo)致swap也不會(huì)剔除任何非臨時(shí)數(shù)據(jù)（但會(huì)嘗試剔除部分臨時(shí)數(shù)據(jù)）轧叽，這點(diǎn)上Redis更適合作為存儲(chǔ)而不是cache苗沧。
數(shù)據(jù)存儲(chǔ)及持久化
memcached不支持內(nèi)存數(shù)據(jù)的持久化操作，所有的數(shù)據(jù)都以in-memory的形式存儲(chǔ)炭晒。
?redis支持持久化操作待逞。redis提供了兩種不同的持久化方法來講數(shù)據(jù)存儲(chǔ)到硬盤里面，一種是快照（snapshotting)网严，它可以將存在于某一時(shí)刻的所有數(shù)據(jù)都寫入硬盤里面识樱。另一種方法叫只追加文件（append-only file， AOF),它會(huì)在執(zhí)行寫命令時(shí)屿笼，將被執(zhí)行的寫命令復(fù)制到硬盤里面牺荠。
數(shù)據(jù)一致性問題
Memcached提供了cas命令翁巍，可以保證多個(gè)并發(fā)訪問操作同一份數(shù)據(jù)的一致性問題驴一。 Redis沒有提供cas 命令，并不能保證這點(diǎn)灶壶，不過Redis提供了事務(wù)的功能肝断，可以保證一串 命令的原子性，中間不會(huì)被任何操作打斷驰凛。
集群管理不同
Memcached是全內(nèi)存的數(shù)據(jù)緩沖系統(tǒng)胸懈，Redis雖然支持?jǐn)?shù)據(jù)的持久化，但是全內(nèi)存畢竟才是其高性能的本質(zhì)恰响。作為基于內(nèi)存的存儲(chǔ)系統(tǒng)來說趣钱，機(jī)器物理內(nèi)存的大小就是系統(tǒng)能夠容納的最大數(shù)據(jù)量。如果需要處理的數(shù)據(jù)量超過了單臺(tái)機(jī)器的物理內(nèi)存大小胚宦，就需要構(gòu)建分布式集群來擴(kuò)展存儲(chǔ)能力首有。
?Memcached本身并不支持分布式，因此只能在客戶端通過像一致性哈希這樣的分布式算法來實(shí)現(xiàn)Memcached的分布式存儲(chǔ)枢劝。下圖給出了Memcached的分布式存儲(chǔ)實(shí)現(xiàn)架構(gòu)井联。當(dāng)客戶端向Memcached集群發(fā)送數(shù)據(jù)之前，首先會(huì)通過內(nèi)置的分布式算法計(jì)算出該條數(shù)據(jù)的目標(biāo)節(jié)點(diǎn)您旁，然后數(shù)據(jù)會(huì)直接發(fā)送到該節(jié)點(diǎn)上存儲(chǔ)烙常。但客戶端查詢數(shù)據(jù)時(shí)，同樣要計(jì)算出查詢數(shù)據(jù)所在的節(jié)點(diǎn)鹤盒，然后直接向該節(jié)點(diǎn)發(fā)送查詢請(qǐng)求以獲取數(shù)據(jù)蚕脏。
?相較于Memcached只能采用客戶端實(shí)現(xiàn)分布式存儲(chǔ)侦副，Redis更偏向于在服務(wù)器端構(gòu)建分布式存儲(chǔ)。最新版本的Redis已經(jīng)支持了分布式存儲(chǔ)功能驼鞭。Redis Cluster是一個(gè)實(shí)現(xiàn)了分布式且允許單點(diǎn)故障的Redis高級(jí)版本跃洛，它沒有中心節(jié)點(diǎn)，具有線性可伸縮的功能终议。Redis Cluster的分布式存儲(chǔ)架構(gòu)汇竭，節(jié)點(diǎn)與節(jié)點(diǎn)之間通過二進(jìn)制協(xié)議進(jìn)行通信，節(jié)點(diǎn)與客戶端之間通過ascii協(xié)議進(jìn)行通信穴张。在數(shù)據(jù)的放置策略上细燎，Redis Cluster將整個(gè)key的數(shù)值域分成4096個(gè)哈希槽，每個(gè)節(jié)點(diǎn)上可以存儲(chǔ)一個(gè)或多個(gè)哈希槽皂甘，也就是說當(dāng)前Redis Cluster支持的最大節(jié)點(diǎn)數(shù)就是4096玻驻。Redis Cluster使用的分布式算法也很簡(jiǎn)單：crc16( key ) % HASH_SLOTS_NUMBER。
?為了保證單點(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)的兩個(gè)用于冗余的Slave節(jié)點(diǎn)渐夸。這樣在整個(gè)集群中嗤锉，任意兩個(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)瘟忱。
