redis 是一個基于內存的高性能key-value數據庫。

Reids的特點

? ? ? ? Redis本質上是一個Key-Value類型的內存數據庫，很像memcached，整個數據庫統統加載在內存當中進行操作，定期通過異步操作把數據庫數據flush到硬盤上進行保存。因為是純內存操作，Redis的性能非常出色，每秒可以處理超過 10萬次讀寫操作，是已知性能最快的Key-Value DB。
? ? ? ? Redis的出色之處不僅僅是性能，Redis最大的魅力是支持保存多種數據結構，此外單個value的最大限制是1GB，不像 memcached只能保存1MB的數據，因此Redis可以用來實現很多有用的功能，比方說用他的List來做FIFO雙向鏈表，實現一個輕量級的高性能消息隊列服務，用他的Set可以做高性能的tag系統等等。另外Redis也可以對存入的Key-Value設置expire時間，因此也可以被當作一個功能加強版的memcached來用。
? ? ? ? Redis的主要缺點是數據庫容量受到物理內存的限制，不能用作海量數據的高性能讀寫，因此Redis適合的場景主要局限在較小數據量的高性能操作和運算上。

?

Redis支持的數據類型

Redis通過Key-Value的單值不同類型來區分, 以下是支持的類型:

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

hashes

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

為什么redis需要把所有數據放到內存中？

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

?

另外講講內存中的數據如何同步到磁盤

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

?

Redis是單進程單線程的

redis利用隊列技術將并發訪問變為串行訪問，消除了傳統數據庫串行控制的開銷

?

虛擬內存

? ? ? ? 當你的key很小而value很大時,使用VM的效果會比較好.因為這樣節約的內存比較大.
? ? ? ? 當你的key不小時,可以考慮使用一些非常方法將很大的key變成很大的value,比如你可以考慮將key,value組合成一個新的value.
? ? ? ? vm-max-threads這個參數,可以設置訪問swap文件的線程數,設置最好不要超過機器的核數,如果設置為0,那么所有對swap文件的操作都是串行的.可能會造成比較長時間的延遲,但是對數據完整性有很好的保證.

? ? ? ? 自己測試的時候發現用虛擬內存性能也不錯。如果數據量很大，可以考慮分布式或者其他數據庫

?

分布式

redis支持主從的模式。原則：Master會將數據同步到slave，而slave不會將數據同步到master。Slave啟動時會連接master來同步數據。

這是一個典型的分布式讀寫分離模型。我們可以利用master來插入數據，slave提供檢索服務。這樣可以有效減少單個機器的并發訪問數量

讀寫分離模型

? ? ? ??通過增加Slave DB的數量，讀的性能可以線性增長。為了避免Master DB的單點故障，集群一般都會采用兩臺Master DB做雙機熱備，所以整個集群的讀和寫的可用性都非常高。
? ? ? ? 讀寫分離架構的缺陷在于，不管是Master還是Slave，每個節點都必須保存完整的數據，如果在數據量很大的情況下，集群的擴展能力還是受限于單個節點的存儲能力，而且對于Write-intensive類型的應用，讀寫分離架構并不適合。

?

數據分片模型

為了解決讀寫分離模型的缺陷，可以將數據分片模型應用進來。

可以將每個節點看成都是獨立的master，然后通過業務實現數據分片。

結合上面兩種模型，可以將每個master設計成由一個master和多個slave組成的模型。

?

redis的性能

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

實驗中模擬了20個客戶端對redis進行寫操作。當數據庫中的數據達到G數據級時，寫速度會有明顯的下降。

可能的原因: 1、redis需要將數據同步到磁盤，占用了大量的CPU和內存； 2、key數量增大，需要重新布局； 3、消息隊列中還存在大量請求，致使請求阻塞。

?

?

redis應用

這里給出一個小例子，是一個基于redis的消息隊列。

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 在項目中使用redis做為緩存，還沒有使用memcache,考慮因素主要有兩點： 1.redis豐富的數據結構,其hash,list,set以及功能豐富的String的支持，對于實際項目中的使用有很大的幫忙。（可參考官網redis.io） 2.redis單點的性能也非常高效（利用項目中的數據測試優于memcache）. 基于以上考慮，因此選用了redis來做為緩存應用。

二.分布式緩存的架構設計

1.架構設計

由于redis是單點，項目中需要使用，必須自己實現分布式。基本架構圖如下所示：

---

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

---

【Redis與Memcache的區別】

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

---

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.

?

---

版權相同

它們都是使用的bsd協議，使用它的項目可以用于商業用戶，不必發布二次修改的代碼，可以修改源代碼。

?

數據類型

redis數據類型豐富，支持set liset等類型
memcache支持簡單數據類型，需要客戶端自己處理復雜對象

?

持久性

redis支持數據落地持久化存儲
memcache不支持數據持久存儲

?

分布式存儲

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

?

value大小不同

memcache是一個內存緩存，key的長度小于250字符，單個item存儲要小于1M，不適合虛擬機使用

?

數據一致性不同

redis使用的是單線程模型，保證了數據按順序提交。
memcache需要使用cas保證數據一致性。CAS（Check and Set）是一個確保并發一致性的機制，屬于“樂觀鎖”范疇；原理很簡單：拿版本號，操作，對比版本號，如果一致就操作，不一致就放棄任何操作。

?

cpu利用

redis單線程模型只能使用一個cpu，可以開啟多個redis進程

?

為何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

副標題: Redis是新興的通用存儲系統,而Memcached仍有其適用領域

Memcached還是Redis? 在現代高性能Web應用中這一直是個爭論不休的話題。 在基于關系型數據庫的Web應用需要提高性能時,使用緩存是絕大多數架構師的第一選擇,自然，Memcached和Redis通常是優先選擇。

共同特征

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

Memcached最初在2003年由 Brad Fitzpatrick 為 LiveJournal網站開發。然后又用C語言重寫了一遍(初版為Perl實現),并開放給公眾使用,從此成為現代Web系統開發的基石。 當前Memcached的發展方向是改進穩定性和性能優化,而不是添加新功能特性。

Redis于2009年由 Salvatore Sanfilippo 創建, 直到今天 Sanfilippo 依然是Redis的唯一開發者和代碼維護者。 Redis也被稱為 "Memcached增強版(Memcached on steroids)", 這一點也不令人驚訝, 因為 Redis 有一部分就是在 Memcached 的經驗總結之上構建的的。 Redis比Memcached具有更多的功能特性,這使得它更靈活,更強大也更復雜。

Memcached和Redis被眾多企業以及大量生產系統所采用, 支持各種語言開發的客戶端,有豐富的SDK。 事實上, 在上點規模的互聯網Web開發語言中,基本上沒有不支持Memcached或Redis的。

為什么Memcached和Redis如此流行? 不僅是其具有超高的性能,還因為相對來說他們都非常簡單。 對程序員來說上手使用Memcached或Redis相當容易。 安裝和設置并集成到系統中可能只需要幾分鐘時間。 因此花費一點點時間和精力就能立刻大幅提升系統性能 —— 通常是提升一個數量級。 一個簡潔的解決方案卻能獲得巨大的性能收益: 這酸爽簡直超乎你的想象。

Memcached 適用場景

?

因為Redis是新興解決方案,提供了更多的功能特性,比起Memcached來說, Redis一般都是更好的選擇。 在兩個特定場景下Memcached可能是更好的選擇。

第一種是很細碎的靜態數據,如HTML代碼片段。 Memcached的內存管理不像Redis那么復雜,所以性能更高一些,原因是Memcached 的元數據metadata更小,相對來說額外開銷就很少。 Memcached唯一支持的數據類型是字符串?String,非常適合緩存只讀數據,因為字符串不需要額外的處理。

第二個場景,是Memcached比Redis更容易水平擴展。 原因在于它的設計和和功能很簡單,Memcached更容易擴展。 消息顯示, Redis在即將到來的3.0版(閱讀CA版本發布筆記)將內置可靠的集群支持[但一直在跳票]。

Redis 用武之地

除非受環境制約(如遺留系統),或者業務符合上面的2種情況,否則你應該優先選擇Redis。 使用Redis作為緩存,通過調優緩存內容,系統效率能獲得極其提升。

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

Redis對緩存的對象提供更大的靈活性。 而Memcached限制 key 為250字節,限制 value 為1 MB,且只能通過純文本String通信.?Redis的 key 和 value 大小限制都是512 MB,是二進制安全的【即不丟數據,與編碼無關】。 Redis提供6種數據類型,使緩存以及管理緩存變得更加智能和方便,為應用程序開發者打開了一個無限可能的世界。

相比將對象序列化后通過字符串存儲, Redis 通過 Hash來存儲一個對象的字段和值,并可以通過單個key來管理它們。

看看用Memcached更新一個對象需要干什么:

獲取整個字符串

反序列化為對象

修改其中的值

再次序列化該對象

在緩存中將整個字符串替換為新字符串

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

而使用Redis Hash的方式, 可以大幅度降低資源消耗并提高性能。 Redis的其他數據類型,如List 或者 Set,可用來實現更復雜的緩存管理模式。

Redis的另一個重大優點是其存儲的數據是不透明的,這意味著在服務器端可以直接操縱這些數據。 160多個命令中的大部分都可以用來進行數據操作, 所以通過服務端腳本調用進行數據處理成為現實。 這些內置命令和用戶腳本可以讓你直接靈活地處理數據任務,而無需通過網絡將數據傳輸給另一個系統進行處理。

Redis提供了可選/可調整的數據持久化, 目的是為了在 崩潰/重啟后可以快速加載緩存。 雖然我們一般認為緩存中的數據是不穩定,瞬時的, 但在緩存系統中將數據持久化到磁盤還是很有價值的。 在重啟后立即加載預熱的方式耗時很短, 而且減輕了主數據庫系統的開銷。

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

當今開源軟件一直在提供最佳的實用技術方案。 需要使用緩存來提高應用系統性能時,Redis和Memcached是最佳的產品級解決方案。 但考慮到其豐富的功能和先進的設計,絕大多數時候Redis都應該是你的第一選擇。

作者簡介: Itamar Haber (@itamarhaber) 是 Redis Labs的首席開發人員, 該企業為開發人員提供完全托管的Memcached和Redis云服務。 具有多年軟件產品研發經驗,曾在 Xeround, Etagon, Amicada, and M.N.S Ltd.擔任管理和領導職位. Itamar 獲得 Northwestern and Tel-Aviv Universitiesd 的Kellogg-Recanati工商管理碩士, 以及 Science in Computer Science 學士。

相關閱讀:

• 用Memcached提升Java企業應用性能,Part 1:體系結構和配置
• 用Memcached提升Java企業應用性能,Part 2:基于數據庫的webApp
• Cache之爭: Azure和AWS升級緩存服務

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

原文日期: 2014-10-15

翻譯日期: 2014-10-23

翻譯人員:?鐵錨

轉載于:https://www.cnblogs.com/lsx1993/p/4632407.html

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。