Redis的進階特性

基礎的使用方式随便在網上都能搜到，是以就不談論這一塊了。

主要想分享一下進階特性，如果不對請指正。

一、資料失效方式：因為redis是基于記憶體的，而由于記憶體的昂貴，注定它的大小是有限的，是以當資料量較大、記憶體被占滿的時候，再插入新資料，就要涉及到如何進行排程了。

排程方式主要分為四類：不删除、LRU（最近最久未使用）、随機删除、删除剩餘過期時間最短。再考慮到部分key存在過期的特性，是以分為一下具體6類：

•1、noeviction：達到記憶體限額後傳回錯誤,不删除已有内容。

•2、allkeys-lru：使用LRU算法(針對所有資料)

•3、volatile-lru：使用LRU算法(針對設定有過期時間的資料)

•4、allkeys-random:随機删除(針對所有資料)

•5、volatile-random:随機删除(針對設定有過期時間的資料)

•6、volatile-ttl:對設定有過期時間的資料中，删除即将失效的。

二、事務：

1、redis是支援事務的，但是很重要的一點是：不支援復原機制。什麼意思呢？如果在事務中執行了10條指令，在第三條失敗後，後面的4-10依然會執行，并且1-2和4-10都是能夠生效的（在mysql等資料庫中，如果事務中出現錯誤，會整個復原到事務執行前的狀态）

2、watch指令：為了照顧事務中資料一緻性，redis也提供了watch樂觀鎖機制來保證資料一緻。具體的方式就是在事務中，對某些key執行watch指令，之後再填寫對應操作指令，如果在執行事務時發現被watch的key已經修改，那麼在watch之後的所有指令就失敗。通過這樣的方式在不支援復原的情況下，也保證了資料的一緻性。

三、資料持久化：redis中，持久化是作為備份的手段使用的，一般來說常用的方式有兩種：

(1)、snap shot（快照機制，也就是常說的rdb）：

首先執行save或bgsave指令，它們倆的差別是save會直接在主程序中執行備份(此時主程序阻塞，就相當于此時redis不能提供服務了)，bgsave會啟動一個子程序執行備份操作，而父程序繼續提供服務。

bgsave指令的執行過程：

•1.redis調用fork,現在有了子程序和父程序。

•2.父程序繼續處理client請求，子程序負責将記憶體内容寫入到臨時檔案。由于os的寫時複制機制（copyon write)父子程序會共享相同的實體頁面，當父程序處理寫請求時os會為父程序要修改的頁面建立副本，而不是寫共享的頁面。是以子程序的位址空間内的資料是fork時刻整個資料庫的一個快照。

•3.當子程序将快照寫入臨時檔案完畢後，用臨時檔案替換原來的快照檔案，然後子程序退出。

(2)、aof(append-only file)：

本質上就是一個記錄日志檔案的機制，

redis會将每一個收到的寫指令都通過write函數追加到檔案中(預設是 appendonly.aof)。當redis重新開機時會通過重新執行檔案中儲存的寫指令來在記憶體中重建整個資料庫的内容。

這樣做的好處是實時儲存的記憶體占用比快照小很多(使用快照儲存一次會占用目前記憶體雙倍的空間)

但aof檔案的追加寫方式會導緻磁盤增量占用，解決方式是重寫aof檔案，什麼意思呢？就是在特定的時間（可以自己規定和調用，一般是在aof檔案過大的時候）啟動子程序收集目前庫中資料并轉化為寫指令，把這些指令寫入臨時檔案中，完成之後再用臨時檔案替換老的aof檔案，這樣就達到了aof檔案的“瘦身”。（其實就有點類似于rdb中的bgsave，隻不過差別是aof存的是指令，而rdb存的是具體資料）

aof的執行方式有以下三種：

1、appendfsyncalways (每次收到一條指令就執行一次AOF，不推薦，太耗資源)

2、appendfsyncno (完全依賴OS排程，不推薦，不穩定)

3、appendfsync everysec  （每秒鐘強制寫入磁盤一次，資源和穩定性平衡，推薦使用）

四、主從複制：

主從複制方式主要用于容災、備份。（注意它不是分布式解決方案，它隻是遠端備份）。

配置方式如下：

•配置slave伺服器隻需要在slave的配置檔案中加入如下配置即可，剩下的redis會自動幫你處理。

•slaveof 192.168.1.1  6379  •#指定master的ip和端口

具體過程如下：

五、消息訂閱：

redis作為一個pub/sub server，在訂閱者和釋出者之間起到了消息路由的功能。訂閱者可以通過subscribe和psubscribe指令向redis server訂閱自己感興趣的消息類型，redis将消息類型稱為通道(channel)。當釋出者通過publish指令向redis server發送特定類型的消息時。訂閱該消息類型的全部client都會收到此消息。這裡消息的傳遞是多對多的。一個client可以訂閱多個 channel,也可以向多個channel發送消息。

允許轉載，但請注明出處：http://blog.csdn.net/lambert310/article/details/51513516