Redis 优缺点
REmote DIctionary Server(Redis) 是一個(gè)由Salvatore Sanfilippo寫的key-value存儲(chǔ)系統(tǒng)。
Redis是一個(gè)開源的使用ANSI C語(yǔ)言編寫、遵守BSD協(xié)議、支持網(wǎng)絡(luò)、可基于內(nèi)存亦可持久化的日志型、Key-Value數(shù)據(jù)庫(kù),并提供多種語(yǔ)言的API。
Redis 與其他 key - value 緩存產(chǎn)品有以下三個(gè)特點(diǎn):
- Redis支持?jǐn)?shù)據(jù)的持久化,可以將內(nèi)存中的數(shù)據(jù)保持在磁盤中,重啟的時(shí)候可以再次加載進(jìn)行使用。
- Redis不僅僅支持簡(jiǎn)單的key-value類型的數(shù)據(jù),同時(shí)還提供list,set,zset,hash等數(shù)據(jù)結(jié)構(gòu)的存儲(chǔ)。
- Redis支持?jǐn)?shù)據(jù)的備份,即master-slave模式的數(shù)據(jù)備份。
Redis 優(yōu)勢(shì)
- 性能極高?– Redis能讀的速度是110000次/s,寫的速度是81000次/s 。
- 豐富的數(shù)據(jù)類型 – Redis支持二進(jìn)制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 數(shù)據(jù)類型操作。
- 原子 – Redis的所有操作都是原子性的,同時(shí)Redis還支持對(duì)幾個(gè)操作全并后的原子性執(zhí)行。
- 豐富的特性?– Redis還支持 publish/subscribe, 通知, key 過(guò)期等等特性。
Redis與其他key-value存儲(chǔ)有什么不同?
-
Redis有著更為復(fù)雜的數(shù)據(jù)結(jié)構(gòu)并且提供對(duì)他們的原子性操作,這是一個(gè)不同于其他數(shù)據(jù)庫(kù)的進(jìn)化路徑。Redis的數(shù)據(jù)類型都是基于基本數(shù)據(jù)結(jié)構(gòu)的同時(shí)對(duì)程序員透明,無(wú)需進(jìn)行額外的抽象。
-
Redis運(yùn)行在內(nèi)存中但是可以持久化到磁盤,所以在對(duì)不同數(shù)據(jù)集進(jìn)行高速讀寫時(shí)需要權(quán)衡內(nèi)存,應(yīng)為數(shù)據(jù)量不能大于硬件內(nèi)存。在內(nèi)存數(shù)據(jù)庫(kù)方面的另一個(gè)優(yōu)點(diǎn)是,相比在磁盤上相同的復(fù)雜的數(shù)據(jù)結(jié)構(gòu),在內(nèi)存中操作起來(lái)非常簡(jiǎn)單,這樣Redis可以做很多內(nèi)部復(fù)雜性很強(qiáng)的事情。同時(shí),在磁盤格式方面他們是緊湊的以追加的方式產(chǎn)生的,因?yàn)樗麄儾⒉恍枰M(jìn)行隨機(jī)訪問。?
【聊聊redis持久化 – RDB】
RDB方式,是將redis某一時(shí)刻的數(shù)據(jù)持久化到磁盤中,是一種快照式的持久化方法。
redis在進(jìn)行數(shù)據(jù)持久化的過(guò)程中,會(huì)先將數(shù)據(jù)寫入到一個(gè)臨時(shí)文件中,待持久化過(guò)程都結(jié)束了,才會(huì)用這個(gè)臨時(shí)文件替換上次持久化好的文件。正是這種特性,讓我們可以隨時(shí)來(lái)進(jìn)行備份,因?yàn)榭煺瘴募偸峭暾捎玫摹?/span>
對(duì)于RDB方式,redis會(huì)單獨(dú)創(chuàng)建(fork)一個(gè)子進(jìn)程來(lái)進(jìn)行持久化,而主進(jìn)程是不會(huì)進(jìn)行任何IO操作的,這樣就確保了redis極高的性能。
如果需要進(jìn)行大規(guī)模數(shù)據(jù)的恢復(fù),且對(duì)于數(shù)據(jù)恢復(fù)的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效。
雖然RDB有不少優(yōu)點(diǎn),但它的缺點(diǎn)也是不容忽視的。如果你對(duì)數(shù)據(jù)的完整性非常敏感,那么RDB方式就不太適合你,因?yàn)榧词鼓忝?分鐘都持久化一次,當(dāng)redis故障時(shí),仍然會(huì)有近5分鐘的數(shù)據(jù)丟失。所以,redis還提供了另一種持久化方式,那就是AOF。
【聊聊redis持久化 – AOF】
AOF,英文是Append Only File,即只允許追加不允許改寫的文件。
如前面介紹的,AOF方式是將執(zhí)行過(guò)的寫指令記錄下來(lái),在數(shù)據(jù)恢復(fù)時(shí)按照從前到后的順序再將指令都執(zhí)行一遍,就這么簡(jiǎn)單。
我們通過(guò)配置redis.conf中的appendonly yes就可以打開AOF功能。如果有寫操作(如SET等),redis就會(huì)被追加到AOF文件的末尾。
默認(rèn)的AOF持久化策略是每秒鐘fsync一次(fsync是指把緩存中的寫指令記錄到磁盤中),因?yàn)樵谶@種情況下,redis仍然可以保持很好的處理性能,即使redis故障,也只會(huì)丟失最近1秒鐘的數(shù)據(jù)。
如果在追加日志時(shí),恰好遇到磁盤空間滿、inode滿或斷電等情況導(dǎo)致日志寫入不完整,也沒有關(guān)系,redis提供了redis-check-aof工具,可以用來(lái)進(jìn)行日志修復(fù)。
因?yàn)椴捎昧俗芳臃绞?#xff0c;如果不做任何處理的話,AOF文件會(huì)變得越來(lái)越大,為此,redis提供了AOF文件重寫(rewrite)機(jī)制,即當(dāng)AOF文件的大小超過(guò)所設(shè)定的閾值時(shí),redis就會(huì)啟動(dòng)AOF文件的內(nèi)容壓縮,只保留可以恢復(fù)數(shù)據(jù)的最小指令集。舉個(gè)例子或許更形象,假如我們調(diào)用了100次INCR指令,在AOF文件中就要存儲(chǔ)100條指令,但這明顯是很低效的,完全可以把這100條指令合并成一條SET指令,這就是重寫機(jī)制的原理。
在進(jìn)行AOF重寫時(shí),仍然是采用先寫臨時(shí)文件,全部完成后再替換的流程,所以斷電、磁盤滿等問題都不會(huì)影響AOF文件的可用性,這點(diǎn)大家可以放心。
AOF方式的另一個(gè)好處,我們通過(guò)一個(gè)“場(chǎng)景再現(xiàn)”來(lái)說(shuō)明。某同學(xué)在操作redis時(shí),不小心執(zhí)行了FLUSHALL,導(dǎo)致redis內(nèi)存中的數(shù)據(jù)全部被清空了,這是很悲劇的事情。不過(guò)這也不是世界末日,只要redis配置了AOF持久化方式,且AOF文件還沒有被重寫(rewrite),我們就可以用最快的速度暫停redis并編輯AOF文件,將最后一行的FLUSHALL命令刪除,然后重啟redis,就可以恢復(fù)redis的所有數(shù)據(jù)到FLUSHALL之前的狀態(tài)了。是不是很神奇,這就是AOF持久化方式的好處之一。但是如果AOF文件已經(jīng)被重寫了,那就無(wú)法通過(guò)這種方法來(lái)恢復(fù)數(shù)據(jù)了。
雖然優(yōu)點(diǎn)多多,但AOF方式也同樣存在缺陷,比如在同樣數(shù)據(jù)規(guī)模的情況下,AOF文件要比RDB文件的體積大。而且,AOF方式的恢復(fù)速度也要慢于RDB方式。
如果你直接執(zhí)行BGREWRITEAOF命令,那么redis會(huì)生成一個(gè)全新的AOF文件,其中便包括了可以恢復(fù)現(xiàn)有數(shù)據(jù)的最少的命令集。
如果運(yùn)氣比較差,AOF文件出現(xiàn)了被寫壞的情況,也不必過(guò)分擔(dān)憂,redis并不會(huì)貿(mào)然加載這個(gè)有問題的AOF文件,而是報(bào)錯(cuò)退出。這時(shí)可以通過(guò)以下步驟來(lái)修復(fù)出錯(cuò)的文件:
1.備份被寫壞的AOF文件
2.運(yùn)行redis-check-aof –fix進(jìn)行修復(fù)
3.用diff -u來(lái)看下兩個(gè)文件的差異,確認(rèn)問題點(diǎn)
4.重啟redis,加載修復(fù)后的AOF文件
【聊聊redis持久化 – AOF重寫】
AOF重寫的內(nèi)部運(yùn)行原理,我們有必要了解一下。
在重寫即將開始之際,redis會(huì)創(chuàng)建(fork)一個(gè)“重寫子進(jìn)程”,這個(gè)子進(jìn)程會(huì)首先讀取現(xiàn)有的AOF文件,并將其包含的指令進(jìn)行分析壓縮并寫入到一個(gè)臨時(shí)文件中。
與此同時(shí),主工作進(jìn)程會(huì)將新接收到的寫指令一邊累積到內(nèi)存緩沖區(qū)中,一邊繼續(xù)寫入到原有的AOF文件中,這樣做是保證原有的AOF文件的可用性,避免在重寫過(guò)程中出現(xiàn)意外。
當(dāng)“重寫子進(jìn)程”完成重寫工作后,它會(huì)給父進(jìn)程發(fā)一個(gè)信號(hào),父進(jìn)程收到信號(hào)后就會(huì)將內(nèi)存中緩存的寫指令追加到新AOF文件中。
當(dāng)追加結(jié)束后,redis就會(huì)用新AOF文件來(lái)代替舊AOF文件,之后再有新的寫指令,就都會(huì)追加到新的AOF文件中了。
【聊聊redis持久化 – 如何選擇RDB和AOF】
對(duì)于我們應(yīng)該選擇RDB還是AOF,官方的建議是兩個(gè)同時(shí)使用。這樣可以提供更可靠的持久化方案。
【聊聊主從 – 用法】
像MySQL一樣,redis是支持主從同步的,而且也支持一主多從以及多級(jí)從結(jié)構(gòu)。
主從結(jié)構(gòu),一是為了純粹的冗余備份,二是為了提升讀性能,比如很消耗性能的SORT就可以由從服務(wù)器來(lái)承擔(dān)。
redis的主從同步是異步進(jìn)行的,這意味著主從同步不會(huì)影響主邏輯,也不會(huì)降低redis的處理性能。
主從架構(gòu)中,可以考慮關(guān)閉主服務(wù)器的數(shù)據(jù)持久化功能,只讓從服務(wù)器進(jìn)行持久化,這樣可以提高主服務(wù)器的處理性能。
在主從架構(gòu)中,從服務(wù)器通常被設(shè)置為只讀模式,這樣可以避免從服務(wù)器的數(shù)據(jù)被誤修改。但是從服務(wù)器仍然可以接受CONFIG等指令,所以還是不應(yīng)該將從服務(wù)器直接暴露到不安全的網(wǎng)絡(luò)環(huán)境中。如果必須如此,那可以考慮給重要指令進(jìn)行重命名,來(lái)避免命令被外人誤執(zhí)行。
【聊聊主從 – 同步原理】
從服務(wù)器會(huì)向主服務(wù)器發(fā)出SYNC指令,當(dāng)主服務(wù)器接到此命令后,就會(huì)調(diào)用BGSAVE指令來(lái)創(chuàng)建一個(gè)子進(jìn)程專門進(jìn)行數(shù)據(jù)持久化工作,也就是將主服務(wù)器的數(shù)據(jù)寫入RDB文件中。在數(shù)據(jù)持久化期間,主服務(wù)器將執(zhí)行的寫指令都緩存在內(nèi)存中。
在BGSAVE指令執(zhí)行完成后,主服務(wù)器會(huì)將持久化好的RDB文件發(fā)送給從服務(wù)器,從服務(wù)器接到此文件后會(huì)將其存儲(chǔ)到磁盤上,然后再將其讀取到內(nèi)存中。這個(gè)動(dòng)作完成后,主服務(wù)器會(huì)將這段時(shí)間緩存的寫指令再以redis協(xié)議的格式發(fā)送給從服務(wù)器。
另外,要說(shuō)的一點(diǎn)是,即使有多個(gè)從服務(wù)器同時(shí)發(fā)來(lái)SYNC指令,主服務(wù)器也只會(huì)執(zhí)行一次BGSAVE,然后把持久化好的RDB文件發(fā)給多個(gè)下游。在redis2.8版本之前,如果從服務(wù)器與主服務(wù)器因某些原因斷開連接的話,都會(huì)進(jìn)行一次主從之間的全量的數(shù)據(jù)同步;而在2.8版本之后,redis支持了效率更高的增量同步策略,這大大降低了連接斷開的恢復(fù)成本。
主服務(wù)器會(huì)在內(nèi)存中維護(hù)一個(gè)緩沖區(qū),緩沖區(qū)中存儲(chǔ)著將要發(fā)給從服務(wù)器的內(nèi)容。從服務(wù)器在與主服務(wù)器出現(xiàn)網(wǎng)絡(luò)瞬斷之后,從服務(wù)器會(huì)嘗試再次與主服務(wù)器連接,一旦連接成功,從服務(wù)器就會(huì)把“希望同步的主服務(wù)器ID”和“希望請(qǐng)求的數(shù)據(jù)的偏移位置(replication offset)”發(fā)送出去。主服務(wù)器接收到這樣的同步請(qǐng)求后,首先會(huì)驗(yàn)證主服務(wù)器ID是否和自己的ID匹配,其次會(huì)檢查“請(qǐng)求的偏移位置”是否存在于自己的緩沖區(qū)中,如果兩者都滿足的話,主服務(wù)器就會(huì)向從服務(wù)器發(fā)送增量?jī)?nèi)容。
增量同步功能,需要服務(wù)器端支持全新的PSYNC指令。這個(gè)指令,只有在redis-2.8之后才具有。
【聊聊redis的事務(wù)處理】
眾所周知,事務(wù)是指“一個(gè)完整的動(dòng)作,要么全部執(zhí)行,要么什么也沒有做”。
在聊redis事務(wù)處理之前,要先和大家介紹四個(gè)redis指令,即MULTI、EXEC、DISCARD、WATCH。這四個(gè)指令構(gòu)成了redis事務(wù)處理的基礎(chǔ)。
1.MULTI用來(lái)組裝一個(gè)事務(wù);
2.EXEC用來(lái)執(zhí)行一個(gè)事務(wù);
3.DISCARD用來(lái)取消一個(gè)事務(wù);
4.WATCH用來(lái)監(jiān)視一些key,一旦這些key在事務(wù)執(zhí)行之前被改變,則取消事務(wù)的執(zhí)行。
常用命令
redis的常用命令主要分為兩個(gè)方面、一個(gè)是鍵值相關(guān)命令、一個(gè)是服務(wù)器相關(guān)命令
1、鍵值相關(guān)命令
??????keys * 取出當(dāng)前所有的key
??????exists name 查看n是否有name這個(gè)key
??????del name 刪除key name
????? expire confirm 100 設(shè)置confirm這個(gè)key100秒過(guò)期
??????ttl confirm 獲取confirm 這個(gè)key的有效時(shí)長(zhǎng)
????? select 0 選擇到0數(shù)據(jù)庫(kù) redis默認(rèn)的數(shù)據(jù)庫(kù)是0~15一共16個(gè)數(shù)據(jù)庫(kù)
??????move confirm 1 將當(dāng)前數(shù)據(jù)庫(kù)中的key移動(dòng)到其他的數(shù)據(jù)庫(kù)中,這里就是把confire這個(gè)key從當(dāng)前數(shù)據(jù)庫(kù)中移動(dòng)到1中
????? persist confirm 移除confirm這個(gè)key的過(guò)期時(shí)間
????? randomkey 隨機(jī)返回?cái)?shù)據(jù)庫(kù)里面的一個(gè)key
????? rename key2 key3 重命名key2 為key3
????? type key2 返回key的數(shù)據(jù)類型
2、服務(wù)器相關(guān)命令
????? ping PONG返回響應(yīng)是否連接成功
????? echo 在命令行打印一些內(nèi)容
????? select 0~15 編號(hào)的數(shù)據(jù)庫(kù)
??????quit? /exit 退出客戶端
????? dbsize 返回當(dāng)前數(shù)據(jù)庫(kù)中所有key的數(shù)量
????? info 返回redis的相關(guān)信息
????? config get dir/* 實(shí)時(shí)傳儲(chǔ)收到的請(qǐng)求
??????flushdb 刪除當(dāng)前選擇數(shù)據(jù)庫(kù)中的所有key
????? flushall 刪除所有數(shù)據(jù)庫(kù)中的數(shù)據(jù)庫(kù)
轉(zhuǎn)載于:https://www.cnblogs.com/canfengfeixue/p/8042913.html
總結(jié)
- 上一篇: 经济学家任泽平:不要神话雷军 对标乔布斯
- 下一篇: TSQLDBServerHttpApi使