上篇文章介紹了redis的基本情況和支持的數據類型，本篇文章將介紹redis持久化、主從複製、簡單的事務支持及發佈訂閱功能。
持久化
•redis是一個支持持久化的內存數據庫，也就是說redis需要經常將內存中的數據同步到磁盤來保證持久化，這是相對memcache來說的一個大的優勢。redis支持兩種持久化方式，一種是 Snapshotting（快照）也是默認方式，另一種是Append-only file（縮寫aof）的方式。
Snapshotting
快照是默認的持久化方式。這種方式將內存中數據以快照的方式寫入到二進制文件中,默認的文件名爲dump.rdb。可以配置自動做快照持久 化的方式。我們可以配置redis在n秒內如果超過m個key被修改就自動做快照，下面是默認的快照保存配置
save 900 1 #900秒內如果超過1個key被修改，則發起快照保存
save 300 10 #300秒內容如超過10個key被修改，則發起快照保存
save 60 10000
Append-only file
aof 比快照方式有更好的持久化性，是由於在使用aof持久化方式時,redis會將每一個收到的寫命令都通過write函數追加到文件中(默認是 appendonly.aof)。當redis重啓時會通過重新執行文件中保存的寫命令來在內存中重建整個數據庫的內容。當然由於os會在內核中緩存 write做的修改，所以可能不是立即寫到磁盤上。這樣aof方式的持久化也還是有可能會丟失部分修改。不過我們可以通過配置文件告訴redis我們想要 通過fsync函數強制os寫入到磁盤的時機。有三種方式如下（默認是：每秒fsync一次）
appendonly yes //啓用aof持久化方式
# appendfsync always //每次收到寫命令就立即強制寫入磁盤，最慢的，但是保證完全的持久化，不推薦使用
appendfsync everysec //每秒鐘強制寫入磁盤一次，在性能和持久化方面做了很好的折中，推薦
# appendfsync no //完全依賴os，性能最好,持久化沒保證
主從複製
•主從複製允許多個slave server擁有和master server相同的數據庫副本。下面是關於redis主從複製的一些特點
–1.master可以有多個slave
–2.除了多個slave連到相同的master外，slave也可以連接其他slave形成圖狀結構
–3.主從複製不會阻塞master。也就是說當一個或多個slave與master進行初次同步數據時，master可以繼續處理client發來的請求。相反slave在初次同步數據時則會阻塞，不能處理client的請求。
–4.主從複製可以用來提高系統的可伸縮性（我們可以用多個slave 專門用於client的讀請求，比如sort操作可以使用slave來處理），也可以用來做簡單的數據冗餘。
-5.可以在master禁用數據持久化，只需要註釋掉master 配置文件中的所有save配置，然後只在slave上配置數據持久化。
事物
•redis對事務的支持目前還比較簡單。redis只能保證一個client發起的事務中的命令可以連續的執行，而中間不會插入其他client的命令。
–Multi 事物開始
–Exec 執行事務
–Discard 放棄事物
–Watch 監聽key
–Unwatch 放棄所有key的監聽
•watch 命令會監視給定的key,當exec時候如果監視的key從調用watch後發生過變化，則整個事務會失敗。注意watch的key是對整個連接有效的，和事務一樣，如果連接斷開，監視和事務都會被自動清除。
發佈訂閱（pub/sub ）
•發佈訂閱(pub/sub)是一種消息通信模式。訂閱者可以通過subscribe和psubscribe命令向redis server訂閱自己感興趣的消息類型，redis將消息類型稱爲通道(channel)。當發佈者通過publish命令向redis server發送特定類型的消息時。訂閱該消息類型的全部client都會收到此消息。這裏消息的傳遞是多對多的。一個client可以訂閱多個 channel,也可以向多個channel發送消息。
–Subscribe
–Unsubscribe
–Psubscribe
–Punsubscribe
–Publish
管道（pipeline）
•redis是一個cs模式的tcp server，使用和http類似的請求響應協議。一個client可以通過一個socket連接發起多個請求命令。每個請求命令發出後client通常
會阻塞並等待redis服務處理，redis處理完後請求命令後會將結果通過響應報文返回給client。基本的通信過程如下
Client: INCR X
Server: 1
Client: INCR X
Server: 2
Client: INCR X
Server: 3
Client: INCR X
Server: 4
•基本上四個命令需要8個tcp報文才能完成。由於通信會有網絡延遲,假如從client和server之間的包傳輸時間需要0.125秒。那麼上面的四個命令8個報文至少會需要1秒才能完成。
利用pipeline的方式從client打包多條命令一起發出，不需要等待單條命令的響應返回，而redis服務端會處理完多條命令後會將多條命令的處理結果打包到一起返回給客戶端。通信過程如下
Client: INCR X
Client: INCR X
Client: INCR X
Client: INCR X
Server: 1
Server: 2
Server: 3
Server: 4
虛擬內存(VM)
VM的作者已經放棄該功能
•redis沒有使用os提供的虛擬內存機制而是自己實現了自己的虛擬內存機制
，但是思路和目的都是相同的。就是暫時把不經常訪問的數據從內存交換到磁盤中，從而騰出內存空間用於其他需要訪問的數據。尤其是對於redis這樣的內存數據庫，內存總是不夠用的。除了可以將數據分割到多個redis server外。另外的能夠提高數據庫容量的辦法就是使用vm把那些不經常訪問的數據交換的磁盤上。如果我們的存儲的數據總是有少部分數據被經常訪問，大
部分數據很少被訪問，對於網站來說確實總是隻有少量用戶經常活躍。當少量數據被經常訪問時，使用vm不但能提高單臺redis server數據庫的容量，而且也不會對性能造成太多影響。
–vm-enabled yes #開啓vm功能
–vm-swap-file /tmp/redis.swap
#交換的value保存的文件路徑/tmp/redis.swap
–vm-max-memory 1000000 #最大內存上限，超過後開始交換value到磁盤文件
–vm-page-size 32 #每個頁面的大小32個字節
–vm-pages 134217728 #最多使用在文件中使用多少頁面
vm-max-threads 4 #用於執行value對象換入換出的工作線程數量，0表示不使用工作線程
