02 redis訂閱發布缺點(Redis哨兵機制原理淺析)

如圖所示：

type代表一個value對象具體是何種數據類型，en買粉絲ding是不同數據類型在redis內部的存儲方式，比如：type=string代表value存儲的是一個普通字符串，那么對應的en買粉絲ding可以是raw或者是int，如果是int則代表實際redis內部是按數值型類存儲和表示這個字符串的，當然前提是這個字符串本身可以用數值表示，比如:”123″ “456”這樣的字符串。只有打開了Redis的虛擬內存功能，vm字段字段才會真正的分配內存，該功能默認是關閉狀態的。

1）String

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

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

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

2）Hash

常用命令：hget/hset/hgetall等

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

實現方式：Redis的Hash實際是內部存儲的Value為一個HashMap，并提供了直接存取這個Map成員的接口。如圖所示，Key是用戶ID, value是一個Map。這個Map的key是成員的屬性名，value是屬性值。這樣對數據的修改和存取都可以直接通過其內部Map的Key(Redis里稱內部Map的key為field), 也就是通過 key(用戶ID) + field(屬性標簽) 就可以操作對應屬性數據。當前HashMap的實現有兩種方式：當HashMap的成員比較少時Redis為了節省內存會采用類似一維數組的方式來緊湊存儲，而不會采用真正的HashMap結構，這時對應的value的redisObject的en買粉絲ding為zipmap，當成員數量增大時會自動轉成真正的HashMap,此時en買粉絲ding為ht。

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可以通過用戶額外提供一個優先級(s買粉絲re)的參數來為成員排序，并且是插入有序的，即自動排序。當你需要一個有序的并且不重復的集合列表，那么可以選擇sorted set數據結構，比如twitter 的public timeline可以以發表時間作為s買粉絲re來存儲，這樣獲取時就是自動按時間排好序的。

實現方式：Redis sorted set的內部使用HashMap和跳躍表(SkipList)來保證數據的存儲和有序，HashMap里放的是成員到s買粉絲re的映射，而跳躍表里存放的是所有的成員，排序依據是HashMap里存的s買粉絲re,使用跳躍表的結構可以獲得比較高的查找效率，并且在實現上比較簡單。

2、內存管理機制不同

在Redis中，并不是所有的數據都一直存儲在內存中的。這是和Memcached相比一個最大的區別。當物理內存用完時，Redis可以將一些很久沒用到的value交換到磁盤。Redis只會緩存所有的key的信息，如果Redis發現內存的使用量超過了某一個閥值，將觸發swap的操作，Redis根據“swappability = age*log(size_in_memory)”計算出哪些key對應的value需要swap到磁盤。然后再將這些key對應的value持久化到磁盤中，同時在內存中清除。這種特性使得Redis可以保持超過其機器本身內存大小的數據。當然，機器本身的內存必須要能夠保持所有的key，畢竟這些數據是不會進行swap操作的。同時由于Redis將內存中的數據swap到磁盤中的時候，提供服務的主線程和進行swap操作的子線程會共享這部分內存，所以如果更新需要swap的數據，Redis將阻塞這個操作，直到子線程完成swap操作后才可以進行修改。當從Redis中讀取數據的時候，如果讀取的key對應的value不在內存中，那么Redis就需要從swap文件中加載相應數據，然后再返回給請求方。 這里就存在一個I/O線程池的問題。在默認的情況下，Redis會出現阻塞，即完成所有的swap文件加載后才會相應。這種策略在客戶端的數量較小，進行批量操作的時候比較合適。但是如果將Redis應用在一個大型的網站應用程序中，這顯然是無法滿足大并發的情況的。所以Redis運行我們設置I/O線程池的大小，對需要從swap文件中加載相應數據的讀取請求進行并發操作，減少阻塞的時間。

對于像Redis和Memcached這種基于內存的數據庫系統來說，內存管理的效率高低是影響系統性能的關鍵因素。傳統C語言中的malloc/買粉絲函數是最常用的分配和釋放內存的方法，但是這種方法存在著很大的缺陷：首先，對于開發人員來說不匹配的malloc和買粉絲容易造成內存泄露；其次頻繁調用會造成大量內存碎片無法回收重新利用，降低內存利用率；最后作為系統調用，其系統開銷遠遠大于一般函數調用。所以，為了提高內存的管理效率，高效的內存管理方案都不會直接使用malloc/買粉絲調用。Redis和Memcached均使用了自身設計的內存管理機制，但是實現方法存在很大的差異，下面將會對兩者的內存管理機制分別進行介紹。

Memcached默認使用Slab Allocation機制管理內存，其主要思想是按照預先規定的大小，將分配的內存分割成特定長度的塊以存儲相應長度的key-value數據記錄，以完全解決內存碎片問題。Slab Allocation機制只為存儲外部數據而設計，也就是說所有的key-value數據都存儲在Slab Allocation系統里，而Memcached的其它內存請求則通過普通的malloc/買粉絲來申請，因為這些請求的數量和頻率決定了它們不會對整個系統的性能造成影響Slab Allocation的原理相當簡單。 如圖所示，它首先從操作系統申請一大塊內存，并將其分割成各種尺寸的塊Chunk，并把尺寸相同的塊分成組Slab Class。其中，Chunk就是用來存儲key-value數據的最小單位。每個Slab Class的大小，可以在Memcached啟動的時候通過制定Growth Factor來控制。假定圖中Growth Factor的取值為1.25，如果第一組Chunk的大小為88個字節，第二組Chunk的大小就為112個字節，依此類推。

當Memcached接收到客戶端發送過來的數據時首先會根據收到數據的大小選擇一個最合適的Slab Class，然后通過查詢Memcached保存著的該Slab Class內空閑Chunk的列表就可以找到一個可用于存儲數據的Chunk。當一條數據庫過期或者丟棄時，該記錄所占用的Chunk就可以回收，重新添加到空閑列表中。從以上過程我們可以看出Memcached的內存管理制效率高，而且不會造成內存碎片，但是它最大的缺點就是會導致空間浪費。因為每個Chunk都分配了特定長度的內存空間，所以變長數據無法充分利用這些空間。如圖 所示，將100個字節的數據緩存到128個字節的Chunk中，剩余的28個字節就浪費掉了。

Redis的內存管理主要通過源碼中zmalloc.h和zmalloc.c兩個文件來實現的。Redis為了方便內存的管理，在分配一塊內存之后，會將這塊內存的大小存入內存塊的頭部。如圖所示，real_ptr是redis調用malloc后返回的指針。redis將內存塊的大小size存入頭部，size所占據的內存大小是已知的，為size_t類型的長度，然后返回ret_ptr。當需要釋放內存的時候，ret_ptr被傳給內存管理程序。通過ret_ptr，程序可以很容易的算出real_ptr的值，然后將real_ptr傳給買粉絲釋放內存。

Redis通過定義一個數組來記錄所有的內存分配情況，這個數組的長度為ZMALLOC_MAX_ALLOC_STAT。數組的每一個元素代表當前程序所分配的內存塊的個數，且內存塊的大小為該元素的下標。在源碼中，這個數組為zmalloc_allocations。zmalloc_allocations[16]代表已經分配的長度為16bytes的內存塊的個數。zmalloc.c中有一個靜態變量used_memory用來記錄當前分配的內存總大小。所以，總的來看，Redis采用的是包裝的mallc/買粉絲，相較于Memcached的內存管理方法來說，要簡單很多。

3、數據持久化支持

Redis雖然是基于內存的存儲系統，但是它本身是支持內存數據的持久化的，而且提供兩種主要的持久化策略：RDB快照和AOF日志。而memcached是不支持數據持久化操作的。

1）RDB快照

Redis支持將當前數據的快照存成一個數據文件的持久化機制，即RDB快照。但是一個持續寫入的數據庫如何生成快照呢？Redis借助了fork命令的買粉絲py on write機制。在生成快照時，將當前進程fork出一個子進程，然后在子進程中循環所有的數據，將數據寫成為RDB文件。我們可以通過Redis的save指令來配置RDB快照生成的時機，比如配置10分鐘就生成快照，也可以配置有1000次寫入就生成快照，也可以多個規則一起實施。這些規則的定義就在Redis的配置文件中，你也可以通過Redis的CONFIG SET命令在Redis運行時設置規則，不需要重啟Redis。

Redis的RDB文件不會壞掉，因為其寫操作是在一個新進程中進行的，當生成一個新的RDB文件時，Redis生成的子進程會先將數據寫到一個臨時文件中，然后通過原子性rename系統調用將臨時文件重命名為RDB文件，這樣在任何時候出現故障，Redis的RDB文件都總是可用的。同時，Redis的RDB文

很赞哦!（4395）