一、Redis發(fā)布訂閱

Redis 發(fā)布訂閱(pub/sub)是一種消息通信模式：發(fā)送者(pub)發(fā)送消息，訂閱者(sub)接收消息。

打開(kāi)兩個(gè)窗口：session1 和 session2

在session1中訂閱消息：

​ subscribe xbqChannel 客戶端訂閱消息，xbqChannel 為相應(yīng)的頻道

在session2中發(fā)布消息：

​ publish xbqChannel testMessge 發(fā)布消息，同時(shí)訂閱該頻道的客戶端能收到該消息

二、Redis事務(wù)

和眾多其它數(shù)據(jù)庫(kù)一樣，Redis作為NoSQL數(shù)據(jù)庫(kù)也同樣提供了事務(wù)機(jī)制。在Redis中，MULTI/EXEC/DISCARD/WATCH這四個(gè)命令是我們實(shí)現(xiàn)事務(wù)的基石。

Redis 事務(wù)帶有以下重要的特征：

• 在事務(wù)中的所有命令都將會(huì)被串行化的順序執(zhí)行，事務(wù)執(zhí)行期間，Redis不會(huì)再為其它客戶端的請(qǐng)求提供任何服務(wù)，從而保證了事物中的所有命令被原子的執(zhí)行。
• 和關(guān)系型數(shù)據(jù)庫(kù)中的事務(wù)相比，在Redis事務(wù)中如果有某一條命令執(zhí)行失敗，其后的命令仍然會(huì)被繼續(xù)執(zhí)行。
• 我們可以通過(guò)MULTI命令開(kāi)啟一個(gè)事務(wù)，有關(guān)系型數(shù)據(jù)庫(kù)開(kāi)發(fā)經(jīng)驗(yàn)的人可以將其理解為"BEGIN TRANSACTION"語(yǔ)句。在該語(yǔ)句之后執(zhí)行的命令都將被視為事務(wù)之內(nèi)的操作，最后我們可以通過(guò)執(zhí)行EXEC/DISCARD命令來(lái)提交/回滾該事務(wù)內(nèi)的所有操作。這兩個(gè)Redis命令可被視為等同于關(guān)系型數(shù)據(jù)庫(kù)中的COMMIT/ROLLBACK語(yǔ)句。
• 在事務(wù)開(kāi)啟之前，如果客戶端與服務(wù)器之間出現(xiàn)通訊故障并導(dǎo)致網(wǎng)絡(luò)斷開(kāi)，其后所有待執(zhí)行的語(yǔ)句都將不會(huì)被服務(wù)器執(zhí)行。然而如果網(wǎng)絡(luò)中斷事件是發(fā)生在客戶端執(zhí)行EXEC命令之后，那么該事務(wù)中的所有命令都會(huì)被服務(wù)器執(zhí)行。
• 當(dāng)使用Append-Only模式時(shí)，Redis會(huì)通過(guò)調(diào)用系統(tǒng)函數(shù)write將該事務(wù)內(nèi)的所有寫(xiě)操作在本次調(diào)用中全部寫(xiě)入磁盤(pán)。然而如果在寫(xiě)入的過(guò)程中出現(xiàn)系統(tǒng)崩潰，如電源故障導(dǎo)致的宕機(jī)，那么此時(shí)也許只有部分?jǐn)?shù)據(jù)被寫(xiě)入到磁盤(pán)，而另外一部分?jǐn)?shù)據(jù)卻已經(jīng)丟失。Redis服務(wù)器會(huì)在重新啟動(dòng)時(shí)執(zhí)行一系列必要的一致性檢測(cè)，一旦發(fā)現(xiàn)類似問(wèn)題，就會(huì)立即退出并給出相應(yīng)的錯(cuò)誤提示。此時(shí)，我們就要充分利用Redis工具包中提供的redis-check-aof工具，該工具可以幫助我們定位到數(shù)據(jù)不一致的錯(cuò)誤，并將已經(jīng)寫(xiě)入的部分?jǐn)?shù)據(jù)進(jìn)行回滾。修復(fù)之后我們就可以再次重新啟動(dòng)Redis服務(wù)器了。

一個(gè)事務(wù)從開(kāi)始到執(zhí)行會(huì)經(jīng)歷以下三個(gè)階段：開(kāi)始事務(wù)、命令入隊(duì)、執(zhí)行事務(wù)。

三、安全

1.查看redis的密碼：config get requirepass

2.為redis設(shè)置密碼的方法：

• 在redis.conf中進(jìn)行配置：requirepass xbqpass
• 通過(guò)命令行進(jìn)行設(shè)置：redis> config set requirepass xbqpass

3.當(dāng)對(duì)redis進(jìn)行操作時(shí)，需要授權(quán)： redis> auth xbqpass

四、持久化

1、RDB（Snapshotting快照持久化）

快照是默認(rèn)的持久化方式。這種方式是就是將內(nèi)存中數(shù)據(jù)以快照的方式寫(xiě)入到二進(jìn)制文件中,默認(rèn)的文件名為dump.rdb?？梢酝ㄟ^(guò)配置設(shè)置自動(dòng)做快照持久化的方式。我們可以配置redis在n秒內(nèi)如果超過(guò)m個(gè)key被修改就自動(dòng)做快照，下面是默認(rèn)的快照保存配置：

1. save 900 1 #900秒內(nèi)如果超過(guò)1個(gè)key被修改，則發(fā)起快照保存
2. save 300 10 #300秒內(nèi)容如超過(guò)10個(gè)key被修改，則發(fā)起快照保存
3. save 60 10000 #在60秒(1分鐘)之后，如果至少有10000個(gè)key發(fā)生變化，則dump內(nèi)存快照

client 也可以使用save或者bgsave命令通知redis做一次快照持久化，每次快照持久化都是將內(nèi)存數(shù)據(jù)完整寫(xiě)入到磁盤(pán)一次，并不是增量的只同步臟數(shù)據(jù)。如果數(shù)據(jù)量大的話，而且寫(xiě)操作比較多，必然會(huì)引起大量的磁盤(pán)io操作，可能會(huì)嚴(yán)重影響性能。另外由于快照方式是在一定間隔時(shí)間做一次的，所以如果redis意外down掉的話，就會(huì)丟失最后一次快照后的所有修改。

2、AOF（Append-only）

redis會(huì)將每一個(gè)收到的寫(xiě)命令都通過(guò)write函數(shù)追加到文件中(默認(rèn)是appendonly.aof)。當(dāng)redis重啟時(shí)會(huì)通過(guò)重新執(zhí)行文件中保存的寫(xiě)命令來(lái)在內(nèi)存中重建整個(gè)數(shù)據(jù)庫(kù)的內(nèi)容。

1. appendonly yes #啟用aof持久化方式
2. # appendfsync always #每次收到寫(xiě)命令就立即強(qiáng)制寫(xiě)入磁盤(pán)，最慢的，但是保證完全的持久化，不推薦使用
3. appendfsync everysec #每秒鐘強(qiáng)制寫(xiě)入磁盤(pán)一次，在性能和持久化方面做了很好的折中，推薦
4. # appendfsync no #完全依賴os，性能最好,持久化沒(méi)保證

3、RDB機(jī)制的優(yōu)勢(shì)和劣勢(shì)：

1.RDB優(yōu)勢(shì):

• 一旦采用該方式，那么整個(gè)Redis數(shù)據(jù)庫(kù)將只包含一個(gè)文件，這對(duì)于文件備份而言是非常完美的。比如，你可能打算每個(gè)小時(shí)歸檔一次最近24小時(shí)的數(shù)據(jù)，同時(shí)還要每天歸檔一次最近30天的數(shù)據(jù)。通過(guò)這樣的備份策略，一旦系統(tǒng)出現(xiàn)災(zāi)難性故障，我們可以非常容易的進(jìn)行恢復(fù)。
• 對(duì)于災(zāi)難恢復(fù)而言，RDB是非常不錯(cuò)的選擇。因?yàn)槲覀兛梢苑浅］p松的將一個(gè)單獨(dú)的文件壓縮后再轉(zhuǎn)移到其它存儲(chǔ)介質(zhì)上。
• 性能最大化。對(duì)于Redis的服務(wù)進(jìn)程而言，在開(kāi)始持久化時(shí)，它唯一需要做的只是fork出子進(jìn)程，之后再由子進(jìn)程完成這些持久化的工作，這樣就可以極大的避免服務(wù)進(jìn)程執(zhí)行IO操作了。
• 相比于AOF機(jī)制，如果數(shù)據(jù)集很大，RDB的啟動(dòng)效率會(huì)更高。

2.RDB劣勢(shì)：

• 如果你想保證數(shù)據(jù)的高可用性，即最大限度的避免數(shù)據(jù)丟失，那么RDB將不是一個(gè)很好的選擇。因?yàn)橄到y(tǒng)一旦在定時(shí)持久化之前出現(xiàn)宕機(jī)現(xiàn)象，此前沒(méi)有來(lái)得及寫(xiě)入磁盤(pán)的數(shù)據(jù)都將丟失。
• 由于RDB是通過(guò)fork子進(jìn)程來(lái)協(xié)助完成數(shù)據(jù)持久化工作的，因此，如果當(dāng)數(shù)據(jù)集較大時(shí)，可能會(huì)導(dǎo)致整個(gè)服務(wù)器停止服務(wù)幾百毫秒，甚至是1秒鐘。

4、AOF機(jī)制的優(yōu)勢(shì)和劣勢(shì)：

1.AOF優(yōu)勢(shì)：

1). 該機(jī)制可以帶來(lái)更高的數(shù)據(jù)安全性，即數(shù)據(jù)持久性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步。事實(shí)上，每秒同步也是異步完成的，其效率也是非常高的，所差的是一旦系統(tǒng)出現(xiàn)宕機(jī)現(xiàn)象，那么這一秒鐘之內(nèi)修改的數(shù)據(jù)將會(huì)丟失。而每修改同步，我們可以將其視為同步持久化，即每次發(fā)生的數(shù)據(jù)變化都會(huì)被立即記錄到磁盤(pán)中?？梢灶A(yù)見(jiàn)，這種方式在效率上是最低的。

2). 由于該機(jī)制對(duì)日志文件的寫(xiě)入操作采用的是append模式，因此在寫(xiě)入過(guò)程中即使出現(xiàn)宕機(jī)現(xiàn)象，也不會(huì)破壞日志文件中已經(jīng)存在的內(nèi)容。然而如果我們本次操作只是寫(xiě)入了一半數(shù)據(jù)就出現(xiàn)了系統(tǒng)崩潰問(wèn)題，不用擔(dān)心，在Redis下一次啟動(dòng)之前，我們可以通過(guò)redis-check-aof工具來(lái)幫助我們解決數(shù)據(jù)一致性的問(wèn)題。

3). 如果日志過(guò)大，Redis可以自動(dòng)啟用rewrite機(jī)制。即Redis以append模式不斷的將修改數(shù)據(jù)寫(xiě)入到老的磁盤(pán)文件中，同時(shí)Redis還會(huì)創(chuàng)建一個(gè)新的文件用于記錄此期間有哪些修改命令被執(zhí)行。因此在進(jìn)行rewrite切換時(shí)可以更好的保證數(shù)據(jù)安全性。

4). AOF包含一個(gè)格式清晰、易于理解的日志文件用于記錄所有的修改操作。事實(shí)上，我們也可以通過(guò)該文件完成數(shù)據(jù)的重建。

2.AOF劣勢(shì)：

• 對(duì)于相同數(shù)量的數(shù)據(jù)集而言，AOF文件通常要大于RDB文件。 根據(jù)同步策略的不同，AOF在運(yùn)行效率上往往會(huì)慢于RDB。總之，每秒同步策略的效率是比較高的，同步禁用策略的效率和RDB一樣高效。

3.如何修復(fù)壞損的AOF文件：

1). 將現(xiàn)有已經(jīng)壞損的AOF文件額外拷貝出來(lái)一份。 2). 執(zhí)行"redis-check-aof --fix "命令來(lái)修復(fù)壞損的AOF文件。 3). 用修復(fù)后的AOF文件重新啟動(dòng)Redis服務(wù)器。

感謝你耐心看完了文章...