国产精品久久久aaaa,日日干夜夜操天天插,亚洲乱熟女香蕉一区二区三区少妇,99精品国产高清一区二区三区,国产成人精品一区二区色戒,久久久国产精品成人免费,亚洲精品毛片久久久久,99久久婷婷国产综合精品电影,国产一区二区三区任你鲁

0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復
登錄后你可以
  • 下載海量資料
  • 學習在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認識你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

redis、memcache原理對比

lhl545545 ? 來源:電子發(fā)燒友網(wǎng) ? 2018-02-09 15:31 ? 次閱讀
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

memcache、redis原理對比

一、問題:

數(shù)據(jù)庫表數(shù)據(jù)量極大(千萬條),要求讓服務(wù)器更加快速地響應(yīng)用戶的需求。

二、解決方案:

1.通過高速服務(wù)器Cache緩存數(shù)據(jù)庫數(shù)據(jù)

2.內(nèi)存數(shù)據(jù)庫

(這里僅從數(shù)據(jù)緩存方面考慮,當然,后期可以采用Hadoop+HBase+Hive等分布式存儲分析平臺)

三、主流解Cache和數(shù)據(jù)庫對比:

redis、memcache原理對比

上述技術(shù)基本上代表了當今在數(shù)據(jù)存儲方面所有的實現(xiàn)方案,其中主要涉及到了普通關(guān)系型數(shù)據(jù)庫(MySQL/PostgreSQL),NoSQL數(shù)據(jù)庫(MongoDB),內(nèi)存數(shù)據(jù)庫(Redis),內(nèi)存Cache(Memcached),我們現(xiàn)在需要的是對大數(shù)據(jù)表仍保持高效的查詢速度,普通關(guān)系型數(shù)據(jù)庫是無法滿足的。而MongoDB其實只是一種非關(guān)系型數(shù)據(jù)庫,其優(yōu)勢在于可以存儲海量數(shù)據(jù),具備強大的查詢功能,因此不宜用于緩存數(shù)據(jù)的場景。

從以上各數(shù)據(jù)可知,對于我們產(chǎn)品最可行的技術(shù)方案有兩種:

1.Memcached 內(nèi)存Key-Value Cache

2.Redis 內(nèi)存數(shù)據(jù)庫

四、下面重點分析Memcached和Redis兩種方案:

4.1 Memcached介紹

Memcached 是一個高性能的分布式內(nèi)存對象緩存系統(tǒng),用于動態(tài)Web應(yīng)用以減輕數(shù)據(jù)庫負載。它通過在內(nèi)存中緩存數(shù)據(jù)和對象來減少讀取數(shù)據(jù)庫的次數(shù),從而提供動態(tài)、數(shù)據(jù)庫驅(qū)動網(wǎng)站的速度,現(xiàn)在已被LiveJournal、hatena、Facebook、Vox、LiveJournal等公司所使用。

4.2 Memcached工作方式分析

許多Web應(yīng)用都將數(shù)據(jù)保存到 RDBMS中,應(yīng)用服務(wù)器從中讀取數(shù)據(jù)并在瀏覽器中顯示。 但隨著數(shù)據(jù)量的增大、訪問的集中,就會出現(xiàn)RDBMS的負擔加重、數(shù)據(jù)庫響應(yīng)惡化、 網(wǎng)站顯示延遲等重大影響。Memcached是高性能的分布式內(nèi)存緩存服務(wù)器,通過緩存數(shù)據(jù)庫查詢結(jié)果,減少數(shù)據(jù)庫訪問次數(shù),以提高動態(tài)Web等應(yīng)用的速度、 提高可擴展性。下圖展示了memcache與數(shù)據(jù)庫端協(xié)同工作情況:

redis、memcache原理對比

其中的過程是這樣的:

1.檢查用戶請求的數(shù)據(jù)是緩存中是否有存在,如果有存在的話,只需要直接把請求的數(shù)據(jù)返回,無需查詢數(shù)據(jù)庫。

2.如果請求的數(shù)據(jù)在緩存中找不到,這時候再去查詢數(shù)據(jù)庫。返回請求數(shù)據(jù)的同時,把數(shù)據(jù)存儲到緩存中一份。

3.保持緩存的“新鮮性”,每當數(shù)據(jù)發(fā)生變化的時候(比如,數(shù)據(jù)有被修改,或被刪除的情況下),要同步的更新緩存信息,確保用戶不會在緩存取到舊的數(shù)據(jù)。

Memcached作為高速運行的分布式緩存服務(wù)器,具有以下的特點:

協(xié)議簡單

基于libevent的事件處理

內(nèi)置內(nèi)存存儲方式

memcached不互相通信的分布式

4.3 如何實現(xiàn)分布式可拓展性?

Memcached的分布式不是在服務(wù)器端實現(xiàn)的,而是在客戶端應(yīng)用中實現(xiàn)的,即通過內(nèi)置算法制定目標數(shù)據(jù)的節(jié)點,如下圖所示:

redis、memcache原理對比

4.4 Redis 介紹

Redis是一個key-value存儲系統(tǒng)。和Memcached類似,它支持存儲的value類型相對更多,包括string(字符串)、 list(鏈表)、set(集合)和zset(有序集合)。這些數(shù)據(jù)類型都支持push/pop、add/remove及取交集并集和差集及更豐富的操作,而且這些操作都是原子性的。在此基礎(chǔ)上,redis支持各種不同方式的排序。與memcached一樣,為了保證效率,數(shù)據(jù)都是緩存在內(nèi)存中。區(qū)別的是redis會周期性的把更新的數(shù)據(jù)寫入磁盤或者把修改操作寫入追加的記錄文件,并且在此基礎(chǔ)上實現(xiàn)了master-slave(主從)同步,當前 Redis的應(yīng)用已經(jīng)非常廣泛,國內(nèi)像新浪、淘寶,國外像 Flickr、Github等均在使用Redis的緩存服務(wù)。

4.5 Redis 工作方式分析

Redis作為一個高性能的key-value數(shù)據(jù)庫具有以下特征:

多樣的數(shù)據(jù)模型

持久化

主從同步

Redis支持豐富的數(shù)據(jù)類型,最為常用的數(shù)據(jù)類型主要由五種:String、Hash、List、Set和Sorted Set。Redis通常將數(shù)據(jù)存儲于內(nèi)存中,或被配置為使用虛擬內(nèi)存。Redis有一個很重要的特點就是它可以實現(xiàn)持久化數(shù)據(jù),通過兩種方式可以實現(xiàn)數(shù)據(jù)持久化:使用RDB快照的方式,將內(nèi)存中的數(shù)據(jù)不斷寫入磁盤;或使用類似MySQL的AOF日志方式,記錄每次更新的日志。前者性能較高,但是可能會引起一定程度的數(shù)據(jù)丟失;后者相反。 Redis支持將數(shù)據(jù)同步到多臺從數(shù)據(jù)庫上,這種特性對提高讀取性能非常有益。

4.6 Redis如何實現(xiàn)分布式可拓展性?

2.8以前的版本:與Memcached一致,可以在客戶端實現(xiàn),也可以使用代理,twitter已開發(fā)出用于Redis和Memcached的代理Twemproxy 。

3.0 以后的版本:相較于Memcached只能采用客戶端實現(xiàn)分布式存儲,Redis則在服務(wù)器端構(gòu)建分布式存儲。Redis Cluster是一個實現(xiàn)了分布式且允許單點故障的Redis高級版本,它沒有中心節(jié)點,各個節(jié)點地位一致,具有線性可伸縮的功能。如圖給出Redis Cluster的分布式存儲架構(gòu),其中節(jié)點與節(jié)點之間通過二進制協(xié)議進行通信,節(jié)點與客戶端之間通過ascii協(xié)議進行通信。在數(shù)據(jù)的放置策略上,Redis Cluster將整個 key的數(shù)值域分成16384個哈希槽,每個節(jié)點上可以存儲一個或多個哈希槽,也就是說當前Redis Cluster支持的最大節(jié)點數(shù)就是16384

redis、memcache原理對比

五、綜合結(jié)論

應(yīng)該說Memcached和Redis都能很好的滿足解決我們的問題,它們性能都很高,總的來說,可以把Redis理解為是對Memcached的拓展,是更加重量級的實現(xiàn),提供了更多更強大的功能。具體來說:

1.性能上:

性能上都很出色,具體到細節(jié),由于Redis只使用單核,而Memcached可以使用多核,所以平均每一個核上Redis在存儲小數(shù)據(jù)時比

Memcached性能更高。而在100k以上的數(shù)據(jù)中,Memcached性能要高于Redis,雖然Redis最近也在存儲大數(shù)據(jù)的性能上進行優(yōu)化,但是比起 Memcached,還是稍有遜色。

2.內(nèi)存空間和數(shù)據(jù)量大小:

MemCached可以修改最大內(nèi)存,采用LRU算法。Redis增加了VM的特性,突破了物理內(nèi)存的限制。

3.操作便利上:

MemCached數(shù)據(jù)結(jié)構(gòu)單一,僅用來緩存數(shù)據(jù),而Redis支持更加豐富的數(shù)據(jù)類型,也可以在服務(wù)器端直接對數(shù)據(jù)進行豐富的操作,這樣可以減少網(wǎng)絡(luò)IO次數(shù)和數(shù)據(jù)體積。

4.可靠性上:

MemCached不支持數(shù)據(jù)持久化,斷電或重啟后數(shù)據(jù)消失,但其穩(wěn)定性是有保證的。Redis支持數(shù)據(jù)持久化和數(shù)據(jù)恢復,允許單點故障,但是同時也會付出性能的代價。

5.應(yīng)用場景:

Memcached:動態(tài)系統(tǒng)中減輕數(shù)據(jù)庫負載,提升性能;做緩存,適合多讀少寫,大數(shù)據(jù)量的情況(如人人網(wǎng)大量查詢用戶信息、好友信息、文章信息等)。

Redis:適用于對讀寫效率要求都很高,數(shù)據(jù)處理業(yè)務(wù)復雜和對安全性要求較高的系統(tǒng)(如新浪微博的計數(shù)和微博發(fā)布部分系統(tǒng),對數(shù)據(jù)安全性、讀寫要求都很高)。

六、需要慎重考慮的部分

1.Memcached單個key-value大小有限,一個value最大只支持1MB,而Redis最大支持512MB

2.Memcached只是個內(nèi)存緩存,對可靠性無要求;而Redis更傾向于內(nèi)存數(shù)據(jù)庫,因此對對可靠性方面要求比較高

3.從本質(zhì)上講,Memcached只是一個單一key-value內(nèi)存Cache;而Redis則是一個數(shù)據(jù)結(jié)構(gòu)內(nèi)存數(shù)據(jù)庫,支持五種數(shù)據(jù)類型,因此Redis除單純緩存作用外,還可以處理一些簡單的邏輯運算,Redis不僅可以緩存,而且還可以作為數(shù)據(jù)庫用

4.新版本(3.0)的Redis是指集群分布式,也就是說集群本身均衡客戶端請求,各個節(jié)點可以交流,可拓展行、可維護性更強大。

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學習之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報投訴
  • Redis
    +關(guān)注

    關(guān)注

    0

    文章

    392

    瀏覽量

    12185
  • memcache
    +關(guān)注

    關(guān)注

    0

    文章

    5

    瀏覽量

    2603
收藏 人收藏
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

    評論

    相關(guān)推薦
    熱點推薦

    Redis哨兵模式的自動故障檢測與主從切換實戰(zhàn)

    Redis 主從復制解決了讀擴展和數(shù)據(jù)冗余問題,但主節(jié)點故障時需要人工介入切換,這在生產(chǎn)環(huán)境中是不可接受的。Sentinel(哨兵)模式在主從架構(gòu)之上增加了自動故障檢測和故障轉(zhuǎn)移能力,是 Redis 高可用的標準方案之一。
    的頭像 發(fā)表于 02-27 11:05 ?121次閱讀

    Redis內(nèi)存管理、持久化策略與慢查詢排查分析

    Redis 在生產(chǎn)環(huán)境中承擔著緩存、會話存儲、消息隊列、分布式鎖等多種角色。隨著數(shù)據(jù)量增長和并發(fā)壓力上升,內(nèi)存碎片、持久化 I/O 抖動、慢查詢堆積這三類問題會逐漸顯現(xiàn),直接影響服務(wù)延遲和穩(wěn)定性。Redis 8.x 在內(nèi)存管理和持久化機制上做了若干改進,但核心調(diào)優(yōu)思路與
    的頭像 發(fā)表于 02-27 11:00 ?126次閱讀

    【產(chǎn)品應(yīng)用】儲能網(wǎng)關(guān)EM-1000與EM-1000G的Redis性能對比

    視頻推薦隨著儲能控制系統(tǒng)智能化發(fā)展,對實時處理和高速緩存需求提升。本測試對EM-1000與EM-1000G的Redis性能進行對比,評估其在吞吐、響應(yīng)與穩(wěn)定性上的差異,為客戶提供精準硬件選型依據(jù)
    的頭像 發(fā)表于 12-02 11:39 ?328次閱讀
    【產(chǎn)品應(yīng)用】儲能網(wǎng)關(guān)EM-1000與EM-1000G的<b class='flag-5'>Redis</b>性能<b class='flag-5'>對比</b>

    不同類型的自動化工具在評估數(shù)據(jù)緩存效果時有哪些優(yōu)缺點?

    在評估數(shù)據(jù)緩存效果時,不同類型的自動化工具(實時監(jiān)控類、性能測試類、深度分析類、云原生專屬類)因設(shè)計目標和技術(shù)特性不同,存在顯著的優(yōu)缺點差異。以下結(jié)合工具類型與具體場景,系統(tǒng)對比其核心優(yōu)劣勢,并給出
    的頭像 發(fā)表于 09-25 17:48 ?707次閱讀
    不同類型的自動化工具在評估數(shù)據(jù)緩存效果時有哪些優(yōu)缺點?

    深度剖析Redis的兩大持久化機制

    凌晨3點,我被一通緊急電話驚醒。線上Redis集群崩潰,6GB的緩存數(shù)據(jù)全部丟失,導致MySQL瞬間承壓暴增,整個交易系統(tǒng)陷入癱瘓。事后復盤發(fā)現(xiàn),問題的根源竟是一個被忽視的持久化配置細節(jié)。
    的頭像 發(fā)表于 09-17 16:22 ?542次閱讀

    Redis Sentinel和Cluster模式如何選擇

    在我十年的運維生涯中,見過太多團隊在Redis集群方案選擇上踩坑。有的團隊盲目追求"高大上"的Cluster模式,結(jié)果運維復雜度爆表;有的團隊死守Sentinel不放,最后擴展性成了瓶頸。今天,我想通過這篇萬字長文,把我在生產(chǎn)環(huán)境中積累的經(jīng)驗全部分享給你。
    的頭像 發(fā)表于 09-08 09:31 ?578次閱讀

    Redis集群部署配置詳解

    Redis集群是一種分布式Redis解決方案,通過數(shù)據(jù)分片和主從復制實現(xiàn)高可用性和橫向擴展。集群將整個數(shù)據(jù)集分割成16384個哈希槽(hash slots),每個節(jié)點負責一部分槽位。
    的頭像 發(fā)表于 07-17 11:04 ?978次閱讀

    Redis集群部署與性能優(yōu)化實戰(zhàn)

    Redis作為高性能的內(nèi)存數(shù)據(jù)庫,在現(xiàn)代互聯(lián)網(wǎng)架構(gòu)中扮演著關(guān)鍵角色。作為運維工程師,掌握Redis的部署、配置和優(yōu)化技能至關(guān)重要。本文將從實戰(zhàn)角度出發(fā),詳細介紹Redis集群的搭建、性能優(yōu)化以及監(jiān)控運維的核心技術(shù)。
    的頭像 發(fā)表于 07-08 17:56 ?849次閱讀

    【經(jīng)驗分享】在Omni3576上編譯Redis-8.0.2源碼,并安裝及性能測試

    本文首先介紹Redis是什么,然后介紹如何在Omni3576上編譯Redis-8.0.2源碼,以及從源碼編譯、安裝Redis,最后介紹如何在Omni3576上運行Redis性能測試,并
    的頭像 發(fā)表于 06-05 08:05 ?975次閱讀
    【經(jīng)驗分享】在Omni3576上編譯<b class='flag-5'>Redis</b>-8.0.2源碼,并安裝及性能測試

    【幸狐Omni3576邊緣計算套件試用體驗】Redis最新8.0.2版本源碼安裝及性能測試

    的結(jié)果進行對比。 一、Redis是什么 維基百科的介紹是: Redis是一個使用ANSI C編寫的開源、支持網(wǎng)絡(luò)、基于內(nèi)存、分布式、可選持久性的鍵值對存儲數(shù)據(jù)庫。 Redis官網(wǎng)的
    發(fā)表于 06-03 01:28

    磁珠與電感的對比

    本文分三部分,詳細的描述了電感的定義、磁珠的定義以及對比了磁珠與電感的區(qū)別,通過舉例方式詳細說明了磁珠的應(yīng)用場合和使用方法
    發(fā)表于 05-29 15:50

    Redis 8 向量搜索實測:輕松擴展至 10 億向量

    艾體寶Redis 8 向量搜索實測輕松支持 10 億向量,仍保持低延遲與高吞吐。中位延遲僅200毫秒,90%精確度;處理50并發(fā)搜索請求中位延遲僅1.3秒,95%精確度。
    的頭像 發(fā)表于 05-13 14:00 ?740次閱讀
    <b class='flag-5'>Redis</b> 8 向量搜索實測:輕松擴展至 10 億向量

    Redis 再次開源!

    “ ?Redis 現(xiàn)已采用 AGPLv3 開源許可證。? ” Redis CEO 的 Blog 以下是 Redis CEO Rowan Trollope 的 Blog: 像 AWS 和 GCP 這樣
    的頭像 發(fā)表于 05-06 18:26 ?928次閱讀

    redis三種集群方案詳解

    Redis中提供的集群方案總共有三種(一般一個redis節(jié)點不超過10G內(nèi)存)。
    的頭像 發(fā)表于 03-31 10:46 ?1529次閱讀
    <b class='flag-5'>redis</b>三種集群方案詳解

    光纖涂覆機技術(shù)對比

    電子發(fā)燒友網(wǎng)站提供《光纖涂覆機技術(shù)對比.pdf》資料免費下載
    發(fā)表于 03-28 17:50 ?0次下載