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,在訂閱者和發佈者之間起到了消息路由的功能。訂閱者可以通過subscribepsubscribe命令向redis server訂閱自己感興趣的消息類型,redis將消息類型稱爲通道(channel)。當發佈者通過publish命令向redis server發送特定類型的消息時。訂閱該消息類型的全部client都會收到此消息。這裏消息的傳遞是多對多的。一個client可以訂閱多個 channel,也可以向多個channel發送消息。

 

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

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章