推薦（免費）：redis教學
文章目錄
AOF持久化
一、Redis發布訂閱介紹
Redis 發布訂閱(pub/sub)是一種訊息通訊模式：發送者(pub)發送訊息，訂閱者(sub)接收訊息。 Redis 用戶端可以訂閱任意數量的頻道。
③微信公眾號模式
。
二、Redis發布訂閱演示
發布訂閱語法# 訂閱頻道：
#subscribe channel1 [channel2 ...] 訂閱給定的一個或多個頻道的資訊
發佈頻道：
publish channel message
取消訂閱頻道：
#unsubscribe channel1 [ channel2 ...] 指退訂給定的頻道。 
退訂所有給定模式的頻道。
三、Redis中的交易
轉帳
Redis會將一個交易中的所有指令序列化，然後按順序執行(任意指令執行失敗，其餘的指令依然被執行)執行中不會被其它指令插入，不准出現加賽行為。
一個交易從開始到執行會經歷以下三個階段：開始事務、命令入隊、執行事務。
事務相關指令:
multi 標記一個交易區塊的開始。
exec 執行所有交易區塊內的指令。
discard 取消事務，放棄執行事務區塊內的所有指令。
監視一個(或多個)key，如果在事務執行之前這個(或這些)key被其他命令所改動，那麼事務將被打斷。 unwatch
取消watch指令對所有key的監視。四、轉帳功能-Redis交易示範轉帳前A有80元，B有10元。
- #需求：轉帳功能，A向B帳號轉帳50元。
轉帳後A有30元，B有60元。
執行exec前，如果發現新增的指令有問題，可以使用discard指令放棄佇列運行，類似MySQL中的回溯操作。
五、轉帳功能升級版-watch#############需求：某一帳戶在一事務內進行操作，在提交交易前，另一個進程對該帳戶進行操作。 ###
上文中的轉帳是不安全的，在執行中如果有其他命令對帳戶a或b的操作，可能會出現幻讀；解決辦法是添加watch命令，可以對帳戶進行watch監視，一旦在事務執行中，出現了其他指令對帳戶a或b操作，程式直接報錯回滾。
執行了watch指令後，如果exec或discard指令先被執行，就不需要再執行 unwatch來取消對key的監視了，因為exec或discard指令會自動取消監視。
六、交易的錯誤處理
業務邏輯錯誤
發生業務邏輯錯誤：只有報錯的指令不會被執行，而其它的指令都會執行，不會回滾。 
語法錯誤
#發生語法錯誤：執行時整個的所有佇列都會被取消。 
七、Redis持久化
資料存放在記憶體：高效率、但斷電記憶體資料會遺失。
資料存放在硬碟：讀寫速度慢於記憶體、但斷電資料不會遺失。
RDB持久化
RDB是redis的預設持久化機制。 RDB相當於照快照，保存的是資料的一種狀態。 (幾十G的資料可以儲存為幾KB的快照)
快照是預設的持久化方式。這種方式是就是將記憶體中資料以快照的方式寫入到二進位檔案中，預設的檔案名稱為dump.rdb(存在redis.conf檔案中)。
優點：
缺點：
AOF持久化
由於快照方式是在一定間隔時間做一次的，所以如果redis 意外宕機，就會失去最後一次快照後的所有修改。如果應用程式要求不能遺失任何修改的話，可以採用AOF(Append-Only File)持久化方式。
appendonly yes 指令可以啟用 AOF 持久化方式。
有三種方式如下（預設是：每秒fsync 一次）
appendfsync always 收到寫入指令就立即寫入磁碟，最慢，但是保證完全的持久化appendfsync everysec 每秒鐘寫入磁碟一次，在效能和持久化方面做了很好的折中appendfsync no 完全依賴OS，性能最好，但持久化沒保證優點：
AOF比快照方式有更好的持久化性，是由於在使用AOF持久化方式時：redis 會將每一個收到的寫入命令都透過write 函數追加到檔案中(預設是appendonly.aof)。當redis 重新啟動時會透過重新執行檔案中儲存的寫入指令來在記憶體中重建整個資料庫的內容。
缺點：
AOF的方式也同時帶來了另一個問題。持久化檔案會變的越來越大，佔硬碟 。例如我們呼叫 incr test指令 100 次，檔案中必須保存全部的 100 個指令，其實有 99 個都是多餘的。
以上是講解Redis發布訂閱演示、事務演示、持久化的詳細內容。更多資訊請關注PHP中文網其他相關文章！
