關於redis和memcache的使用選擇

2021-07-23 21:59:15 字數 1513 閱讀 9312

1首先關注效能。

由於redis只使用單核,而memcached可以使用多核,

所以在比較上,平均每乙個核上redis在儲存小資料時比memcached效能更高。

而在100k以上的資料中,memcached效能要高於redis,

雖然redis最近也在儲存大資料的效能上進行優化,但是比起memcached,還是稍有遜色。

說了這麼多,結論是,無論你使用哪乙個,每秒處理請求的次數都不會成為瓶頸。

2 關注記憶體使用率。

對於key-value這樣簡單的資料儲存,memcache的記憶體使用率更高。

如果採用hash結構,redis的記憶體使用率會更高。當然,這些都依賴於具體的應用場景。

3關注關注資料持久化和主從複製時,只有redis擁有這兩個特性。如果你的目標是構建乙個快取在公升級或者重啟後之前的資料不會丟失的話,那也只能選擇redis。

4關心你需要的操作。redis支援很多複雜的操作,甚至只考慮記憶體的使用情況,在乙個單一操作裡你常常可以做很多,而不需要將資料讀取到客戶端中(這樣會需要很多的io操作)。這些複雜的操作基本上和純get和post操作一樣快,所以你不只是需要get/set而是更多的操作時,redis會起很大的作用。

綜上所述:   對於兩者的選擇還是要看具體的應用場景,如果需要快取的資料只是key-value這樣簡單的結構時,我在專案裡還是採用memcache,它也足夠的穩定可靠。如果涉及到儲存,排序等一系列複雜的操作時,毫無疑問選擇redis。

redis和memecache的不同在於:

1、儲存方式:

memecache 把資料全部存在記憶體之中,斷電後會掛掉,資料不能超過記憶體大小

redis有部份存在硬碟上,這樣能保證資料的永續性,支援資料的持久化(筆者注:有快照和aof日誌兩種持久化方式,在實際應用的時候,要特別注意配置檔案快照引數,要不就很有可能伺服器頻繁滿載做dump)。

2、資料支援型別:

redis在資料支援上要比memecache多的多,redis不僅僅支援簡單的k/v型別的資料,同時還提供list,set,hash等資料結構的儲存  

3、使用底層模型不同:

新版本的redis直接自己構建了vm 機制 ,因為一般的系統呼叫系統函式的話,會浪費一定的時間去移動和請求。

4、執行環境不同:

redis目前官方只支援linux 上去行,從而省去了對於其它系統的支援,這樣的話可以更好的把精力用於本系統 環境上的優化,雖然後來微軟有乙個小組為其寫了補丁。但是沒有放到主幹上

5 過期策略--memcache在set時就指定,例如set key1 0 0 8,即永不過期。redis可以通過例如expire 設定,例如expire name 10

6淘汰策略 不同 ,memcache 只有lru, jedis 除了lru 最近最少使用,還有快過期的刪除,和刪除最早的快取兩種淘汰策略。

7memcache 乙個key 對應的value最大為1m,而jedis 最大為1g.

個人總結一下,有持久化需求或者對資料結構和處理有高階要求的應用,選擇redis,其他簡單的key/value儲存,選擇memcache。

非關係型資料庫 Redis和Memcache區別

redis和memecache的不同在於 2 1 儲存方式 memecache 把資料全部存在記憶體之中,斷電後會掛掉,資料不能超過記憶體大小 redis有部份存在硬碟上,這樣能保證資料的永續性,支援資料的持久化 筆者注 有快照和aof日誌兩種持久化方式,在實際應用的時候,要特別注意配置檔案快照引數...

關於Redis快取

業務場景 實時性要求不高的查詢 如果用redis做mysql的快取,key value中的值為乙個屬性 屬性值組成的hashmap,鍵的定義是個難點。鍵應該盡可能與mysql查詢的條件相關,請求呼叫的方法 controller裡分發 對應的查詢引數就可以唯一的確定查詢條件,如如 listusers....

關於Redis快取

什麼是快取穿透 有人惡意請求快取中存在的key,或者key集體過期,導致大量流量直接打到資料庫,資料庫肯定扛不住 解決方案 用布隆過濾器 什麼是快取雪崩 快取掛了,導致大量流量直接打到資料庫,資料庫肯定扛不住 解決方案 事前 redis主從 哨兵 集群部署 事中 mysql做限速和降級處理,超過處理...