www.久久久久|狼友网站av天堂|精品国产无码a片|一级av色欲av|91在线播放视频|亚洲无码主播在线|国产精品草久在线|明星AV网站在线|污污内射久久一区|婷婷综合视频网站

當(dāng)前位置:首頁 > 公眾號精選 > 架構(gòu)師社區(qū)
[導(dǎo)讀]本文介紹了Redis高可用相關(guān)的機(jī)制。

來源:http://kaito-kidd.com/

從這篇文章開始,我們來介紹Redis高可用相關(guān)的機(jī)制。Redis要想實(shí)現(xiàn)高可用,主要有以下方面來保證:

  • 數(shù)據(jù)持久化

  • 主從復(fù)制

  • 自動(dòng)故障恢復(fù)

  • 集群化

這篇文章我們先介紹Redis的高可用保障的基礎(chǔ):數(shù)據(jù)持久化。因?yàn)镽edis的主從復(fù)制和自動(dòng)故障恢復(fù),都需要依賴Redis持久化相關(guān)的東西。同時(shí),Redis的數(shù)據(jù)持久化也可以用來做數(shù)據(jù)備份,用來保障數(shù)據(jù)的安全性。

Redis是一個(gè)內(nèi)存數(shù)據(jù)庫,它的數(shù)據(jù)都保存在內(nèi)存中,如果實(shí)例宕機(jī),那么數(shù)據(jù)則全部丟失。如何保證數(shù)據(jù)的完整性和安全性也是提高服務(wù)高可用的重要機(jī)制之一。

Redis提供了完善的持久化機(jī)制,可以把內(nèi)存中的數(shù)據(jù)持久化到磁盤上,方便我們進(jìn)行備份數(shù)據(jù)和快速恢復(fù)數(shù)據(jù)。

這篇文章我們就來分析Redis的數(shù)據(jù)持久化是如何實(shí)現(xiàn)的?我們經(jīng)常聽的RDB和AOF有什么區(qū)別?以及它們不同的使用場景。

持久化方式

Redis提供的數(shù)據(jù)持久化方式主要有2種:

  • RDB:產(chǎn)生一個(gè)數(shù)據(jù)快照文件

  • AOF:實(shí)時(shí)追加命令的日志文件

它們分別對應(yīng)了不同的使用場景,下面我們就來依次分析。

RDB

RDB全稱Redis Database Backup file(Redis數(shù)據(jù)備份文件),也被叫做Redis數(shù)據(jù)快照。

我們可以通過執(zhí)行save或bgsave命令讓Redis在本地生成RDB快照文件,這個(gè)RDB文件包含了整個(gè)實(shí)例接近完整的數(shù)據(jù)內(nèi)容。

不知道這些,簡歷上千萬不要說你會(huì)Redis持久化

它的優(yōu)點(diǎn)如下:

  • RDB文件數(shù)據(jù)是被壓縮寫入的,因此RDB文件的體積要比整個(gè)實(shí)例內(nèi)存要小

  • 當(dāng)實(shí)例宕機(jī)恢復(fù)時(shí),加載RDB文件的速度很快,能夠在很短時(shí)間內(nèi)迅速恢復(fù)文件中的數(shù)據(jù)

它的缺點(diǎn)也很明顯:

  • 由于是某一時(shí)刻的數(shù)據(jù)快照,因此它的數(shù)據(jù)并不全

  • 生成RDB文件的代價(jià)是比較大的,它會(huì)消耗大量的CPU和內(nèi)存資源

因此RDB比較適用于以下場景:

  • 主從全量同步數(shù)據(jù)

  • 數(shù)據(jù)庫備份

  • 對于丟失數(shù)據(jù)不敏感的業(yè)務(wù)場景,實(shí)例宕機(jī)后快速恢復(fù)數(shù)據(jù)

Redis主從全量同步數(shù)據(jù)就是使用RDB文件進(jìn)行的,我們會(huì)在后面的文章詳細(xì)講到。

由此可以看出,RDB非常適合做數(shù)據(jù)備份,我們可以定時(shí)讓Redis生成RDB文件,然后備份這個(gè)快照文件即可。

定時(shí)生成RDB

Redis也提供了定時(shí)觸發(fā)生成RDB文件的配置項(xiàng):

#?最近15分鐘內(nèi)?至少產(chǎn)生1次寫入 save 900 1 #?最近5分鐘內(nèi)?至少產(chǎn)生10次寫入 save 300 10 #?最近1分鐘內(nèi)?至少產(chǎn)生10000次寫入 save 60 10000 

如果達(dá)到以上任意條件,則Redis會(huì)自動(dòng)生成新的RDB文件,降低RDB數(shù)據(jù)內(nèi)容與實(shí)例數(shù)據(jù)的差異。

Copy On Write

在Redis上執(zhí)行save和bgsave命令都可以生成RDB文件,但前者是在前臺執(zhí)行的,也就是說在生成RDB文件時(shí),會(huì)阻塞整個(gè)實(shí)例,在RDB未生成之前,任何請求都是無法處理的,對于內(nèi)存很大的實(shí)例,生成RDB文件非常耗時(shí),顯然這是我們不能接受的。

所以通常我們會(huì)選擇執(zhí)行bgsave讓Redis在后臺生成RDB文件,這樣Redis依舊可以處理客戶端請求,不會(huì)阻塞整個(gè)實(shí)例。

但不是說后臺生成RDB就是沒有代價(jià)的,Redis為了實(shí)現(xiàn)后臺把內(nèi)存數(shù)據(jù)的快照寫入文件,采用了操作系統(tǒng)提供的Copy On Write技術(shù),也就是我們熟知的fork系統(tǒng)調(diào)用。

fork系統(tǒng)調(diào)用會(huì)產(chǎn)生一個(gè)子進(jìn)程,它與父進(jìn)程共享相同的內(nèi)存地址空間,這樣子進(jìn)程在這一時(shí)刻就能擁有與父進(jìn)程的相同的內(nèi)存數(shù)據(jù)。

雖然子進(jìn)程與父進(jìn)程共享同一塊內(nèi)存地址空間,但在fork子進(jìn)程時(shí),操作系統(tǒng)需要拷貝父進(jìn)程的內(nèi)存頁表給子進(jìn)程,如果整個(gè)Redis實(shí)例內(nèi)存占用很大,那么它的內(nèi)存頁表也會(huì)很大,在拷貝時(shí)就會(huì)比較耗時(shí),同時(shí)這個(gè)過程會(huì)消耗大量的CPU資源。在完成拷貝之前父進(jìn)程也處于阻塞狀態(tài),無法處理客戶端請求。

fork執(zhí)行完之后,子進(jìn)程就可以掃描自身所有的內(nèi)存數(shù)據(jù),然后把全部數(shù)據(jù)寫入到RDB文件中。

之后父進(jìn)程依舊處理客戶端的請求,當(dāng)在處理寫命令時(shí),父進(jìn)程會(huì)重新分配新的內(nèi)存地址空間,從操作系統(tǒng)申請新的內(nèi)存使用,不再與子進(jìn)程共享,這個(gè)過程就是Copy On Write(寫實(shí)復(fù)制)名字的由來。這樣父子進(jìn)程的內(nèi)存就會(huì)逐漸分離,父進(jìn)程申請新的內(nèi)存空間并更改內(nèi)存數(shù)據(jù),子進(jìn)程的內(nèi)存數(shù)據(jù)不受影響。

由此可以看出,在生成RDB文件時(shí),不僅消耗CPU資源,還有需要占用最多一倍的內(nèi)存空間。

我們在Redis執(zhí)行info命令,可以看到fork子進(jìn)程的耗時(shí),可以通過這個(gè)耗時(shí)來評估fork時(shí)間是否符合預(yù)期。同時(shí)我們應(yīng)該保證Redis機(jī)器擁有足夠的CPU和內(nèi)存資源,并合理設(shè)置生成RDB的時(shí)機(jī)。

AOF

AOF全稱為Append Only File(追加日志文件)。它與RDB不同的是,AOF中記錄的是每一個(gè)命令的詳細(xì)信息,包括完整的命令類型、參數(shù)等。只要產(chǎn)生寫命令,就會(huì)實(shí)時(shí)寫入到AOF文件中。

不知道這些,簡歷上千萬不要說你會(huì)Redis持久化

我們可以通過配置文件開啟AOF:

#?開啟AOF appendonly yes #?AOF文件名 appendfilename "appendonly.aof" #?文件刷盤方式 appendfsync?everysec

刷盤方式

開啟AOF后,Redis會(huì)把每個(gè)寫操作的命令記錄到文件并持久化到磁盤中,為了保證數(shù)據(jù)文件的安全性,Redis還提供了文件刷盤的時(shí)機(jī):

  • appendfsync always:每次寫入都刷盤,對性能影響最大,占用磁盤IO比較高,數(shù)據(jù)安全性最高

  • appendfsync everysec:1秒刷一次盤,對性能影響相對較小,節(jié)點(diǎn)宕機(jī)時(shí)最多丟失1秒的數(shù)據(jù)

  • appendfsync no:按照操作系統(tǒng)的機(jī)制刷盤,對性能影響最小,數(shù)據(jù)安全性低,節(jié)點(diǎn)宕機(jī)丟失數(shù)據(jù)取決于操作系統(tǒng)刷盤機(jī)制

以上可以看出AOF相對于RDB的優(yōu)點(diǎn)是,AOF數(shù)據(jù)文件更新比較及時(shí),比RDB保存更完整的數(shù)據(jù),這樣在數(shù)據(jù)恢復(fù)時(shí)能夠恢復(fù)盡量完整的數(shù)據(jù),降低丟失數(shù)據(jù)的風(fēng)險(xiǎn)。

如果同時(shí)存在RDB文件和AOF文件,Redis會(huì)優(yōu)先使用AOF文件進(jìn)行數(shù)據(jù)恢復(fù)。

但它的缺點(diǎn)也很易見:

  • 隨著時(shí)間增長,AOF文件會(huì)越來越大

  • AOF文件刷盤會(huì)增加磁盤IO的負(fù)擔(dān),可能影響Redis的性能(開啟每秒刷盤時(shí))

AOF重寫

針對第一種情況,Redis提供了AOF瘦身的功能,可以設(shè)置在AOF文件很大時(shí),自動(dòng)觸發(fā)AOF重寫,Redis會(huì)掃描整個(gè)實(shí)例的數(shù)據(jù),重新生成一個(gè)AOF文件達(dá)成瘦身的效果。但這個(gè)重寫過程也需要消耗大量的CPU資源。

#?AOF文件距離上次文件增長超過多少百分比則觸發(fā)重寫 auto-aof-rewrite-percentage 100 #?AOF文件體積最小多大以上才觸發(fā)重寫 auto-aof-rewrite-min-size 64mb

由于AOF可以最大可能降低丟失數(shù)據(jù)的風(fēng)險(xiǎn),所以它一般適用于對丟失數(shù)據(jù)很敏感的業(yè)務(wù)場景,例如涉及金錢交易的業(yè)務(wù)。

性能影響

如果AOF的刷盤時(shí)機(jī)設(shè)置為每次寫入都刷盤,那么會(huì)大大降低Redis的寫入性能,因?yàn)槊看螌懨疃夹枰獙懭胛募⑺⒌酱疟P中才會(huì)返回,當(dāng)寫入量很大時(shí),會(huì)增加磁盤IO的負(fù)擔(dān)。

性能與數(shù)據(jù)安全不能兼得,雖然Redis提供了實(shí)時(shí)刷盤的機(jī)制,但是在真正場景中使用的不多。

通常我們會(huì)選擇每秒刷盤這種方式,既能保證良好的寫入性能,在實(shí)例宕機(jī)時(shí)最多丟失1秒的數(shù)據(jù),做到性能和安全的平衡。

總結(jié)

我們對RDB和AOF的總結(jié)如下表。

不知道這些,簡歷上千萬不要說你會(huì)Redis持久化


我們需要針對不同的業(yè)務(wù)場景選擇合適的持久化方式,也可以根據(jù)RDB和AOF的優(yōu)點(diǎn)配合使用,保證Redis數(shù)據(jù)的安全性,又可以兼顧它的性能。


免責(zé)聲明:本文內(nèi)容由21ic獲得授權(quán)后發(fā)布,版權(quán)歸原作者所有,本平臺僅提供信息存儲服務(wù)。文章僅代表作者個(gè)人觀點(diǎn),不代表本平臺立場,如有問題,請聯(lián)系我們,謝謝!

本站聲明: 本文章由作者或相關(guān)機(jī)構(gòu)授權(quán)發(fā)布,目的在于傳遞更多信息,并不代表本站贊同其觀點(diǎn),本站亦不保證或承諾內(nèi)容真實(shí)性等。需要轉(zhuǎn)載請聯(lián)系該專欄作者,如若文章內(nèi)容侵犯您的權(quán)益,請及時(shí)聯(lián)系本站刪除。
換一批
延伸閱讀

9月2日消息,不造車的華為或?qū)⒋呱龈蟮莫?dú)角獸公司,隨著阿維塔和賽力斯的入局,華為引望愈發(fā)顯得引人矚目。

關(guān)鍵字: 阿維塔 塞力斯 華為

加利福尼亞州圣克拉拉縣2024年8月30日 /美通社/ -- 數(shù)字化轉(zhuǎn)型技術(shù)解決方案公司Trianz今天宣布,該公司與Amazon Web Services (AWS)簽訂了...

關(guān)鍵字: AWS AN BSP 數(shù)字化

倫敦2024年8月29日 /美通社/ -- 英國汽車技術(shù)公司SODA.Auto推出其旗艦產(chǎn)品SODA V,這是全球首款涵蓋汽車工程師從創(chuàng)意到認(rèn)證的所有需求的工具,可用于創(chuàng)建軟件定義汽車。 SODA V工具的開發(fā)耗時(shí)1.5...

關(guān)鍵字: 汽車 人工智能 智能驅(qū)動(dòng) BSP

北京2024年8月28日 /美通社/ -- 越來越多用戶希望企業(yè)業(yè)務(wù)能7×24不間斷運(yùn)行,同時(shí)企業(yè)卻面臨越來越多業(yè)務(wù)中斷的風(fēng)險(xiǎn),如企業(yè)系統(tǒng)復(fù)雜性的增加,頻繁的功能更新和發(fā)布等。如何確保業(yè)務(wù)連續(xù)性,提升韌性,成...

關(guān)鍵字: 亞馬遜 解密 控制平面 BSP

8月30日消息,據(jù)媒體報(bào)道,騰訊和網(wǎng)易近期正在縮減他們對日本游戲市場的投資。

關(guān)鍵字: 騰訊 編碼器 CPU

8月28日消息,今天上午,2024中國國際大數(shù)據(jù)產(chǎn)業(yè)博覽會(huì)開幕式在貴陽舉行,華為董事、質(zhì)量流程IT總裁陶景文發(fā)表了演講。

關(guān)鍵字: 華為 12nm EDA 半導(dǎo)體

8月28日消息,在2024中國國際大數(shù)據(jù)產(chǎn)業(yè)博覽會(huì)上,華為常務(wù)董事、華為云CEO張平安發(fā)表演講稱,數(shù)字世界的話語權(quán)最終是由生態(tài)的繁榮決定的。

關(guān)鍵字: 華為 12nm 手機(jī) 衛(wèi)星通信

要點(diǎn): 有效應(yīng)對環(huán)境變化,經(jīng)營業(yè)績穩(wěn)中有升 落實(shí)提質(zhì)增效舉措,毛利潤率延續(xù)升勢 戰(zhàn)略布局成效顯著,戰(zhàn)新業(yè)務(wù)引領(lǐng)增長 以科技創(chuàng)新為引領(lǐng),提升企業(yè)核心競爭力 堅(jiān)持高質(zhì)量發(fā)展策略,塑強(qiáng)核心競爭優(yōu)勢...

關(guān)鍵字: 通信 BSP 電信運(yùn)營商 數(shù)字經(jīng)濟(jì)

北京2024年8月27日 /美通社/ -- 8月21日,由中央廣播電視總臺與中國電影電視技術(shù)學(xué)會(huì)聯(lián)合牽頭組建的NVI技術(shù)創(chuàng)新聯(lián)盟在BIRTV2024超高清全產(chǎn)業(yè)鏈發(fā)展研討會(huì)上宣布正式成立。 活動(dòng)現(xiàn)場 NVI技術(shù)創(chuàng)新聯(lián)...

關(guān)鍵字: VI 傳輸協(xié)議 音頻 BSP

北京2024年8月27日 /美通社/ -- 在8月23日舉辦的2024年長三角生態(tài)綠色一體化發(fā)展示范區(qū)聯(lián)合招商會(huì)上,軟通動(dòng)力信息技術(shù)(集團(tuán))股份有限公司(以下簡稱"軟通動(dòng)力")與長三角投資(上海)有限...

關(guān)鍵字: BSP 信息技術(shù)
關(guān)閉
關(guān)閉