redis入門筆記(2)

redis入門筆記(2)

上篇文章介紹了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表示不使用工做線程