下載本文檔
版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進(jìn)行舉報或認(rèn)領(lǐng)
文檔簡介
Redis幾個認(rèn)識誤區(qū)前幾天微博發(fā)生了一起大的系統(tǒng)故障,很多技術(shù)的朋友都比較關(guān)心,其中的原因不會超出JamesHamilton在OnDesigningandDeployingInternet-ScaleService(1)概括的那幾個范圍,James第一條經(jīng)驗“Designforfailure”是所有互聯(lián)網(wǎng)架構(gòu)成功的一個關(guān)鍵?;ヂ?lián)網(wǎng)系統(tǒng)的工程理論其實非常簡單,Jamespaper中內(nèi)容幾乎稱不上理論,而是多條實踐經(jīng)驗分享,每個公司對這些經(jīng)驗的理解及執(zhí)行力決定了架構(gòu)成敗。題外話說完,最近又研究了Redis。去年曾做過一個MemcacheDB,TokyoTyrant,Redisperformancetest,到目前為止,這個benchmark結(jié)果依然有效。這1年我們經(jīng)歷了很多眼花繚亂的keyvalue存儲產(chǎn)品的誘惑,從Cassandra的淡出(Twitter暫停在主業(yè)務(wù)使用)到HBase的興起(Facebook新的郵箱業(yè)務(wù)選用HBase(2)),當(dāng)再回頭再去看Redis,發(fā)現(xiàn)這個只有1萬多行源代碼的程序充滿了神奇及大量未經(jīng)挖掘的特性。Redis性能驚人,國內(nèi)前十大網(wǎng)站的子產(chǎn)品估計用1臺Redis就可以滿足存儲及Cache的需求。除了性能印象之外,業(yè)界其實普遍對Redis的認(rèn)識存在一定誤區(qū)。本文提出一些觀點供大家探討。1.Redis是什么這個問題的結(jié)果影響了我們怎么用Redis。如果你認(rèn)為Redis是一個keyvaluestore,那可能會用它來代替MySQL;如果認(rèn)為它是一個可以持久化的cache,可能只是它保存一些頻繁訪問的臨時數(shù)據(jù)。Redis是REmoteDIctionaryServer的縮寫,在Redis在官方網(wǎng)站的的副標(biāo)題是Apersistentkey-valuedatabasewithbuilt-innetinterfacewritteninANSI-CforPosixsystems,這個定義偏向keyvaluestore。還有一些看法則認(rèn)為Redis是一個memorydatabase,因為它的高性能都是基于內(nèi)存操作的基礎(chǔ)。另外一些人則認(rèn)為Redis是一個datastructureserver,因為Redis支持復(fù)雜的數(shù)據(jù)特性,比如List,Set等。對Redis的作用的不同解讀決定了你對Redis的使用方式。互聯(lián)網(wǎng)數(shù)據(jù)目前基本使用兩種方式來存儲,關(guān)系數(shù)據(jù)庫或者keyvalue。但是這些互聯(lián)網(wǎng)業(yè)務(wù)本身并不屬于這兩種數(shù)據(jù)類型,比如用戶在社會化平臺中的關(guān)系,它是一個list,如果要用關(guān)系數(shù)據(jù)庫存儲就需要轉(zhuǎn)換成一種多行記錄的形式,這種形式存在很多冗余數(shù)據(jù),每一行需要存儲一些重復(fù)信息。如果用keyvalue存儲則修改和刪除比較麻煩,需要將全部數(shù)據(jù)讀出再寫入。Redis在內(nèi)存中設(shè)計了各種數(shù)據(jù)類型,讓業(yè)務(wù)能夠高速原子的訪問這些數(shù)據(jù)結(jié)構(gòu),并且不需要關(guān)心持久存儲的問題,從架構(gòu)上解決了前面兩種存儲需要走一些彎路的問題。2.Redis不可能比Memcache快很多開發(fā)者都認(rèn)為Redis不可能比Memcached快,Memcached完全基于內(nèi)存,而Redis具有持久化保存特性,即使是異步的,Redis也不可能比Memcached快。但是測試結(jié)果基本是Redis占絕對優(yōu)勢。一直在思考這個原因,目前想到的原因有這幾方面。Libevent。和Memcached不同,Redis并沒有選擇libevent。Libevent為了迎合通用性造成代碼龐大(目前Redis代碼還不到libevent的1/3)及犧牲了在特定平臺的不少性能。Redis用libevent中兩個文件修改實現(xiàn)了自己的epolleventloop(4)。業(yè)界不少開發(fā)者也建議Redis使用另外一個libevent高性能替代libev,但是作者還是堅持Redis應(yīng)該小巧并去依賴的思路。一個印象深刻的細(xì)節(jié)是編譯Redis之前并不需要執(zhí)行./configure。CAS問題。CAS是Memcached中比較方便的一種防止競爭修改資源的方法。CAS實現(xiàn)需要為每個cachekey設(shè)置一個隱藏的castoken,cas相當(dāng)value版本號,每次set會token需要遞增,因此帶來CPU和內(nèi)存的雙重開銷,雖然這些開銷很小,但是到單機(jī)10G+cache以及QPS上萬之后這些開銷就會給雙方相對帶來一些細(xì)微性能差別(5)。3.單臺Redis的存放數(shù)據(jù)必須比物理內(nèi)存小Redis的數(shù)據(jù)全部放在內(nèi)存帶來了高速的性能,但是也帶來一些不合理之處。比如一個中型網(wǎng)站有100萬注冊用戶,如果這些資料要用Redis來存儲,內(nèi)存的容量必須能夠容納這100萬用戶。但是業(yè)務(wù)實際情況是100萬用戶只有5萬活躍用戶,1周來訪問過1次的也只有15萬用戶,因此全部100萬用戶的數(shù)據(jù)都放在內(nèi)存有不合理之處,RAM需要為冷數(shù)據(jù)買單。這跟操作系統(tǒng)非常相似,操作系統(tǒng)所有應(yīng)用訪問的數(shù)據(jù)都在內(nèi)存,但是如果物理內(nèi)存容納不下新的數(shù)據(jù),操作系統(tǒng)會智能將部分長期沒有訪問的數(shù)據(jù)交換到磁盤,為新的應(yīng)用留出空間。現(xiàn)代操作系統(tǒng)給應(yīng)用提供的并不是物理內(nèi)存,而是虛擬內(nèi)存(VirtualMemory)的概念?;谙嗤目紤],Redis2.0也增加了VM特性。讓Redis數(shù)據(jù)容量突破了物理內(nèi)存的限制。并實現(xiàn)了數(shù)據(jù)冷熱分離。4.Redis的VM實現(xiàn)是重復(fù)造輪子Redis的VM依照之前的epoll實現(xiàn)思路依舊是自己實現(xiàn)。但是在前面操作系統(tǒng)的介紹提到OS也可以自動幫程序?qū)崿F(xiàn)冷熱數(shù)據(jù)分離,Redis只需要OS申請一塊大內(nèi)存,OS會自動將熱數(shù)據(jù)放入物理內(nèi)存,冷數(shù)據(jù)交換到硬盤,另外一個知名的“理解了現(xiàn)代操作系統(tǒng)(3)”的Varnish就是這樣實現(xiàn),也取得了非常成功的效果。作者antirez在解釋為什么要自己實現(xiàn)VM中提到幾個原因(6)。主要OS的VM換入換出是基于Page概念,比如OSVM1個Page是4K,4K中只要還有一個元素即使只有1個字節(jié)被訪問,這個頁也不會被SWAP,換入也同樣道理,讀到一個字節(jié)可能會換入4K無用的內(nèi)存。而Redis自己實現(xiàn)則可以達(dá)到控制換入的粒度。另外訪問操作系統(tǒng)SWAP內(nèi)存區(qū)域時block進(jìn)程,也是導(dǎo)致Redis要自己實現(xiàn)VM原因之一。5.用get/set方式使用Redis作為一個keyvalue存在,很多開發(fā)者自然的使用set/get方式來使用Redis,實際上這并不是最優(yōu)化的使用方法。尤其在未啟用VM情況下,Redis全部數(shù)據(jù)需要放入內(nèi)存,節(jié)約內(nèi)存尤其重要。假如一個key-value單元需要最小占用512字節(jié),即使只存一個字節(jié)也占了512字節(jié)。這時候就有一個設(shè)計模式,可以把key復(fù)用,幾個key-value放入一個key中,value再作為一個set存入,這樣同樣512字節(jié)就會存放10-100倍的容量。這就是為了節(jié)約內(nèi)存,建議使用hashset而不是set/get的方式來使用Redis,詳細(xì)方法見參考文獻(xiàn)(7)。6.使用aof代替snapshotRedis有兩種存儲方式,默認(rèn)是snapshot方式,實現(xiàn)方法是定時將內(nèi)存的快照(snapshot)持久化到硬盤,這種方法缺點是持久化之后如果出現(xiàn)crash則會丟失一段數(shù)據(jù)。因此在完美主義者的推動下作者增加了aof方式。aof即appendonlymode,在寫入內(nèi)存數(shù)據(jù)的同時將操作命令保存到日志文件,在一個并發(fā)更改上萬的系統(tǒng)中,命令日志是一個非常龐大的數(shù)據(jù),管理維護(hù)成本非常高,恢復(fù)重建時間會非常長,這樣導(dǎo)致失去aof高可用性本意。另外更重要的是Redis是一個內(nèi)存數(shù)據(jù)結(jié)構(gòu)模型,所有的優(yōu)勢都是建立在對內(nèi)存復(fù)雜數(shù)據(jù)結(jié)構(gòu)高效的原子操作上,這樣就看出aof是一個非常不協(xié)調(diào)的部分。其實aof目的主要是數(shù)據(jù)可靠性及高可用性,在Redis中有另外一種方法來達(dá)到目的:Replication。由于Redis的高性能,復(fù)制基本沒有延遲。這樣達(dá)到了防止單點故障及實現(xiàn)了高可用。小結(jié)要想成功使用一種產(chǎn)品,我們需要深入了解它的特性。Redis性能突出,如果能夠熟練的駕馭,對國內(nèi)很多大型應(yīng)用具有很大幫助。希望更多同行加入到Redis使用及代碼研究行列。參考文獻(xiàn)OnDesigningandDeployingInternet-ScaleService(PDF)Facebook’sNewReal-TimeMessagingSystem:HBaseToStore135+BillionMessagesAMonthWhat’swrongwith1975programmingHYPERLINK"/g
溫馨提示
- 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
- 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
- 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
- 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
- 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負(fù)責(zé)。
- 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
- 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。
最新文檔
- 工作總結(jié)之互聯(lián)網(wǎng)實習(xí)總結(jié)
- 2024年無機(jī)械動力飛機(jī)項目資金申請報告代可行性研究報告
- 《侵犯人身權(quán)利罪》課件
- 銀行員工績效評估制度
- 酒店餐飲服務(wù)流程優(yōu)化與提升制度
- 【大學(xué)課件】學(xué)習(xí)科學(xué)與技術(shù)
- 《保險業(yè)務(wù)需求分析》課件
- 學(xué)生關(guān)于珍愛生命的演講稿(34篇)
- 陜西省咸陽市武功縣2024屆九年級上學(xué)期期末考試數(shù)學(xué)試卷(含答案)
- 2024數(shù)字醫(yī)療年度創(chuàng)新白皮書 醫(yī)療大模型開啟“百模大戰(zhàn)”數(shù)字醫(yī)療單筆融資創(chuàng)紀(jì)錄
- 中華人民共和國文物保護(hù)法
- 2024《整治形式主義為基層減負(fù)若干規(guī)定》全文課件
- 常用統(tǒng)計軟件應(yīng)用智慧樹知到期末考試答案章節(jié)答案2024年揚州大學(xué)
- 中國法律史-第三次平時作業(yè)-國開-參考資料
- 區(qū)域分析與規(guī)劃智慧樹知到期末考試答案章節(jié)答案2024年寧波大學(xué)
- 食品營養(yǎng)學(xué)(暨南大學(xué))智慧樹知到期末考試答案2024年
- 2024年全國高考物理電學(xué)實驗真題(附答案)
- 國有企業(yè)合規(guī)管理
- 《膽囊癌診斷和治療指南》(2023年版)解讀
- GB/T 17646-2017小型風(fēng)力發(fā)電機(jī)組
- 教科版科學(xué)五年級上冊科學(xué)復(fù)習(xí)計劃
評論
0/150
提交評論