面試官：Redis 大 key 多 key，你要怎么拆分？

2024-11-26 08:09:58

數(shù)據(jù)庫 Redis

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

背景

業(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) ）

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

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

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

ii：該對象每次只需要存取部分?jǐn)?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 本身就有很強(qiáng)的相關(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本身就具有很強(qiáng)的相關(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 取模對負(fù)數(shù)的處理；2，預(yù)分桶的時候，一個hash 中存儲的值最好不要超過 512 ，100 左右較為合適

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

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

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

圖片