前面已經(jīng)學(xué)習(xí)了redis的基本的命令行操作和數(shù)據(jù)類型，下面開始redis一些有趣的功能。

訂閱和發(fā)布機(jī)制

• 定義：發(fā)布者相當(dāng)于電臺(tái)，訂閱者相當(dāng)于客戶端，客戶端發(fā)到頻道的消息，將會(huì)被推送到所有訂閱此頻道的客戶端；客戶端不需要主動(dòng)去獲取消息，只需要訂閱頻道，這個(gè)頻道的內(nèi)容就會(huì)被推送過來；

• 作用:發(fā)布者和訂閱者的解耦合可以帶來更大的擴(kuò)展性和更加動(dòng)態(tài)的網(wǎng)絡(luò)拓?fù)?

相關(guān)命令

# 訂閱消息 subscribe 頻道1 頻道2 # 此時(shí)redis客戶端會(huì)一直處于監(jiān)聽頻道的狀態(tài)，一有消息就處理； # 取消訂閱 unsubcribe 頻道1 ... # 如果不寫頻道名稱，則取消所有的訂閱；# 推送消息 publish 頻道1 消息內(nèi)容

重點(diǎn)說明

• 發(fā)布訂閱機(jī)制一般使用在對(duì)同一個(gè)redis實(shí)例來說，實(shí)現(xiàn)類似于生產(chǎn)者消費(fèi)者模式；

• 在主從集群中，master發(fā)布的消息可以推送到slave中，但slave中的消息不能推送到master中；

訂閱發(fā)布機(jī)制的不足：

如果消息接收方不能及時(shí)處理推送的消息，消息會(huì)在緩存隊(duì)列中，會(huì)導(dǎo)致緩存占用的空間越來越大，最終導(dǎo)致redis崩潰；

發(fā)布的消息推送存在即時(shí)性,但網(wǎng)絡(luò)一般是不穩(wěn)定的，對(duì)于客戶端來說，如果出現(xiàn)了斷網(wǎng)的現(xiàn)象，那么接收的消息就會(huì)丟失，所以發(fā)布訂閱模式不能用在對(duì)數(shù)據(jù)完整性要求高的場(chǎng)合；

簡(jiǎn)單的主從復(fù)制配置

• 定義：一臺(tái)redis服務(wù)器可以作為一個(gè)master，在其下面可以有多個(gè)slave，每個(gè)slave又可以作為一個(gè)master，從而可以構(gòu)建龐大的redis數(shù)據(jù)庫集群；

配置方法

方式一：修改配置文件

# 設(shè)置主服務(wù)器的配置，綁定固定的ip sudo vi redis.conf bind 服務(wù)器的ip# 設(shè)置從服務(wù)器的ip sudo vi redis.conf bind 服務(wù)器的ip slaveof 主服務(wù)器的ip 主服務(wù)器redis端口 # 注意，ip與端口之間使用空格分割# 分別啟動(dòng)主從redis，主服務(wù)器redis負(fù)責(zé)寫，也可以讀；從服務(wù)器只能讀，不能寫；

方式二：使用命令行的方式動(dòng)態(tài)設(shè)置

# 從服務(wù)器連接主服務(wù)器 slaveof host port # 從服務(wù)器斷開主服務(wù)器 slaveof no one

重要說明

• 從服務(wù)器與主服務(wù)器進(jìn)行初始連接時(shí)，從服務(wù)器會(huì)丟棄所有的舊數(shù)據(jù)，然后載入主服務(wù)器的數(shù)據(jù)；

• redis不支持主主復(fù)制，也就是說不可以兩個(gè)redis相互設(shè)置對(duì)方為主服務(wù)器，雖然不會(huì)報(bào)錯(cuò)，但性能方面，以及對(duì)客戶端的請(qǐng)求都可能出現(xiàn)問題；

redis復(fù)制的啟動(dòng)過程

• 當(dāng)主服務(wù)器收到從服務(wù)器發(fā)送的復(fù)制請(qǐng)求的時(shí)候，主服務(wù)器執(zhí)行的動(dòng)作有：

等待從服務(wù)器的命令進(jìn)入-->執(zhí)行bgsave，創(chuàng)建快照文件；使用緩存區(qū)記錄bgsave命令執(zhí)行后所有的寫命令-->快照文件創(chuàng)建完畢后，向服務(wù)器發(fā)送快照文件-->發(fā)送快照文件完畢后向從服務(wù)器發(fā)送緩存區(qū)的寫命令-->完畢后每收到一個(gè)寫命令就向從服務(wù)器發(fā)送

• 從服務(wù)器相應(yīng)的動(dòng)作有：

連接主服務(wù)器,發(fā)送sync命令-->等待響應(yīng)-->丟棄所有的舊數(shù)據(jù)，載入主服務(wù)器的快照文件-->完成快照文件的解釋，開始接受命令請(qǐng)求-->執(zhí)行從主服務(wù)器發(fā)送的所有的寫命令；

注意：redis支持主從鏈，即從服務(wù)器還可以有從服務(wù)器，但是從服務(wù)器A復(fù)制從服務(wù)器B的過程和從服務(wù)器B復(fù)制主服務(wù)器是有區(qū)別的；從服務(wù)器B向從服務(wù)器A發(fā)送完畢快照文件后，會(huì)先斷開與從服務(wù)器A的連接，從服務(wù)器A需要重新連接并且請(qǐng)求同步；

redis的事務(wù)

• redis有像關(guān)系型數(shù)據(jù)庫一樣的事務(wù)機(jī)制來保證多條命令作為原子操作；事務(wù)中的命令要么全執(zhí)行，要么全不執(zhí)行；

• 事務(wù)的完整過程：開始事務(wù)-->命令進(jìn)入緩存-->執(zhí)行事務(wù);

事務(wù)的基本使用

# 開啟一個(gè)事務(wù) multi # 提交命令后，redis會(huì)將后面的操作保存起來 # 提交事務(wù) exec # 提交命令后，redis會(huì)執(zhí)行前面保存的所有的命令# 取消事務(wù) discard # 如果書寫命令隊(duì)列的過程中需要取消事務(wù)時(shí)使用

• redis事務(wù)中在寫命令隊(duì)列的時(shí)候，如果中間發(fā)生了語法錯(cuò)誤，并且redis報(bào)了錯(cuò)，那么這個(gè)事務(wù)所有的命令都會(huì)取消執(zhí)行；

> lpush list a b c (integer) 3 > multi OK > lpush list d QUEUED > lpuxh list f (error) ERR unknown command 'lpuxh' > lrange list 0 10 QUEUED > exec (error) EXECABORT Transaction discarded because of previous errors. > lrange list 0 10 1) "c" 2) "b" 3) "a"# 所有的命令都沒有執(zhí)行

• 但有一些錯(cuò)誤redis在執(zhí)行之前并不能感知，這時(shí)redis會(huì)執(zhí)行所有的的命令，客戶端必須自己處理錯(cuò)誤；

> lpush li blue red green (integer) 3 > multi OK > get li QUEUED > lpush li white QUEUED > exec 1) (error) WRONGTYPE Operation against a key holding the wrong kind of value 2) (integer) 4 > lrange li 0 10 1) "white" 2) "green" 3) "red" 4) "blue"# 所有的命令都執(zhí)行了，只不過有的命令執(zhí)行失敗

注意點(diǎn)

• redis的開啟事務(wù)是將命令暫時(shí)保存在一個(gè)隊(duì)列里，執(zhí)行時(shí)依次操作；如果命令隊(duì)列有一條出現(xiàn)語法錯(cuò)誤，整個(gè)事務(wù)創(chuàng)建會(huì)失敗；

• redis沒有提供事務(wù)的回滾功能，客戶端必須自己處理失敗的命令；

事務(wù)鎖

# 基本命令 watch key key .. # 監(jiān)控鍵值# 取消對(duì)所有鍵的監(jiān)控 unwatch

• 由于redis的事務(wù)中的命令其實(shí)是緩存隊(duì)列，并且redis可以防止在事務(wù)的執(zhí)行過程中有其他的命令插入，即具有隔離性；但是在多個(gè)客戶端進(jìn)行并發(fā)操作時(shí)存在數(shù)據(jù)無法同步的問題；如客戶端A、B同時(shí)操作鍵key的值加一，預(yù)期結(jié)果為增加2，實(shí)際可能只有1.

• 為了解決這個(gè)問題，redis引入了watch監(jiān)控鍵；

> watch num OK > set num 7 OK > multi OK > set num 5 QUEUED > exec (nil) > get num "7"

• 可以看到事務(wù)并沒有執(zhí)行成功，wetch可以監(jiān)控鍵，如果在監(jiān)控后，鍵的值發(fā)生了改變，那么redis后面與這個(gè)鍵相關(guān)的事務(wù)操作將會(huì)失敗，同時(shí)在exec執(zhí)行后，鍵的監(jiān)控會(huì)被取消；

注意：無論監(jiān)控多少個(gè)鍵或事務(wù)中有沒有與該鍵相關(guān)的命令，在最近的一個(gè)執(zhí)行了exec，無論事務(wù)執(zhí)行有沒有成功，watch監(jiān)控的所有鍵都將會(huì)取消，后面的事務(wù)不再受影響。

說明：使用watch監(jiān)控實(shí)現(xiàn)并發(fā)修改鍵值，如果事務(wù)被取消，需要手動(dòng)重新執(zhí)行事務(wù)；

問題

• 以上可知，redis實(shí)現(xiàn)的是類似樂觀鎖（即預(yù)期并發(fā)時(shí)沒有出現(xiàn)競(jìng)爭(zhēng)修改同一個(gè)鍵值的狀況)，這種情況在并發(fā)量低時(shí)影響不大，但是高并發(fā)時(shí)幾乎肯定出現(xiàn)競(jìng)爭(zhēng)，并發(fā)修改鍵值程序重試的次數(shù)越來越多，資源被白白浪費(fèi)，需要使用其他的方法實(shí)現(xiàn)悲觀鎖機(jī)制，這點(diǎn)后面會(huì)繼續(xù)研究；

• 作者：天宇之游
• 出處：http://www.cnblogs.com/cwp-bg/
• 本文版權(quán)歸作者和博客園共有，歡迎轉(zhuǎn)載、交流，但未經(jīng)作者同意必須保留此段聲明，且在文章明顯位置給出原文鏈接。

轉(zhuǎn)載于:https://www.cnblogs.com/cwp-bg/p/8137273.html

總結(jié)

以上是生活随笔為你收集整理的redis基础之订阅发布、主从复制和事务(四)的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。