一、Redis發(fā)布訂閱
Redis 發(fā)布訂閱(pub/sub)是一種消息通信模式:發(fā)送者(pub)發(fā)送消息,訂閱者(sub)接收消息。
打開兩個(gè)窗口:session1 和 session2
在session1中訂閱消息:
subscribe xbqChannel 客戶端訂閱消息,xbqChannel 為相應(yīng)的頻道
在session2中發(fā)布消息:
publish xbqChannel testMessge 發(fā)布消息,同時(shí)訂閱該頻道的客戶端能收到該消息
二、Redis事務(wù)
和眾多其它數(shù)據(jù)庫一樣,Redis作為NoSQL數(shù)據(jù)庫也同樣提供了事務(wù)機(jī)制。在Redis中,MULTI/EXEC/DISCARD/WATCH這四個(gè)命令是我們實(shí)現(xiàn)事務(wù)的基石。
Redis 事務(wù)帶有以下重要的特征:
- 在事務(wù)中的所有命令都將會被串行化的順序執(zhí)行,事務(wù)執(zhí)行期間,Redis不會再為其它客戶端的請求提供任何服務(wù),從而保證了事物中的所有命令被原子的執(zhí)行。
- 和關(guān)系型數(shù)據(jù)庫中的事務(wù)相比,在Redis事務(wù)中如果有某一條命令執(zhí)行失敗,其后的命令仍然會被繼續(xù)執(zhí)行。
- 我們可以通過MULTI命令開啟一個(gè)事務(wù),有關(guān)系型數(shù)據(jù)庫開發(fā)經(jīng)驗(yàn)的人可以將其理解為"BEGIN TRANSACTION"語句。在該語句之后執(zhí)行的命令都將被視為事務(wù)之內(nèi)的操作,最后我們可以通過執(zhí)行EXEC/DISCARD命令來提交/回滾該事務(wù)內(nèi)的所有操作。這兩個(gè)Redis命令可被視為等同于關(guān)系型數(shù)據(jù)庫中的COMMIT/ROLLBACK語句。
- 在事務(wù)開啟之前,如果客戶端與服務(wù)器之間出現(xiàn)通訊故障并導(dǎo)致網(wǎng)絡(luò)斷開,其后所有待執(zhí)行的語句都將不會被服務(wù)器執(zhí)行。然而如果網(wǎng)絡(luò)中斷事件是發(fā)生在客戶端執(zhí)行EXEC命令之后,那么該事務(wù)中的所有命令都會被服務(wù)器執(zhí)行。
- 當(dāng)使用Append-Only模式時(shí),Redis會通過調(diào)用系統(tǒng)函數(shù)write將該事務(wù)內(nèi)的所有寫操作在本次調(diào)用中全部寫入磁盤。然而如果在寫入的過程中出現(xiàn)系統(tǒng)崩潰,如電源故障導(dǎo)致的宕機(jī),那么此時(shí)也許只有部分?jǐn)?shù)據(jù)被寫入到磁盤,而另外一部分?jǐn)?shù)據(jù)卻已經(jīng)丟失。Redis服務(wù)器會在重新啟動時(shí)執(zhí)行一系列必要的一致性檢測,一旦發(fā)現(xiàn)類似問題,就會立即退出并給出相應(yīng)的錯(cuò)誤提示。此時(shí),我們就要充分利用Redis工具包中提供的redis-check-aof工具,該工具可以幫助我們定位到數(shù)據(jù)不一致的錯(cuò)誤,并將已經(jīng)寫入的部分?jǐn)?shù)據(jù)進(jìn)行回滾。修復(fù)之后我們就可以再次重新啟動Redis服務(wù)器了。
一個(gè)事務(wù)從開始到執(zhí)行會經(jīng)歷以下三個(gè)階段:開始事務(wù)、命令入隊(duì)、執(zhí)行事務(wù)。
三、安全
1.查看redis的密碼:config get requirepass
2.為redis設(shè)置密碼的方法:
- 在redis.conf中進(jìn)行配置:requirepass xbqpass
- 通過命令行進(jìn)行設(shè)置:redis> config set requirepass xbqpass
3.當(dāng)對redis進(jìn)行操作時(shí),需要授權(quán): redis> auth xbqpass
四、持久化
1、RDB(Snapshotting快照持久化)
快照是默認(rèn)的持久化方式。這種方式是就是將內(nèi)存中數(shù)據(jù)以快照的方式寫入到二進(jìn)制文件中,默認(rèn)的文件名為dump.rdb??梢酝ㄟ^配置設(shè)置自動做快照持久化的方式。我們可以配置redis在n秒內(nèi)如果超過m個(gè)key被修改就自動做快照,下面是默認(rèn)的快照保存配置:
- save 900 1 #900秒內(nèi)如果超過1個(gè)key被修改,則發(fā)起快照保存
- save 300 10 #300秒內(nèi)容如超過10個(gè)key被修改,則發(fā)起快照保存
- save 60 10000 #在60秒(1分鐘)之后,如果至少有10000個(gè)key發(fā)生變化,則dump內(nèi)存快照
client 也可以使用save或者bgsave命令通知redis做一次快照持久化,每次快照持久化都是將內(nèi)存數(shù)據(jù)完整寫入到磁盤一次,并不是增量的只同步臟數(shù)據(jù)。如果數(shù)據(jù)量大的話,而且寫操作比較多,必然會引起大量的磁盤io操作,可能會嚴(yán)重影響性能。另外由于快照方式是在一定間隔時(shí)間做一次的,所以如果redis意外down掉的話,就會丟失最后一次快照后的所有修改。
2、AOF(Append-only)
redis會將每一個(gè)收到的寫命令都通過write函數(shù)追加到文件中(默認(rèn)是appendonly.aof)。當(dāng)redis重啟時(shí)會通過重新執(zhí)行文件中保存的寫命令來在內(nèi)存中重建整個(gè)數(shù)據(jù)庫的內(nèi)容。
- appendonly yes #啟用aof持久化方式
- # appendfsync always #每次收到寫命令就立即強(qiáng)制寫入磁盤,最慢的,但是保證完全的持久化,不推薦使用
- appendfsync everysec #每秒鐘強(qiáng)制寫入磁盤一次,在性能和持久化方面做了很好的折中,推薦
- # appendfsync no #完全依賴os,性能最好,持久化沒保證
3、RDB機(jī)制的優(yōu)勢和劣勢:
1.RDB優(yōu)勢:
- 一旦采用該方式,那么整個(gè)Redis數(shù)據(jù)庫將只包含一個(gè)文件,這對于文件備份而言是非常完美的。比如,你可能打算每個(gè)小時(shí)歸檔一次最近24小時(shí)的數(shù)據(jù),同時(shí)還要每天歸檔一次最近30天的數(shù)據(jù)。通過這樣的備份策略,一旦系統(tǒng)出現(xiàn)災(zāi)難性故障,我們可以非常容易的進(jìn)行恢復(fù)。
- 對于災(zāi)難恢復(fù)而言,RDB是非常不錯(cuò)的選擇。因?yàn)槲覀兛梢苑浅]p松的將一個(gè)單獨(dú)的文件壓縮后再轉(zhuǎn)移到其它存儲介質(zhì)上。
- 性能最大化。對于Redis的服務(wù)進(jìn)程而言,在開始持久化時(shí),它唯一需要做的只是fork出子進(jìn)程,之后再由子進(jìn)程完成這些持久化的工作,這樣就可以極大的避免服務(wù)進(jìn)程執(zhí)行IO操作了。
- 相比于AOF機(jī)制,如果數(shù)據(jù)集很大,RDB的啟動效率會更高。
2.RDB劣勢:
- 如果你想保證數(shù)據(jù)的高可用性,即最大限度的避免數(shù)據(jù)丟失,那么RDB將不是一個(gè)很好的選擇。因?yàn)橄到y(tǒng)一旦在定時(shí)持久化之前出現(xiàn)宕機(jī)現(xiàn)象,此前沒有來得及寫入磁盤的數(shù)據(jù)都將丟失。
- 由于RDB是通過fork子進(jìn)程來協(xié)助完成數(shù)據(jù)持久化工作的,因此,如果當(dāng)數(shù)據(jù)集較大時(shí),可能會導(dǎo)致整個(gè)服務(wù)器停止服務(wù)幾百毫秒,甚至是1秒鐘。
4、AOF機(jī)制的優(yōu)勢和劣勢:
1.AOF優(yōu)勢:
1). 該機(jī)制可以帶來更高的數(shù)據(jù)安全性,即數(shù)據(jù)持久性。Redis中提供了3中同步策略,即每秒同步、每修改同步和不同步。事實(shí)上,每秒同步也是異步完成的,其效率也是非常高的,所差的是一旦系統(tǒng)出現(xiàn)宕機(jī)現(xiàn)象,那么這一秒鐘之內(nèi)修改的數(shù)據(jù)將會丟失。而每修改同步,我們可以將其視為同步持久化,即每次發(fā)生的數(shù)據(jù)變化都會被立即記錄到磁盤中。可以預(yù)見,這種方式在效率上是最低的。
2). 由于該機(jī)制對日志文件的寫入操作采用的是append模式,因此在寫入過程中即使出現(xiàn)宕機(jī)現(xiàn)象,也不會破壞日志文件中已經(jīng)存在的內(nèi)容。然而如果我們本次操作只是寫入了一半數(shù)據(jù)就出現(xiàn)了系統(tǒng)崩潰問題,不用擔(dān)心,在Redis下一次啟動之前,我們可以通過redis-check-aof工具來幫助我們解決數(shù)據(jù)一致性的問題。
3). 如果日志過大,Redis可以自動啟用rewrite機(jī)制。即Redis以append模式不斷的將修改數(shù)據(jù)寫入到老的磁盤文件中,同時(shí)Redis還會創(chuàng)建一個(gè)新的文件用于記錄此期間有哪些修改命令被執(zhí)行。因此在進(jìn)行rewrite切換時(shí)可以更好的保證數(shù)據(jù)安全性。
4). AOF包含一個(gè)格式清晰、易于理解的日志文件用于記錄所有的修改操作。事實(shí)上,我們也可以通過該文件完成數(shù)據(jù)的重建。
2.AOF劣勢:
- 對于相同數(shù)量的數(shù)據(jù)集而言,AOF文件通常要大于RDB文件。 根據(jù)同步策略的不同,AOF在運(yùn)行效率上往往會慢于RDB??傊?,每秒同步策略的效率是比較高的,同步禁用策略的效率和RDB一樣高效。
3.如何修復(fù)壞損的AOF文件:
1). 將現(xiàn)有已經(jīng)壞損的AOF文件額外拷貝出來一份。 2). 執(zhí)行"redis-check-aof --fix "命令來修復(fù)壞損的AOF文件。 3). 用修復(fù)后的AOF文件重新啟動Redis服務(wù)器。
感謝你耐心看完了文章...