Memcached與Redis(二)

2.2 Redis的經常使用數據類型

與Memcached僅支持簡單的key-value結構的數據記錄不一樣，Redis支持的數據類型要豐富得多。最爲經常使用的數據類型主要由五種：String、Hash、List、Set和Sorted Set。在具體描述這幾種數據類型以前，咱們先經過一張圖來了解下Redis內部內存管理中是如何描述這些不一樣數據類型的。

                        圖1 Redis對象

Redis內部使用一個redisObject對象來表示全部的key和value。redisObject最主要的信息如圖1所示：type表明一個value對象具體是何種數據類型，encoding是不一樣數據類型在redis內部的存儲方式，好比：type=string表明value存儲的是一個普通字符串，那麼對應的encoding能夠是raw或者是int，若是是int則表明實際redis內部是按數值型類存儲和表示這個字符串的，固然前提是這個字符串自己能夠用數值表示，好比:"123" "456"這樣的字符串。這裏須要特殊說明一下vm字段，只有打開了Redis的虛擬內存功能，此字段纔會真正的分配內存，該功能默認是關閉狀態的。經過Figure1咱們能夠發現Redis使用redisObject來表示全部的key/value數據是比較浪費內存的，固然這些內存管理成本的付出主要也是爲了給Redis不一樣數據類型提供一個統一的管理接口，實際做者也提供了多種方法幫助咱們儘可能節省內存使用。下面咱們先來逐一的分析下這五種數據類型的使用和內部實現方式。

1）String

經常使用命令：set/get/decr/incr/mget等；

應用場景：String是最經常使用的一種數據類型，普通的key/value存儲均可以歸爲此類；

實現方式：String在redis內部存儲默認就是一個字符串，被redisObject所引用，當遇到incr、decr等操做時會轉成數值型進行計算，此時redisObject的encoding字段爲int。

2）Hash

經常使用命令：hget/hset/hgetall等

應用場景：咱們要存儲一個用戶信息對象數據，其中包括用戶ID、用戶姓名、年齡和生日，經過用戶ID咱們但願獲取該用戶的姓名或者年齡或者生日；

實現方式：Redis的Hash實際是內部存儲的Value爲一個HashMap，並提供了直接存取這個Map成員的接口。如圖2所示，Key是用戶ID, value是一個Map。這個Map的key是成員的屬性名，value是屬性值。這樣對數據的修改和存取均可以直接經過其內部Map的Key(Redis裏稱內部Map的key爲field), 也就是經過 key(用戶ID) + field(屬性標籤) 就能夠操做對應屬性數據。當前HashMap的實現有兩種方式：當HashMap的成員比較少時Redis爲了節省內存會採用相似一維數組的方式來緊湊存儲，而不會採用真正的HashMap結構，這時對應的value的redisObject的encoding爲zipmap，當成員數量增大時會自動轉成真正的HashMap,此時encoding爲ht。

圖2 Redis的Hash數據類型

3）List

經常使用命令：lpush/rpush/lpop/rpop/lrange等；

應用場景：Redis list的應用場景很是多，也是Redis最重要的數據結構之一，好比twitter的關注列表，粉絲列表等均可以用Redis的list結構來實現；

實現方式：Redis list的實現爲一個雙向鏈表，便可以支持反向查找和遍歷，更方便操做，不過帶來了部分額外的內存開銷，Redis內部的不少實現，包括髮送緩衝隊列等也都是用的這個數據結構。

4）Set

經常使用命令：sadd/spop/smembers/sunion等；

應用場景：Redis set對外提供的功能與list相似是一個列表的功能，特殊之處在於set是能夠自動排重的，當你須要存儲一個列表數據，又不但願出現重複數據時，set是一個很好的選擇，而且set提供了判斷某個成員是否在一個set集合內的重要接口，這個也是list所不能提供的；

實現方式：set 的內部實現是一個 value永遠爲null的HashMap，實際就是經過計算hash的方式來快速排重的，這也是set能提供判斷一個成員是否在集合內的緣由。

5）Sorted Set

經常使用命令：zadd/zrange/zrem/zcard等；

應用場景：Redis sorted set的使用場景與set相似，區別是set不是自動有序的，而sorted set能夠經過用戶額外提供一個優先級(score)的參數來爲成員排序，而且是插入有序的，即自動排序。當你須要一個有序的而且不重複的集合列表，那麼能夠選擇sorted set數據結構，好比twitter 的public timeline能夠以發表時間做爲score來存儲，這樣獲取時就是自動按時間排好序的。

實現方式：Redis sorted set的內部使用HashMap和跳躍表(SkipList)來保證數據的存儲和有序，HashMap裏放的是成員到score的映射，而跳躍表裏存放的是全部的成員，排序依據是HashMap裏存的score,使用跳躍表的結構能夠得到比較高的查找效率，而且在實現上比較簡單。

2.3 Redis的持久化

Redis雖然是基於內存的存儲系統，可是它自己是支持內存數據的持久化的，並且提供兩種主要的持久化策略：RDB快照和AOF日誌。咱們會在下文分別介紹這兩種不一樣的持久化策略。

2.3.1 Redis的RDB快照

Redis支持將當前數據的快照存成一個數據文件的持久化機制，即RDB快照。這種方法是很是好理解的，可是一個持續寫入的數據庫如何生成快照呢？Redis藉助了fork命令的copy on write機制。在生成快照時，將當前進程fork出一個子進程，而後在子進程中循環全部的數據，將數據寫成爲RDB文件。

咱們能夠經過Redis的save指令來配置RDB快照生成的時機，好比你能夠配置當10分鐘之內有100次寫入就生成快照，也能夠配置當1小時內有1000次寫入就生成快照，也能夠多個規則一塊兒實施。這些規則的定義就在Redis的配置文件中，你也能夠經過Redis的CONFIG SET命令在Redis運行時設置規則，不須要重啓Redis。

Redis的RDB文件不會壞掉，由於其寫操做是在一個新進程中進行的，當生成一個新的RDB文件時，Redis生成的子進程會先將數據寫到一個臨時文件中，而後經過原子性rename系統調用將臨時文件重命名爲RDB文件，這樣在任什麼時候候出現故障，Redis的RDB文件都老是可用的。同時，Redis的RDB文件也是Redis主從同步內部實現中的一環。

可是，咱們能夠很明顯的看到，RDB有他的不足，就是一旦數據庫出現問題，那麼咱們的RDB文件中保存的數據並非全新的，從上次RDB文件生成到Redis停機這段時間的數據所有丟掉了。在某些業務下，這是能夠忍受的，咱們也推薦這些業務使用RDB的方式進行持久化，由於開啓RDB的代價並不高。可是對於另一些對數據安全性要求極高的應用，沒法容忍數據丟失的應用，RDB就無能爲力了，因此Redis引入了另外一個重要的持久化機制：AOF日誌。

2.3.2 Redis的AOF日誌

AOF日誌的全稱是append only file，從名字上咱們就能看出來，它是一個追加寫入的日誌文件。與通常數據庫的binlog不一樣的是，AOF文件是可識別的純文本，它的內容就是一個個的Redis標準命令。固然，並非發送發Redis的全部命令都要記錄到AOF日誌裏面，只有那些會致使數據發生修改的命令纔會追加到AOF文件。那麼每一條修改數據的命令都生成一條日誌，那麼AOF文件是否是會很大？答案是確定的，AOF文件會愈來愈大，因此Redis又提供了一個功能，叫作AOF rewrite。其功能就是從新生成一份AOF文件，新的AOF文件中一條記錄的操做只會有一次，而不像一份老文件那樣，可能記錄了對同一個值的屢次操做。其生成過程和RDB相似，也是fork一個進程，直接遍歷數據，寫入新的AOF臨時文件。在寫入新文件的過程當中，全部的寫操做日誌仍是會寫到原來老的AOF文件中，同時還會記錄在內存緩衝區中。當重完操做完成後，會將全部緩衝區中的日誌一次性寫入到臨時文件中。而後調用原子性的rename命令用新的AOF文件取代老的AOF文件。

AOF是一個寫文件操做，其目的是將操做日誌寫到磁盤上，因此它也一樣會遇到咱們上面說的寫操做的5個流程。那麼寫AOF的操做安全性又有多高呢。實際上這是能夠設置的，在Redis中對AOF調用write(2)寫入後，什麼時候再調用fsync將其寫到磁盤上，經過appendfsync選項來控制，下面appendfsync的三個設置項，安全強度逐漸變強。

1）appendfsync no

當設置appendfsync爲no的時候，Redis不會主動調用fsync去將AOF日誌內容同步到磁盤，因此這一切就徹底依賴於操做系統的調試了。對大多數Linux操做系統，是每30秒進行一次fsync，將緩衝區中的數據寫到磁盤上。

2）appendfsync everysec

當設置appendfsync爲everysec的時候，Redis會默認每隔一秒進行一次fsync調用，將緩衝區中的數據寫到磁盤。可是當這一次的fsync調用時長超過1秒時。Redis會採起延遲fsync的策略，再等一秒鐘。也就是在兩秒後再進行fsync，這一次的fsync就無論會執行多長時間都會進行。這時候因爲在fsync時文件描述符會被阻塞，因此當前的寫操做就會阻塞。因此結論就是，在絕大多數狀況下，Redis會每隔一秒進行一次fsync。在最壞的狀況下，兩秒鐘會進行一次fsync操做。這一操做在大多數數據庫系統中被稱爲group commit，就是組合屢次寫操做的數據，一次性將日誌寫到磁盤。

3）appednfsync always

當設置appendfsync爲always時，每一次寫操做都會調用一次fsync，這時數據是最安全的，固然，因爲每次都會執行fsync，因此其性能也會受到影響。