redis（2）

Redis發佈和訂閱

Redis 發佈訂閱(pub/sub)是一種消息通訊模式：
發送者(pub)發送消息
訂閱者(sub)接收消息
Redis 客戶端能夠訂閱任意數量的頻道

subscribe c1 c2 c3  訂閱c1  c2  c3

publish c1 "hello redis"    向c1頻道發佈消息

psubscribe c*   "c*" #訂閱全部發送則是c開頭的消息

發送消息和上面的沒有區別

 

 

 

事務實例
Redis中事務的使用其實很是簡單，經過MULTI命令便可。

127.0.0.1:6379> multi
OK
 
在MULTI命令執行以後，咱們能夠繼續發送命令執行，但此時命令不會當即執行，而是保持到一個隊列中，以下

127.0.0.1:6379> set k1 bbb
QUEUED
127.0.0.1:6379> set k2 ccc
QUEUED
127.0.0.1:6379> set k3 ddd
QUEUED
127.0.0.1:6379> set k4 eee
QUEUED
127.0.0.1:6379> get k1
QUEUED
 
當全部的命令都輸入完成後，咱們能夠輸入EXEC命令來執行隊列中的命令，以下

127.0.0.1:6379> exec
1) OK
2) OK
3) OK
4) OK
5) "bbb"
 

 

Watch
watch命令能夠監控一個或多個鍵，一旦其中有一個鍵被修改（或刪除），以後的事務就不會執行。監控一直持續到exec命令（事務中的命令是在exec以後才執行的，因此在multi命令後能夠修改watch監控的鍵值）。假設咱們經過watch命令在事務執行以前監控了多個Keys，假若在watch以後有任何Key的值發生了變化，exec命令執行的事務都將被放棄，同時返回Null multi-bulk應答以通知調用者事務執行失敗。
 

exec後會自動執行unwatch命令，撤銷監控

UnWatch

撤銷對一個key的監控

 

 

Redis持久化
所謂的持久化就是保持咱們的數據不丟失，將數據一般保存在咱們的硬盤中。在Redis中持久化的方式有兩種，一種是快照持久化，一種是AOF持久化，各有各的優缺點，在項目中咱們得根據實際的狀況來選擇具體的持久化方式。本文主要介紹快照持久化，下篇文章介紹AOF持久化。

快照持久化
也叫RDB持久化方式。就是經過拍攝快照的方式來實現持久化，將某個時間的內存數據存儲在一個rdb文件中。在redis服務從新啓動的時候會加載rdb文件中的數據。
 

優缺點
優勢
RDB文件是一個很簡潔的單文件，它保存了某個時間點的Redis數據，很適合用於作備份。你能夠設定一個時間點對RDB文件進行歸檔，這樣就能在須要的時候很輕易的把數據恢復到不一樣的版本。
RDB很適合用於災備。單文件很方便就能傳輸到遠程的服務器上。
RDB的性能很好，須要進行持久化時，主進程會fork一個子進程出來，而後把持久化的工做交給子進程，本身不會有相關的I/O操做。
比起AOF，在數據量比較大的狀況下，RDB的啓動速度更快。

缺點
RDB容易形成數據的丟失。假設每5分鐘保存一次快照，若是Redis由於某些緣由不能正常工做，那麼從上次產生快照到Redis出現問題這段時間的數據就會丟失了。
RDB使用fork()產生子進程進行數據的持久化，若是數據比較大的話可能就會花費點時間，形成Redis中止服務幾毫秒。若是數據量很大且CPU性能不是很好的時候，中止服務的時間甚至會到1秒。

如何禁用快照持久化
1.在redis.conf配置文件中註釋掉全部的save配置
2.在最後一條save配置追加吃命令

save ""
 

 

AOF持久化
與快照持久化經過直接保存 Redis 的鍵值對數據不一樣，AOF 持久化是經過保存 Redis 執行的寫命令來記錄 Redis 的內存數據。理論上說，只要咱們保存了全部可能修改 Redis 內存數據的命令（也就是寫命令），那麼根據這些保存的寫命令，咱們能夠從新恢復 Redis 的內存狀態。AOF 持久化正是利用這個原理來實現數據的持久化與數據的恢復的
 

AOF優缺點
AOF 的優勢
AOF 持久化的方法提供了多種的同步頻率，即便使用默認的同步頻率每秒同步一次，Redis 最多也就丟失 1 秒的數據而已。
AOF 文件使用 Redis 命令追加的形式來構造，所以，即便 Redis 只能向 AOF 文件寫入命令的片段，使用 redis-check-aof 工具也很容易修正 AOF 文件。
AOF 文件的格式可讀性較強，這也爲使用者提供了更靈活的處理方式。例如，若是咱們不當心錯用了 FLUSHALL 命令，在重寫還沒進行時，咱們能夠手工將最後的 FLUSHALL 命令去掉，而後再使用 AOF 來恢復數據。

 

AOF 的缺點
對於具備相同數據的的 Redis，AOF 文件一般會比 RDF 文件體積更大。
雖然 AOF 提供了多種同步的頻率，默認狀況下，每秒同步一次的頻率也具備較高的性能。但在 Redis 的負載較高時，RDB 比 AOF 具好更好的性能保證。
RDB 使用快照的形式來持久化整個 Redis 數據，而 AOF 只是將每次執行的命令追加到 AOF 文件中，所以從理論上說，RDB 比 AOF 方式更健壯。官方文檔也指出，AOF 的確也存在一些 BUG，這些 BUG 在 RDB 沒有存在。

持久化的一些使用建議 1.若是redis僅僅是用來作爲緩存服務器的話，咱們能夠不使用任何的持久化。 2.通常狀況下咱們會將兩種持久化的方式都開啓。redis優先加載AOF文件來回複數據。RDB的好處是快速。 3.在主從節點中，RDB做爲咱們的備份數據，只在salve(從節點)上啓動，同步時間能夠設置的長一點，只留(save 900 1)這條規則就能夠了。 4.開啓AOF的狀況下，主從同步是時候必然會帶來IO的性能影響，此時咱們能夠調大auto-aof-rewrite-min-size的值，好比5GB。來減小IO的頻率 5.不開啓AOF的狀況下，能夠節省IO的性能影響，這是主從建經過RDB持久化同步，但若是主從都掛掉，影響較大