背景

業(yè)務(wù)場景中經(jīng)常會有各種大key多key的情況， 比如：

1：單個簡單的key存儲的value很大

2：hash， set，zset，list 中存儲過多的元素（以萬為單位）

3：一個集群存儲了上億的key，Key 本身過多也帶來了更多的空間占用

（如無意外，文章中所提及的hash，set等數(shù)據(jù)結(jié)構(gòu)均指redis中的數(shù)據(jù)結(jié)構(gòu)  ）

由于redis是單線程運行的，如果一次操作的value很大會對整個redis的響應(yīng)時間造成負面影響，所以，業(yè)務(wù)上能拆則拆，下面舉幾個典型的分拆方案。

1：單個簡單的key存儲的value很大

i：該對象需要每次都整存整取

可以嘗試將對象分拆成幾個key-value， 使用multiGet獲取值，這樣分拆的意義在于分拆單次操作的壓力，將操作壓力平攤到多個redis實例中，降低對單個redis的IO影響；

ii：該對象每次只需要存取部分數(shù)據(jù)

可以像第一種做法一樣，分拆成幾個key-value，  也可以將這個存儲在一個hash中，每個field代表一個具體的屬性，

使用hget,hmget來獲取部分的value，使用hset，hmset來更新部分屬性

2：value中存儲過多的元素

類似于場景一種的第一個做法，可以將這些元素分拆。

以hash為例，原先的正常存取流程是  hget(hashKey, field) ; hset(hashKey, field, value)

現(xiàn)在，固定一個桶的數(shù)量，比如 10000， 每次存取的時候，先在本地計算field的hash值，模除 10000， 確定了該field落在哪個key上。

newHashKey  =  hashKey + ( set, zset, list 也可以類似上述做法

但有些不適合的場景，比如，要保證 lpop 的數(shù)據(jù)的確是最早push到list中去的，這個就需要一些附加的屬性，或者是在 key的拼接上做一些工作（比如list按照時間來分拆）。

3：一個集群存儲了上億的key

如果key的個數(shù)過多會帶來更多的內(nèi)存空間占用，

i：key本身的占用（每個key 都會有一個Category前綴）

ii：集群模式中，服務(wù)端需要建立一些slot2key的映射關(guān)系，這其中的指針占用在key多的情況下也是浪費巨大空間

這兩個方面在key個數(shù)上億的時候消耗內(nèi)存十分明顯（Redis 3.2及以下版本均存在這個問題，4.0有優(yōu)化）；

所以減少key的個數(shù)可以減少內(nèi)存消耗，可以參考的方案是轉(zhuǎn)Hash結(jié)構(gòu)存儲，即原先是直接使用Redis String 的結(jié)構(gòu)存儲，現(xiàn)在將多個key存儲在一個Hash結(jié)構(gòu)中，具體場景參考如下：

一：key 本身就有很強的相關(guān)性，比如多個key 代表一個對象，每個key是對象的一個屬性，這種可直接按照特定對象的特征來設(shè)置一個新Key——Hash結(jié)構(gòu)， 原先的key則作為這個新Hash 的field。

舉例說明：

原先存儲的三個key

user.zhangsan-id = 123;

user.zhangsan-age = 18;

user.zhangsan-country = china;

這三個key本身就具有很強的相關(guān)特性，轉(zhuǎn)成Hash存儲就像這樣 key = user.zhangsan

field:id = 123;

field:age = 18;

field:country = china;

即redis中存儲的是一個key ：user.zhangsan， 他有三個 field， 每個field + key 就對應(yīng)原先的一個key。

二：key 本身沒有相關(guān)性，預(yù)估一下總量，采取和上述第二種場景類似的方案，預(yù)分一個固定的桶數(shù)量

比如現(xiàn)在預(yù)估key 的總數(shù)為 2億，按照一個hash存儲 100個field來算，需要 2億 / 100 = 200W 個桶 (200W 個key占用的空間很少，2億可能有將近 20G )

原先比如有三個key  ：

user.123456789

user.987654321

user.678912345

現(xiàn)在按照200W 固定桶分就是先計算出桶的序號 hash(123456789)  % 200W ， 這里最好保證這個 hash算法的值是個正數(shù)，否則需要調(diào)整下模除的規(guī)則；

這樣算出三個key 的桶分別是  1 ， 2， 2。所以存儲的時候調(diào)用API  hset(key,  field, value)，讀取的時候使用 hget （key， field）

圖片

注意兩個地方：1，hash 取模對負數(shù)的處理；2，預(yù)分桶的時候， 一個hash 中存儲的值最好不要超過 512 ，100 左右較為合適

4：大Bitmap或布隆過濾器（Bloom）拆分

使用bitmap或布隆過濾器的場景，往往是數(shù)據(jù)量極大的情況，在這種情況下，Bitmap和布隆過濾器使用空間也比較大，比如用于公司userid匹配的布隆過濾器，就需要512MB的大小，這對redis來說是絕對的大value了。

這種場景下，我們就需要對其進行拆分，拆分為足夠小的Bitmap，比如將512MB的大Bitmap拆分為1024個512KB的Bitmap。不過拆分的時候需要注意，要將每個key落在一個Bitmap上。有些業(yè)務(wù)只是把Bitmap 拆開， 但還是當做一個整體的bitmap看， 所以一個 key 還是落在多個 Bitmap 上，這樣就有可能導(dǎo)致一個key請求需要查詢多個節(jié)點、多個Bitmap。如下圖，被請求的值被hash到多個Bitmap上，也就是redis的多個key上，這些key還有可能在不同節(jié)點上，這樣拆分顯然大大降低了查詢的效率。

圖片

因此我們所要做的是把所有拆分后的Bitmap當作獨立的bitmap，然后通過hash將不同的key分配給不同的bitmap上，而不是把所有的小Bitmap當作一個整體。這樣做后每次請求都只要取redis中一個key即可。

圖片

圖片有同學可能會問，通過這樣拆分后，相當于Bitmap變小了，會不會增加布隆過濾器的誤判率？實際上是不會的，布隆過濾器的誤判率是哈希函數(shù)個數(shù)k，集合元素個數(shù)n，以及Bitmap大小m所決定的，其約等于

圖片

。因此如果我們在第一步，也就是在分配key給不同Bitmap時，能夠盡可能均勻的拆分，那么n／m的值幾乎是一樣的，誤判率也就不會改變。具體的誤判率推導(dǎo)可以參考wiki：Bloom_filter

同時，客戶端也提供便利的api （>=2.3.4版本）， setBits/ getBits 用于一次操作同一個key的多個bit值 。

建議 ：k 取 13 個， 單個bloomfilter控制在 512KB 以下

以上方案僅供參考，歡迎大家提供其他的優(yōu)秀方案。