redis 是一個(gè)基于內(nèi)存的高性能key-value數(shù)據(jù)庫(kù)。

Reids的特點(diǎn)

? ? ? ? Redis本質(zhì)上是一個(gè)Key-Value類型的內(nèi)存數(shù)據(jù)庫(kù)，很像memcached，整個(gè)數(shù)據(jù)庫(kù)統(tǒng)統(tǒng)加載在內(nèi)存當(dāng)中進(jìn)行操作，定期通過(guò)異步操作把數(shù)據(jù)庫(kù)數(shù)據(jù)flush到硬盤(pán)上進(jìn)行保存。因?yàn)槭?strong>純內(nèi)存操作，Redis的性能非常出色，每秒可以處理超過(guò) 10萬(wàn)次讀寫(xiě)操作，是已知性能最快的Key-Value DB。
? ? ? ? Redis的出色之處不僅僅是性能，Redis最大的魅力是支持保存多種數(shù)據(jù)結(jié)構(gòu)，此外單個(gè)value的最大限制是1GB，不像 memcached只能保存1MB的數(shù)據(jù)，因此Redis可以用來(lái)實(shí)現(xiàn)很多有用的功能，比方說(shuō)用他的List來(lái)做FIFO雙向鏈表，實(shí)現(xiàn)一個(gè)輕量級(jí)的高性能消息隊(duì)列服務(wù)，用他的Set可以做高性能的tag系統(tǒng)等等。另外Redis也可以對(duì)存入的Key-Value設(shè)置expire時(shí)間，因此也可以被當(dāng)作一個(gè)功能加強(qiáng)版的memcached來(lái)用。
? ? ? ? Redis的主要缺點(diǎn)是數(shù)據(jù)庫(kù)容量受到物理內(nèi)存的限制，不能用作海量數(shù)據(jù)的高性能讀寫(xiě)，因此Redis適合的場(chǎng)景主要局限在較小數(shù)據(jù)量的高性能操作和運(yùn)算上。

?

Redis支持的數(shù)據(jù)類型

Redis通過(guò)Key-Value的單值不同類型來(lái)區(qū)分, 以下是支持的類型:

Strings
Lists
Sets 求交集、并集
Sorted Set?

hashes

具體的指令說(shuō)明：http://code.google.com/p/redis/wiki/CommandReference

為什么redis需要把所有數(shù)據(jù)放到內(nèi)存中？

? ? ? ? Redis為了達(dá)到最快的讀寫(xiě)速度將數(shù)據(jù)都讀到內(nèi)存中，并通過(guò)異步的方式將數(shù)據(jù)寫(xiě)入磁盤(pán)。所以redis具有快速和數(shù)據(jù)持久化的特征。如果不將數(shù)據(jù)放在內(nèi)存中，磁盤(pán)I/O速度為嚴(yán)重影響redis的性能。在內(nèi)存越來(lái)越便宜的今天，redis將會(huì)越來(lái)越受歡迎。
? ? ? ? 如果設(shè)置了最大使用的內(nèi)存，則數(shù)據(jù)已有記錄數(shù)達(dá)到內(nèi)存限值后不能繼續(xù)插入新值。

?

另外講講內(nèi)存中的數(shù)據(jù)如何同步到磁盤(pán)

? ? ? ? redis在dump數(shù)據(jù)的時(shí)候,是fork子進(jìn)程。redis的默認(rèn)配置中,每60秒如果紀(jì)錄更改數(shù)達(dá)到1萬(wàn)條就需要dump到硬盤(pán)中去,但實(shí)際上由于超過(guò)了這個(gè)數(shù),我們的redis幾乎不停地在dump數(shù)據(jù)到硬盤(pán)上;dump數(shù)據(jù)到硬盤(pán)時(shí),我估計(jì)為了達(dá)到一個(gè)原子的效應(yīng),避免數(shù)據(jù)丟失,redis是先把數(shù)據(jù)dump到一個(gè)臨時(shí)文件,然后重命名為你在配置文件設(shè)定的數(shù)據(jù)文件名.而前面說(shuō)到,加載數(shù)據(jù)要1到2分鐘,dump數(shù)據(jù)應(yīng)該也在1分鐘左右吧;dump出來(lái)的文件差不多1到2個(gè)G;這樣,服務(wù)器幾乎一直保持著每分鐘寫(xiě)一個(gè)2G的文件的這種IO的負(fù)載，磁盤(pán)基本不閑著;

?

Redis是單進(jìn)程單線程的

redis利用隊(duì)列技術(shù)將并發(fā)訪問(wèn)變?yōu)榇性L問(wèn)，消除了傳統(tǒng)數(shù)據(jù)庫(kù)串行控制的開(kāi)銷

?

虛擬內(nèi)存

? ? ? ? 當(dāng)你的key很小而value很大時(shí),使用VM的效果會(huì)比較好.因?yàn)檫@樣節(jié)約的內(nèi)存比較大.
? ? ? ? 當(dāng)你的key不小時(shí),可以考慮使用一些非常方法將很大的key變成很大的value,比如你可以考慮將key,value組合成一個(gè)新的value.
? ? ? ? vm-max-threads這個(gè)參數(shù),可以設(shè)置訪問(wèn)swap文件的線程數(shù),設(shè)置最好不要超過(guò)機(jī)器的核數(shù),如果設(shè)置為0,那么所有對(duì)swap文件的操作都是串行的.可能會(huì)造成比較長(zhǎng)時(shí)間的延遲,但是對(duì)數(shù)據(jù)完整性有很好的保證.

? ? ? ? 自己測(cè)試的時(shí)候發(fā)現(xiàn)用虛擬內(nèi)存性能也不錯(cuò)。如果數(shù)據(jù)量很大，可以考慮分布式或者其他數(shù)據(jù)庫(kù)

?

分布式

redis支持主從的模式。原則：Master會(huì)將數(shù)據(jù)同步到slave，而slave不會(huì)將數(shù)據(jù)同步到master。Slave啟動(dòng)時(shí)會(huì)連接master來(lái)同步數(shù)據(jù)。

這是一個(gè)典型的分布式讀寫(xiě)分離模型。我們可以利用master來(lái)插入數(shù)據(jù)，slave提供檢索服務(wù)。這樣可以有效減少單個(gè)機(jī)器的并發(fā)訪問(wèn)數(shù)量

讀寫(xiě)分離模型

? ? ? ??通過(guò)增加Slave DB的數(shù)量，讀的性能可以線性增長(zhǎng)。為了避免Master DB的單點(diǎn)故障，集群一般都會(huì)采用兩臺(tái)Master DB做雙機(jī)熱備，所以整個(gè)集群的讀和寫(xiě)的可用性都非常高。
? ? ? ? 讀寫(xiě)分離架構(gòu)的缺陷在于，不管是Master還是Slave，每個(gè)節(jié)點(diǎn)都必須保存完整的數(shù)據(jù)，如果在數(shù)據(jù)量很大的情況下，集群的擴(kuò)展能力還是受限于單個(gè)節(jié)點(diǎn)的存儲(chǔ)能力，而且對(duì)于Write-intensive類型的應(yīng)用，讀寫(xiě)分離架構(gòu)并不適合。

?

數(shù)據(jù)分片模型

為了解決讀寫(xiě)分離模型的缺陷，可以將數(shù)據(jù)分片模型應(yīng)用進(jìn)來(lái)。

可以將每個(gè)節(jié)點(diǎn)看成都是獨(dú)立的master，然后通過(guò)業(yè)務(wù)實(shí)現(xiàn)數(shù)據(jù)分片。

結(jié)合上面兩種模型，可以將每個(gè)master設(shè)計(jì)成由一個(gè)master和多個(gè)slave組成的模型。

?

redis的性能

這是官方給出的數(shù)據(jù)：SET操作每秒鐘 110000 次，GET操作每秒鐘 81000 次。

實(shí)驗(yàn)中模擬了20個(gè)客戶端對(duì)redis進(jìn)行寫(xiě)操作。當(dāng)數(shù)據(jù)庫(kù)中的數(shù)據(jù)達(dá)到G數(shù)據(jù)級(jí)時(shí)，寫(xiě)速度會(huì)有明顯的下降。

可能的原因: 1、redis需要將數(shù)據(jù)同步到磁盤(pán)，占用了大量的CPU和內(nèi)存； 2、key數(shù)量增大，需要重新布局； 3、消息隊(duì)列中還存在大量請(qǐng)求，致使請(qǐng)求阻塞。

?

?

redis應(yīng)用

這里給出一個(gè)小例子，是一個(gè)基于redis的消息隊(duì)列。

python源碼:

[python]?view plaincopy

r?=?redis.Redis()??

class?Queue(object):??

????"""An?abstract?FIFO?queue"""??

????def?__init__(self):??

???????local_id?=?r.incr("queue_space")??

???????id_name?=?"queue:%s"?%(local_id)??

???????self.id_name?=?id_name??

???def?push(self,?element):??

???"""Push?an?element?to?the?tail?of?the?queue"""???

???????id_name?=?self.id_name??

???????push_element?=?redis.lpush(id_name,?element)??

???def?pop(self):??

???"""Pop?an?element?from?the?head?of?the?queue"""??

??????id_name?=?self.id_name??

??????popped_element?=?redis.rpop(id_name)??

??????return?popped_element ?

---

一.為什么選擇redis 在項(xiàng)目中使用redis做為緩存，還沒(méi)有使用memcache,考慮因素主要有兩點(diǎn)： 1.redis豐富的數(shù)據(jù)結(jié)構(gòu),其hash,list,set以及功能豐富的String的支持，對(duì)于實(shí)際項(xiàng)目中的使用有很大的幫忙。（可參考官網(wǎng)redis.io） 2.redis單點(diǎn)的性能也非常高效（利用項(xiàng)目中的數(shù)據(jù)測(cè)試優(yōu)于memcache）. 基于以上考慮，因此選用了redis來(lái)做為緩存應(yīng)用。

二.分布式緩存的架構(gòu)設(shè)計(jì)

1.架構(gòu)設(shè)計(jì)

由于redis是單點(diǎn)，項(xiàng)目中需要使用，必須自己實(shí)現(xiàn)分布式。基本架構(gòu)圖如下所示：

---

1. Redis是什么
這個(gè)問(wèn)題的結(jié)果影響了我們?cè)趺从肦edis。如果你認(rèn)為Redis是一個(gè)key value store, 那可能會(huì)用它來(lái)代替MySQL；如果認(rèn)為它是一個(gè)可以持久化的cache, 可能只是它保存一些頻繁訪問(wèn)的臨時(shí)數(shù)據(jù)。Redis是REmote DIctionary Server的縮寫(xiě)，在Redis在官方網(wǎng)站的的副標(biāo)題是A persistent key-value database with built-in net interface written in ANSI-C for Posix systems，這個(gè)定義偏向key value store。還有一些看法則認(rèn)為Redis是一個(gè)memory database，因?yàn)樗母咝阅芏际腔趦?nèi)存操作的基礎(chǔ)。另外一些人則認(rèn)為Redis是一個(gè)data structure server，因?yàn)镽edis支持復(fù)雜的數(shù)據(jù)特性，比如List, Set等。對(duì)Redis的作用的不同解讀決定了你對(duì)Redis的使用方式。
互聯(lián)網(wǎng)數(shù)據(jù)目前基本使用兩種方式來(lái)存儲(chǔ)，關(guān)系數(shù)據(jù)庫(kù)或者key value。但是這些互聯(lián)網(wǎng)業(yè)務(wù)本身并不屬于這兩種數(shù)據(jù)類型，比如用戶在社會(huì)化平臺(tái)中的關(guān)系，它是一個(gè)list，如果要用關(guān)系數(shù)據(jù)庫(kù)存儲(chǔ)就需要轉(zhuǎn)換成一種多行記錄的形式，這種形式存在很多冗余數(shù)據(jù)，每一行需要存儲(chǔ)一些重復(fù)信息。如果用key value存儲(chǔ)則修改和刪除比較麻煩，需要將全部數(shù)據(jù)讀出再寫(xiě)入。Redis在內(nèi)存中設(shè)計(jì)了各種數(shù)據(jù)類型，讓業(yè)務(wù)能夠高速原子的訪問(wèn)這些數(shù)據(jù)結(jié)構(gòu)，并且不需要關(guān)心持久存儲(chǔ)的問(wèn)題，從架構(gòu)上解決了前面兩種存儲(chǔ)需要走一些彎路的問(wèn)題。
2. Redis不可能比Memcache快
很多開(kāi)發(fā)者都認(rèn)為Redis不可能比Memcached快，Memcached完全基于內(nèi)存，而Redis具有持久化保存特性，即使是異步的，Redis也不可能比Memcached快。但是測(cè)試結(jié)果基本是Redis占絕對(duì)優(yōu)勢(shì)。一直在思考這個(gè)原因，目前想到的原因有這幾方面。
Libevent。和Memcached不同，Redis并沒(méi)有選擇libevent。Libevent為了迎合通用性造成代碼龐大(目前Redis代碼還不到libevent的1/3)及犧牲了在特定平臺(tái)的不少性能。Redis用libevent中兩個(gè)文件修改實(shí)現(xiàn)了自己的epoll event loop(4)。業(yè)界不少開(kāi)發(fā)者也建議Redis使用另外一個(gè)libevent高性能替代libev，但是作者還是堅(jiān)持Redis應(yīng)該小巧并去依賴的思路。一個(gè)印象深刻的細(xì)節(jié)是編譯Redis之前并不需要執(zhí)行./configure。
CAS問(wèn)題。CAS是Memcached中比較方便的一種防止競(jìng)爭(zhēng)修改資源的方法。CAS實(shí)現(xiàn)需要為每個(gè)cache key設(shè)置一個(gè)隱藏的cas token，cas相當(dāng)value版本號(hào)，每次set會(huì)token需要遞增，因此帶來(lái)CPU和內(nèi)存的雙重開(kāi)銷，雖然這些開(kāi)銷很小，但是到單機(jī)10G+ cache以及QPS上萬(wàn)之后這些開(kāi)銷就會(huì)給雙方相對(duì)帶來(lái)一些細(xì)微性能差別(5)。
3. 單臺(tái)Redis的存放數(shù)據(jù)必須比物理內(nèi)存小
Redis的數(shù)據(jù)全部放在內(nèi)存帶來(lái)了高速的性能，但是也帶來(lái)一些不合理之處。比如一個(gè)中型網(wǎng)站有100萬(wàn)注冊(cè)用戶，如果這些資料要用Redis來(lái)存儲(chǔ)，內(nèi)存的容量必須能夠容納這100萬(wàn)用戶。但是業(yè)務(wù)實(shí)際情況是100萬(wàn)用戶只有5萬(wàn)活躍用戶，1周來(lái)訪問(wèn)過(guò)1次的也只有15萬(wàn)用戶，因此全部100萬(wàn)用戶的數(shù)據(jù)都放在內(nèi)存有不合理之處，RAM需要為冷數(shù)據(jù)買(mǎi)單。
這跟操作系統(tǒng)非常相似，操作系統(tǒng)所有應(yīng)用訪問(wèn)的數(shù)據(jù)都在內(nèi)存，但是如果物理內(nèi)存容納不下新的數(shù)據(jù)，操作系統(tǒng)會(huì)智能將部分長(zhǎng)期沒(méi)有訪問(wèn)的數(shù)據(jù)交換到磁盤(pán)，為新的應(yīng)用留出空間。現(xiàn)代操作系統(tǒng)給應(yīng)用提供的并不是物理內(nèi)存，而是虛擬內(nèi)存(Virtual Memory)的概念。
基于相同的考慮，Redis 2.0也增加了VM特性。讓Redis數(shù)據(jù)容量突破了物理內(nèi)存的限制。并實(shí)現(xiàn)了數(shù)據(jù)冷熱分離。
4. Redis的VM實(shí)現(xiàn)是重復(fù)造輪子
Redis的VM依照之前的epoll實(shí)現(xiàn)思路依舊是自己實(shí)現(xiàn)。但是在前面操作系統(tǒng)的介紹提到OS也可以自動(dòng)幫程序?qū)崿F(xiàn)冷熱數(shù)據(jù)分離，Redis只需要OS申請(qǐng)一塊大內(nèi)存，OS會(huì)自動(dòng)將熱數(shù)據(jù)放入物理內(nèi)存，冷數(shù)據(jù)交換到硬盤(pán)，另外一個(gè)知名的“理解了現(xiàn)代操作系統(tǒng)(3)”的Varnish就是這樣實(shí)現(xiàn)，也取得了非常成功的效果。
作者antirez在解釋為什么要自己實(shí)現(xiàn)VM中提到幾個(gè)原因(6)。主要OS的VM換入換出是基于Page概念，比如OS VM1個(gè)Page是4K, 4K中只要還有一個(gè)元素即使只有1個(gè)字節(jié)被訪問(wèn)，這個(gè)頁(yè)也不會(huì)被SWAP, 換入也同樣道理，讀到一個(gè)字節(jié)可能會(huì)換入4K無(wú)用的內(nèi)存。而Redis自己實(shí)現(xiàn)則可以達(dá)到控制換入的粒度。另外訪問(wèn)操作系統(tǒng)SWAP內(nèi)存區(qū)域時(shí)block進(jìn)程，也是導(dǎo)致Redis要自己實(shí)現(xiàn)VM原因之一。
5. 用get/set方式使用Redis
作為一個(gè)key value存在，很多開(kāi)發(fā)者自然的使用set/get方式來(lái)使用Redis，實(shí)際上這并不是最優(yōu)化的使用方法。尤其在未啟用VM情況下，Redis全部數(shù)據(jù)需要放入內(nèi)存，節(jié)約內(nèi)存尤其重要。
假如一個(gè)key-value單元需要最小占用512字節(jié)，即使只存一個(gè)字節(jié)也占了512字節(jié)。這時(shí)候就有一個(gè)設(shè)計(jì)模式，可以把key復(fù)用，幾個(gè)key-value放入一個(gè)key中，value再作為一個(gè)set存入，這樣同樣512字節(jié)就會(huì)存放10-100倍的容量。
這就是為了節(jié)約內(nèi)存，建議使用hashset而不是set/get的方式來(lái)使用Redis，詳細(xì)方法見(jiàn)參考文獻(xiàn)(7)。
6. 使用aof代替snapshot
Redis有兩種存儲(chǔ)方式，默認(rèn)是snapshot方式，實(shí)現(xiàn)方法是定時(shí)將內(nèi)存的快照(snapshot)持久化到硬盤(pán)，這種方法缺點(diǎn)是持久化之后如果出現(xiàn)crash則會(huì)丟失一段數(shù)據(jù)。因此在完美主義者的推動(dòng)下作者增加了aof方式。aof即append only mode，在寫(xiě)入內(nèi)存數(shù)據(jù)的同時(shí)將操作命令保存到日志文件，在一個(gè)并發(fā)更改上萬(wàn)的系統(tǒng)中，命令日志是一個(gè)非常龐大的數(shù)據(jù)，管理維護(hù)成本非常高，恢復(fù)重建時(shí)間會(huì)非常長(zhǎng)，這樣導(dǎo)致失去aof高可用性本意。另外更重要的是Redis是一個(gè)內(nèi)存數(shù)據(jù)結(jié)構(gòu)模型，所有的優(yōu)勢(shì)都是建立在對(duì)內(nèi)存復(fù)雜數(shù)據(jù)結(jié)構(gòu)高效的原子操作上，這樣就看出aof是一個(gè)非常不協(xié)調(diào)的部分。
其實(shí)aof目的主要是數(shù)據(jù)可靠性及高可用性，在Redis中有另外一種方法來(lái)達(dá)到目的：Replication。由于Redis的高性能，復(fù)制基本沒(méi)有延遲。這樣達(dá)到了防止單點(diǎn)故障及實(shí)現(xiàn)了高可用。
小結(jié)
要想成功使用一種產(chǎn)品，我們需要深入了解它的特性。Redis性能突出，如果能夠熟練的駕馭，對(duì)國(guó)內(nèi)很多大型應(yīng)用具有很大幫助。

---

【Redis與Memcache的區(qū)別】

1、Redis和Memcache都是將數(shù)據(jù)存放在內(nèi)存中，都是內(nèi)存數(shù)據(jù)庫(kù)。不過(guò)memcache還可用于緩存其他東西，例如圖片、視頻等等。 2、Redis不僅僅支持簡(jiǎn)單的k/v類型的數(shù)據(jù)，同時(shí)還提供list，set，hash等數(shù)據(jù)結(jié)構(gòu)的存儲(chǔ)。 3、虛擬內(nèi)存--Redis當(dāng)物理內(nèi)存用完時(shí)，可以將一些很久沒(méi)用到的value交換到磁盤(pán) 4、過(guò)期策略--memcache在set時(shí)就指定，例如set key1 0 0 8,即永不過(guò)期。Redis可以通過(guò)例如expire 設(shè)定，例如expire name 10 5、分布式--設(shè)定memcache集群，利用magent做一主多從;redis可以做一主多從。都可以一主一從 6、存儲(chǔ)數(shù)據(jù)安全--memcache掛掉后，數(shù)據(jù)沒(méi)了；redis可以定期保存到磁盤(pán)（持久化） 7、災(zāi)難恢復(fù)--memcache掛掉后，數(shù)據(jù)不可恢復(fù); redis數(shù)據(jù)丟失后可以通過(guò)aof恢復(fù) 8、Redis支持?jǐn)?shù)據(jù)的備份，即master-slave模式的數(shù)據(jù)備份。

---

memcache官方定義

Free & open source, high-performance, distributed memory object caching system, generic in nature, but intended for use in speeding up dynamic web applications by alleviating database load.

?

redis官方定義
Redis is an open source, BSD licensed, advanced key-value store. It is often referred to as a data structure server since keys can contain strings, hashes, lists, sets and sorted sets.

?

---

版權(quán)相同

它們都是使用的bsd協(xié)議，使用它的項(xiàng)目可以用于商業(yè)用戶，不必發(fā)布二次修改的代碼，可以修改源代碼。

?

數(shù)據(jù)類型

redis數(shù)據(jù)類型豐富，支持set liset等類型
memcache支持簡(jiǎn)單數(shù)據(jù)類型，需要客戶端自己處理復(fù)雜對(duì)象

?

持久性

redis支持?jǐn)?shù)據(jù)落地持久化存儲(chǔ)
memcache不支持?jǐn)?shù)據(jù)持久存儲(chǔ)

?

分布式存儲(chǔ)

redis支持master-slave復(fù)制模式
memcache可以使用一致性hash做分布式

?

value大小不同

memcache是一個(gè)內(nèi)存緩存，key的長(zhǎng)度小于250字符，單個(gè)item存儲(chǔ)要小于1M，不適合虛擬機(jī)使用

?

數(shù)據(jù)一致性不同

redis使用的是單線程模型，保證了數(shù)據(jù)按順序提交。
memcache需要使用cas保證數(shù)據(jù)一致性。CAS（Check and Set）是一個(gè)確保并發(fā)一致性的機(jī)制，屬于“樂(lè)觀鎖”范疇；原理很簡(jiǎn)單：拿版本號(hào)，操作，對(duì)比版本號(hào)，如果一致就操作，不一致就放棄任何操作。

?

cpu利用

redis單線程模型只能使用一個(gè)cpu，可以開(kāi)啟多個(gè)redis進(jìn)程

?

為何Redis要比Memcached好用

【http://blog.csdn.net/renfufei/article/details/40598889】

GitHub版本地址:?https://github.com/cncounter/translation/blob/master/tiemao_2014/Redis_beats_Memcached/Redis_beats_Memcached.md

副標(biāo)題: Redis是新興的通用存儲(chǔ)系統(tǒng),而Memcached仍有其適用領(lǐng)域

Memcached還是Redis? 在現(xiàn)代高性能Web應(yīng)用中這一直是個(gè)爭(zhēng)論不休的話題。 在基于關(guān)系型數(shù)據(jù)庫(kù)的Web應(yīng)用需要提高性能時(shí),使用緩存是絕大多數(shù)架構(gòu)師的第一選擇,自然，Memcached和Redis通常是優(yōu)先選擇。

共同特征

• 都是 key-value 形式的內(nèi)存數(shù)據(jù)庫(kù)
• 都是NoSQL家族的數(shù)據(jù)管理解決方案
• 都基于同樣的key-value 數(shù)據(jù)模型
• 所有數(shù)據(jù)全部放在內(nèi)存中(這也是適用于緩存的原因)
• 性能得分不分伯仲,包括數(shù)據(jù)吞吐量和延遲等指標(biāo)
• 都是成熟的、廣受開(kāi)源項(xiàng)目歡迎的 key-value存儲(chǔ)系統(tǒng)

Memcached最初在2003年由 Brad Fitzpatrick 為 LiveJournal網(wǎng)站開(kāi)發(fā)。然后又用C語(yǔ)言重寫(xiě)了一遍(初版為Perl實(shí)現(xiàn)),并開(kāi)放給公眾使用,從此成為現(xiàn)代Web系統(tǒng)開(kāi)發(fā)的基石。 當(dāng)前Memcached的發(fā)展方向是改進(jìn)穩(wěn)定性和性能優(yōu)化,而不是添加新功能特性。

Redis于2009年由 Salvatore Sanfilippo 創(chuàng)建, 直到今天 Sanfilippo 依然是Redis的唯一開(kāi)發(fā)者和代碼維護(hù)者。 Redis也被稱為 "Memcached增強(qiáng)版(Memcached on steroids)", 這一點(diǎn)也不令人驚訝, 因?yàn)?Redis 有一部分就是在 Memcached 的經(jīng)驗(yàn)總結(jié)之上構(gòu)建的的。 Redis比Memcached具有更多的功能特性,這使得它更靈活,更強(qiáng)大也更復(fù)雜。

Memcached和Redis被眾多企業(yè)以及大量生產(chǎn)系統(tǒng)所采用, 支持各種語(yǔ)言開(kāi)發(fā)的客戶端,有豐富的SDK。 事實(shí)上, 在上點(diǎn)規(guī)模的互聯(lián)網(wǎng)Web開(kāi)發(fā)語(yǔ)言中,基本上沒(méi)有不支持Memcached或Redis的。

為什么Memcached和Redis如此流行? 不僅是其具有超高的性能,還因?yàn)橄鄬?duì)來(lái)說(shuō)他們都非常簡(jiǎn)單。 對(duì)程序員來(lái)說(shuō)上手使用Memcached或Redis相當(dāng)容易。 安裝和設(shè)置并集成到系統(tǒng)中可能只需要幾分鐘時(shí)間。 因此花費(fèi)一點(diǎn)點(diǎn)時(shí)間和精力就能立刻大幅提升系統(tǒng)性能 —— 通常是提升一個(gè)數(shù)量級(jí)。 一個(gè)簡(jiǎn)潔的解決方案卻能獲得巨大的性能收益: 這酸爽簡(jiǎn)直超乎你的想象。

Memcached 適用場(chǎng)景

?

因?yàn)镽edis是新興解決方案,提供了更多的功能特性,比起Memcached來(lái)說(shuō), Redis一般都是更好的選擇。 在兩個(gè)特定場(chǎng)景下Memcached可能是更好的選擇。

第一種是很細(xì)碎的靜態(tài)數(shù)據(jù),如HTML代碼片段。 Memcached的內(nèi)存管理不像Redis那么復(fù)雜,所以性能更高一些,原因是Memcached 的元數(shù)據(jù)metadata更小,相對(duì)來(lái)說(shuō)額外開(kāi)銷就很少。 Memcached唯一支持的數(shù)據(jù)類型是字符串?String,非常適合緩存只讀數(shù)據(jù),因?yàn)樽址恍枰~外的處理。

第二個(gè)場(chǎng)景,是Memcached比Redis更容易水平擴(kuò)展。 原因在于它的設(shè)計(jì)和和功能很簡(jiǎn)單,Memcached更容易擴(kuò)展。 消息顯示, Redis在即將到來(lái)的3.0版(閱讀CA版本發(fā)布筆記)將內(nèi)置可靠的集群支持[但一直在跳票]。

Redis 用武之地

除非受環(huán)境制約(如遺留系統(tǒng)),或者業(yè)務(wù)符合上面的2種情況,否則你應(yīng)該優(yōu)先選擇Redis。 使用Redis作為緩存,通過(guò)調(diào)優(yōu)緩存內(nèi)容,系統(tǒng)效率能獲得極其提升。

很明顯Redis的優(yōu)勢(shì)在于緩存管理。 緩存通過(guò)某種數(shù)據(jù)回收機(jī)制(data eviction mechanism)在必要時(shí)將舊數(shù)據(jù)從內(nèi)存中刪除,為新數(shù)據(jù)騰出空間。 Memcached的數(shù)據(jù)回收機(jī)制使用LRU(Least Recently Used,最近最少使用)算法,同時(shí)優(yōu)先清除與新數(shù)據(jù)大小差不多的舊數(shù)據(jù)塊。 相比之下,Redis允許細(xì)粒度控制過(guò)期緩存,有6種不同的策略可供選擇。 Redis還采用了一些更復(fù)雜的內(nèi)存管理方法和回收策略。

Redis對(duì)緩存的對(duì)象提供更大的靈活性。 而Memcached限制 key 為250字節(jié),限制 value 為1 MB,且只能通過(guò)純文本String通信.?Redis的 key 和 value 大小限制都是512 MB,是二進(jìn)制安全的【即不丟數(shù)據(jù),與編碼無(wú)關(guān)】。 Redis提供6種數(shù)據(jù)類型,使緩存以及管理緩存變得更加智能和方便,為應(yīng)用程序開(kāi)發(fā)者打開(kāi)了一個(gè)無(wú)限可能的世界。

相比將對(duì)象序列化后通過(guò)字符串存儲(chǔ), Redis 通過(guò) Hash來(lái)存儲(chǔ)一個(gè)對(duì)象的字段和值,并可以通過(guò)單個(gè)key來(lái)管理它們。

看看用Memcached更新一個(gè)對(duì)象需要干什么:

獲取整個(gè)字符串

反序列化為對(duì)象

修改其中的值

再次序列化該對(duì)象

在緩存中將整個(gè)字符串替換為新字符串

并且每次更新都要干這些破事。

而使用Redis Hash的方式, 可以大幅度降低資源消耗并提高性能。 Redis的其他數(shù)據(jù)類型,如List 或者 Set,可用來(lái)實(shí)現(xiàn)更復(fù)雜的緩存管理模式。

Redis的另一個(gè)重大優(yōu)點(diǎn)是其存儲(chǔ)的數(shù)據(jù)是不透明的,這意味著在服務(wù)器端可以直接操縱這些數(shù)據(jù)。 160多個(gè)命令中的大部分都可以用來(lái)進(jìn)行數(shù)據(jù)操作, 所以通過(guò)服務(wù)端腳本調(diào)用進(jìn)行數(shù)據(jù)處理成為現(xiàn)實(shí)。 這些內(nèi)置命令和用戶腳本可以讓你直接靈活地處理數(shù)據(jù)任務(wù),而無(wú)需通過(guò)網(wǎng)絡(luò)將數(shù)據(jù)傳輸給另一個(gè)系統(tǒng)進(jìn)行處理。

Redis提供了可選/可調(diào)整的數(shù)據(jù)持久化, 目的是為了在 崩潰/重啟后可以快速加載緩存。 雖然我們一般認(rèn)為緩存中的數(shù)據(jù)是不穩(wěn)定,瞬時(shí)的, 但在緩存系統(tǒng)中將數(shù)據(jù)持久化到磁盤(pán)還是很有價(jià)值的。 在重啟后立即加載預(yù)熱的方式耗時(shí)很短, 而且減輕了主數(shù)據(jù)庫(kù)系統(tǒng)的開(kāi)銷。

最后, Redis提供主從復(fù)制(replication)。 Replication 可用于實(shí)現(xiàn)高可用的cache系統(tǒng),允許某些服務(wù)器宕機(jī)的情況下也能提供不間斷的服務(wù)。 假設(shè)要求在某臺(tái)緩存服務(wù)器崩潰時(shí), 只有少部分用戶和程序在短時(shí)間內(nèi)受影響, 大多數(shù)情況下就需要有一個(gè)行之有效的解決方案,來(lái)保證緩存內(nèi)容和服務(wù)的可用性。

當(dāng)今開(kāi)源軟件一直在提供最佳的實(shí)用技術(shù)方案。 需要使用緩存來(lái)提高應(yīng)用系統(tǒng)性能時(shí),Redis和Memcached是最佳的產(chǎn)品級(jí)解決方案。 但考慮到其豐富的功能和先進(jìn)的設(shè)計(jì),絕大多數(shù)時(shí)候Redis都應(yīng)該是你的第一選擇。

作者簡(jiǎn)介: Itamar Haber (@itamarhaber) 是 Redis Labs的首席開(kāi)發(fā)人員, 該企業(yè)為開(kāi)發(fā)人員提供完全托管的Memcached和Redis云服務(wù)。 具有多年軟件產(chǎn)品研發(fā)經(jīng)驗(yàn),曾在 Xeround, Etagon, Amicada, and M.N.S Ltd.擔(dān)任管理和領(lǐng)導(dǎo)職位. Itamar 獲得 Northwestern and Tel-Aviv Universitiesd 的Kellogg-Recanati工商管理碩士, 以及 Science in Computer Science 學(xué)士。

相關(guān)閱讀:

• 用Memcached提升Java企業(yè)應(yīng)用性能,Part 1:體系結(jié)構(gòu)和配置
• 用Memcached提升Java企業(yè)應(yīng)用性能,Part 2:基于數(shù)據(jù)庫(kù)的webApp
• Cache之爭(zhēng): Azure和AWS升級(jí)緩存服務(wù)

原文鏈接:?Why Redis beats Memcached for caching

原文日期: 2014-10-15

翻譯日期: 2014-10-23

翻譯人員:?鐵錨

轉(zhuǎn)載于:https://www.cnblogs.com/lsx1993/p/4632407.html

總結(jié)

以上是生活随笔為你收集整理的Redis简介 与Memcache的区别的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。