回覆列表
  • 1 # 蟲蟲安全

    首先,Memcached和Redis都是著名的、廣泛使用的Nosql資料庫。

    1. Memcached簡介

    Memcached 免費開源、高效能、分散式記憶體物件快取系統,主要用於作為關係資料庫快取,用來加速應用程式的訪問,減輕主資料庫的壓力。Memcached 是一個記憶體key-value儲存,主要儲存字串或者小的物件等資料庫呼叫,API呼叫或者頁面渲染結果的資料。Memcached立足於簡單、快速部署可以解決大型資料庫快取的各種問題。

    Memcached同時又非常強大,支援包括C/C++, PHP, Java, Python, Ruby, Perl, Erlang, Lua等語言呼叫。Memcached在業界廣泛應用,除了開發者LiveJournal自己外還有Wikipedia、Flickr、Bebo,WordPress.com,Craigslist、 Mixi也在使用。

    2. Redis簡介

    Redis同樣是一個免費開源的key-value儲存系統。可以用做資料庫,快取和訊息代理使用。Redis支援比較多的資料型別,包括:字串、雜湊 表、連結串列、集合、有序集合。

    Redis使用C語言開發,支援絕大多數類Unix系統,在Linux,BSD、Unix,OS X等符合POSIX的系統下無需任何依賴就能使用。官方建議在線上應用的話最好在Linux下部署。在Windows下有非官方微軟自己開發和維護的的Redis。

    Redis和Memcached對比

    1、效能對比

    由於Redis廣泛使用的版本只使用單核,而Memcached可以使用多核,所以平均每一個核上Redis在儲存小資料時比Memcached效能更高。而在100k以上的資料中,Memcached效能要高於Redis,雖然Redis也升級新版本3.0以上支援多核,但是3.0以上版本除了增加很多功能外,效能還不如老版本。

    這是是相關效能測試對比圖:

    2、記憶體使用效率對比

    使用簡單的key-value儲存的話,Memcached的記憶體利用率更高,而如果Redis採用hash結構來做key-value儲存,由於其組合式的壓縮,其記憶體利用率會高於Memcached。

    3、Redis支援伺服器端的資料操作

    Redis相比Memcached來說,擁有更多的資料結構和並支援更豐富的資料操作,通常在Memcached 裡,你需要將資料拿到客戶端來進行類似的修改再set回去。這大大增加了網路IO的次數和資料體積。在Redis中,這些複雜的操作通常和一般的 GET/SET一樣高效。所以,如果需要快取能夠支援更復雜的結構和操作,那麼Redis會是不錯的選擇。

    4、Redis的持久化和主從架構

    Redis雖然記憶體的儲存系統,但是支援記憶體資料持久化,而且提供兩種主要的持久化策略:RDB快照和AOF日誌。使得Redis可以儲存比較重要的資料不怕斷電後資料丟失,同時基於資料持久化的分散式主從架構也提升了Redis的可用性和效能問題。

    作為對比,雖然memecached的雖然也支援透過客戶端的分散式儲存架構。

    關於memcached的命中率

    快取的命中率命中:直接從快取中get讀能取到想要的資料。 不命中:快取中沒有想要的資料,還需要到資料庫進行一次查詢才能讀取到想要的資料。

    所以命中率的高低會直接影響memcached效能。那麼要如何進行最佳化,提高命中率呢?

    最佳化設定專案:

    1、預設單個item最大資料是1MB,超過1MB資料不予儲存,常量POWER_BLOCK 1048576 進行控制,它是預設的slab大小

    2、要根據實際業務情況預估一些引數大小,適當的調整記憶體頁大小和增長因子。

    設定引數:

    -f:chunk增長因子,預設1.25。

    -n:指定最小chunk的key+suffix+value大小。

    Item (no cas) 48,Item(cas) 56。

    當指定-C選項時,最小chunk為-n指定大小+48;當沒有-C選項時,最小chunk為-n指定大

    3、極端情況下,你可以禁止LRU(最近最少使用演算法)試試。透過“-M”引數可以禁止LRU。

  • 2 # IT實戰聯盟

    簡介

    說到快取技術,只要有一定經驗的開發人員,肯定會想到redis和memcached這兩個。並且在BAT裡,redis已經逐漸取代了memcached,成為分散式場景廣泛使用的快取方案。接下來,我們就分析下,redis是如何取代memcached,成為開發者的寵兒的。

    一、支援的儲存型別不同

    雖然redis和memcached都是記憶體型資料庫,並且memcached不僅能夠儲存string型別,還能夠儲存圖片、檔案、影片等格式的檔案。然而對於更多的使用記憶體資料庫做快取以及分散式方案的程式開發者來說,memcached提供的string型別儲存的應用場景非常有限,而儲存圖片影片的功能又十分雞肋(許多公司的使用者場景是沒這方面需求)。相比之下,redis提供set,hash,list等多種型別的儲存結構,非常適合分散式快取的實現。

    二、資料落盤

    memcached 資料不可恢復,雖然大多數人使用快取以及分散式方案都不會要求資料持久化,但是誰也不能保證不出現萬一的情況。一旦發生穩定性問題,memcached掛掉後,資料是不可恢復的,而redis除了支援在配置裡開啟資料落盤(RDB),還能透過aof來找回資料。

    三、記憶體空間與資料量

    memcached可以修改最大記憶體,使用的是LRU演算法,而redis目前底層使用了自己的VM,引入了新的特性突破了物理記憶體的限制。個人認為在這方面依然是redis更加優秀一些。

    備註:value值-redis最大可以達到1GB,而memcache只有1MB;

    四、使用場景

    (1)、會話快取(Session Cache)

    最常用的一種使用Redis的情景是會話快取(session cache)。用Redis快取會話比其他儲存(如Memcached)的優勢在於:Redis提供持久化。當維護一個不是嚴格要求一致性的快取時,如果使用者的購物車資訊全部丟失,大部分人都會不高興的,現在,他們還會這樣嗎?

    幸運的是,隨著 Redis 這些年的改進,很容易找到怎麼恰當的使用Redis來快取會話的文件。甚至廣為人知的商業平臺Magento也提供Redis的外掛。

    (2)、全頁快取(FPC)

    除基本的會話token之外,Redis還提供很簡便的FPC平臺。回到一致性問題,即使重啟了Redis例項,因為有磁碟的持久化,使用者也不會看到頁面載入速度的下降,這是一個極大改進,類似PHP本地FPC。

    再次以Magento為例,Magento提供一個外掛來使用Redis作為全頁快取後端。

    此外,對WordPress的使用者來說,Pantheon有一個非常好的外掛 wp-redis,這個外掛能幫助你以最快速度載入你曾瀏覽過的頁面。

    (3)、佇列

    Reids在記憶體儲存引擎領域的一大優點是提供 list 和 set 操作,這使得Redis能作為一個很好的訊息佇列平臺來使用。Redis作為佇列使用的操作,就類似於本地程式語言(如Python)對 list 的 push/pop 操作。

    如果你快速的在Google中搜索“Redis queues”,你馬上就能找到大量的開源專案,這些專案的目的就是利用Redis建立非常好的後端工具,以滿足各種佇列需求。例如,Celery有一個後臺就是使用Redis作為broker,你可以從這裡去檢視。

    (4),排行榜/計數器

    Redis在記憶體中對數字進行遞增或遞減的操作實現的非常好。集合(Set)和有序集合(Sorted Set)也使得我們在執行這些操作的時候變的非常簡單,Redis只是正好提供了這兩種資料結構。所以,我們要從排序集合中獲取到排名最靠前的10個使用者–我們稱之為“user_scores”,我們只需要像下面一樣執行即可:

    當然,這是假定你是根據你使用者的分數做遞增的排序。如果你想返回使用者及使用者的分數,你需要這樣執行:

    ZRANGE user_scores 0 10 WITHSCORES

    Agora Games就是一個很好的例子,用Ruby實現的,它的排行榜就是使用Redis來儲存資料的,你可以在這裡看到。

    (5)、釋出/訂閱

    最後(但肯定不是最不重要的)是Redis的釋出/訂閱功能。釋出/訂閱的使用場景確實非常多。我已看見人們在社交網路連線中使用,還可作為基於釋出/訂閱的指令碼觸發器,甚至用Redis的釋出/訂閱功能來建立聊天系統!(不,這是真的,你可以去核實)。

    (6)、其他

    但是如果是對快取的資料格式有更多的要求,且對安全性也有很高的要求的話,建議還是使用redis,這也是redis目前正在逐漸代替memcached的根本原因。

    五、總結

    六、快問快答

    1、redis常見效能問題和解決方案?

    (1) Master最好不要做任何持久化工作,如RDB記憶體快照和AOF日誌檔案

    (2) 如果資料比較重要,某個Slave開啟AOF備份資料,策略設定為每秒同步一次

    (3) 為了主從複製的速度和連線的穩定性,Master和Slave最好在同一個區域網內

    (4) 儘量避免在壓力很大的主庫上增加從庫

    (5) 主從複製不要用圖狀結構,用單向連結串列結構更為穩定,即:Master <- Slave1 <- Slave2 <- Slave3…

    這樣的結構方便解決單點故障問題,實現Slave對Master的替換。如果Master掛了,可以立刻啟用Slave1做Master,其他不變。

    2、MySQL裡有2000w資料,redis中只存20w的資料,如何保證redis中的資料都是熱點資料?

    相關知識:redis 記憶體資料集大小上升到一定大小的時候,就會施行資料淘汰策略。redis 提供 6種資料淘汰策略:

    voltile-lru:從已設定過期時間的資料集(server.db[i].expires)中挑選最近最少使用的資料淘汰;

    volatile-ttl:從已設定過期時間的資料集(server.db[i].expires)中挑選將要過期的資料淘汰;

    volatile-random:從已設定過期時間的資料集(server.db[i].expires)中任意選擇資料淘汰;

    allkeys-lru:從資料集(server.db[i].dict)中挑選最近最少使用的資料淘汰;

    allkeys-random:從資料集(server.db[i].dict)中任意選擇資料淘汰

    no-enviction(驅逐):禁止驅逐資料;

    七、經典架構

    ---------------END----------------

    後續的內容同樣精彩

  • 3 # 木子教程

    問題的引入

    DB(Oracle、MySQL、Postgresql等)+Memcached 這種架構模式在我們生產環境中十分常見,一般我們透過Memcached將熱點資料載入到cache,應用層首先向Memcached請求資料,如果快取中存在資料,那麼直接返回應用層;但隨著業務資料量的不斷增加,和訪問量的持續增長,我們也會遇到很多問題:

      1.在DB和Memcached之間如何保證資料的一致性。

      2.Memcached資料命中率低或down機,應用直接訪問DB,形成雪崩效應,資料庫壓力瞬間暴增,直接導致資料庫響應慢,或者crash掉。

      3.跨機房cache同步問題。

      

    Redis

    在眾多NoSQL中我們一般拿Redis替換Memecached使用,原因有下:

    1 、Redis 支援更多的資料型別(strings、map、 list、sets、 sorted sets等)

    2 、Redis 支援複製功能。

    3 、Redis 支援資料的持久化,可以將記憶體中的資料保持在磁碟中,重啟的時候可以再次載入進行使用。

    4 、Redis 支援Sharding技術, 很容易將資料分佈到多個Redis例項中,方便快速擴充套件。

    5 、Redis 在記憶體分配時採用申請分配方式, 記憶體使用更高效。

    Redis最為常用的資料型別主要有以下:

    StringHashListSetSorted setpub/subTransactions

  • 中秋節和大豐收的關聯?
  • 清冷如雪是什麼意思?