exHash 類型是一種支持 Field 過期的新型數(shù)據(jù)類型，它在原先的 Hash 類型基礎(chǔ)上進(jìn)行了擴(kuò)展：在支持 Hash 類型的通用功能以外，exHash 類型還支持為 Field 設(shè)置過期時(shí)間和版本，增強(qiáng)了數(shù)據(jù)結(jié)構(gòu)的靈活性，從而簡化了很多復(fù)雜場景下的業(yè)務(wù)開發(fā)工作。

本文以兩種常見的場景（頻控場景 &購物車）為例，通過使用 GeminiDB Redis 接口中的 exHash 類命令來實(shí)現(xiàn)復(fù)雜的業(yè)務(wù)，簡化開發(fā)難度。

一、exHash 命令使用簡介

命令語法定義如下：

大寫關(guān)鍵字：命令關(guān)鍵字。

斜體：變量。

[options]：可選參數(shù)，不在括號中的參數(shù)為必選。

A|B：該組參數(shù)互斥，請進(jìn)行二選一或多選一。

...：前面的內(nèi)容可重復(fù)。

二、應(yīng)用場景

1.頻控場景

頻控指的是對用戶在一定時(shí)間內(nèi)（例如一天、一周、一個(gè)月）進(jìn)行某種操作的次數(shù)進(jìn)行限制，可以控制特定廣告或信息在一定時(shí)間內(nèi)在特定平臺上的展示次數(shù)，以避免過度曝光和廣告疲勞，同時(shí)優(yōu)化廣告效果和用戶體驗(yàn)；對于廣告來說，也可以提高廣告的效果和轉(zhuǎn)化率。此外，頻控還可以避免惡意行為，如刷流量、刷評論、刷點(diǎn)贊等。

頻控的 3 個(gè)要素包含用戶 ID、廣告 ID、觸發(fā)次數(shù)；以用戶 ID 為 key，廣告 ID 為 field，指定時(shí)間內(nèi)的觸發(fā)次數(shù)為 value，恰好構(gòu)成頻控的三要素。先配置好各個(gè)廣告的指定頻控策略，如下圖所示即可根據(jù)如下的方式來實(shí)現(xiàn)頻控：

最左邊通過 Hash 類型來實(shí)現(xiàn)，通過 expire 命令設(shè)置 User_1 的過期時(shí)間為一天，每推送一次通過 hincrby 來增加指定廣告的推送次數(shù)，每次推送指定廣告前在一天內(nèi)的推送次數(shù)則可以通過 hget 獲取進(jìn)行判斷，一天后該用戶的數(shù)據(jù)自動(dòng)過期無需手動(dòng)清理，這樣便可以簡單地實(shí)現(xiàn)頻控。但這個(gè)方案的缺點(diǎn)在于對于每個(gè)用戶（即每個(gè) key）只能設(shè)置一個(gè)過期時(shí)間，無法做到例如 8 小時(shí) 3 次這樣指定時(shí)間段內(nèi)的靈活的頻控策略。

為了做到對每個(gè)廣告都配置指定時(shí)間段內(nèi)的靈活頻控，如中間圖所示可以通過將時(shí)間戳拼接在 value 里的方式用 Hash 類型來實(shí)現(xiàn)，但這種方案無疑是增加了業(yè)務(wù)側(cè)開發(fā)的工作量。

如最右圖所示，支持給 field 設(shè)置過期時(shí)間的 exHash 類型可以很完美地解決 Hash 類型面對頻控場景的缺點(diǎn)。由于 Field 支持過期時(shí)間設(shè)置，那么該場景下，平臺可以給每個(gè)廣告都配置不同時(shí)間段內(nèi)的頻次要求，假設(shè)此時(shí)給 AD_2 配置的頻控策略為 8 小時(shí)內(nèi) 2 次，那么如圖所示在下一次再準(zhǔn)備給 User_1 推送 AD_2 廣告前，先通過 exhget User_1 AD_2 命令獲取到了該值已經(jīng)是 2 時(shí)，便可以判斷出此時(shí)根據(jù)平臺頻控策略，不應(yīng)該再給 User_1 推送 AD_2 廣告了。而當(dāng) 8 小時(shí)一過，User_1 的 AD_2 這個(gè) field 過期后，exhget 無法再獲取到這個(gè) field 的信息，則可以繼續(xù)給 User_1 推送 AD_2 廣告了。

2.購物車場景

最近雙十一期間，相信很多同學(xué)購物車?yán)锒继顫M了各種想要清空的寶貝，這里就以購物車場景為例介紹該場景的幾種不同 Redis 類型的實(shí)現(xiàn)，并比較這幾種實(shí)現(xiàn)方案的優(yōu)缺點(diǎn)。

1）基于 String 實(shí)現(xiàn)購物車功能

如圖所示基于 String 可以輕松地實(shí)現(xiàn)各個(gè)用戶的購物車功能，該方案需要將用戶 ID 與商品 ID 進(jìn)行拼接作為 key，例如 User_1#Earphones_1，key 對應(yīng)的 value 為購物車中用戶準(zhǔn)備購買的數(shù)量，其中可能有部分商品為限時(shí)特購，所以有過期時(shí)間，為 key 對應(yīng)的過期時(shí)間。

涉及命令如下：

該方案會存在如下問題：

額外拼接增加編、解碼開發(fā)工作量

某個(gè)用戶獲取自己的購物車清單時(shí)還需要通過 scan 命令前綴匹配掃描所有 key，并通過 get 命令去獲取對應(yīng)的值。

想要直接獲取清單長度時(shí)，仍然需要遍歷整個(gè)前綴 key 的數(shù)目，方法復(fù)雜。

存在大量重復(fù)的用戶名前綴，浪費(fèi)存儲空間。

2）基于 Hash 實(shí)現(xiàn)購物車功能

可以根據(jù)如圖所示的 Hash 類型來實(shí)現(xiàn)購物車的管理，用戶 ID 作為 key，商品 ID 作為 field，value 為購物車中對應(yīng)商品的數(shù)量。其中對于部分限時(shí)特購的商品，其過期時(shí)間通過拼接的方式放到 field 對應(yīng)的 value 里。

涉及命令如下：

該方案相對于 String 類型的方案有了不少優(yōu)化：

獲取某個(gè)用戶購物車中的所有商品清單僅需要一個(gè) hgetall 命令即可

獲取某個(gè)用戶的清單長度時(shí)直接 hlen 獲取即可

不存在大量重復(fù)的用戶名前綴問題

然而該方案仍存在一個(gè)明顯的缺點(diǎn)，即對于部分限時(shí)特購的商品處理起來復(fù)雜：對于 User_1 的 Keyboard_1 商品，如果要再加一個(gè)數(shù)量，不能直接使用 hincrby，而是需要先 hget 獲取 Keyboard_1 商品的值并解碼，再加上指定的數(shù)量再編碼后 hset 對應(yīng)的值。

3）基于 exHash 實(shí)現(xiàn)購物車功能

根據(jù)如圖所示的 exHash 類型來實(shí)現(xiàn)購物車的管理，同 Hash 類型一樣，用戶 ID 作為 key，商品 ID 作為 field，value 為購物車中對應(yīng)商品的數(shù)量。其中對于部分限時(shí)特購的商品，由于 exHash 類型可以為 Field 設(shè)置過期時(shí)間，其過期時(shí)間可通過 hset 命令直接設(shè)置。

涉及命令如下：

該方案相對于 Hash 類型的優(yōu)化主要體現(xiàn)在可以直接為各 field 設(shè)置過期時(shí)間，使業(yè)務(wù)側(cè)使用起來簡單又高效?？梢钥吹?exHash 類型相關(guān)的命令和 Hash 類型是類似的，使用起來學(xué)習(xí)成本很低，業(yè)務(wù)側(cè)改造成本相對也比較低。

圖 1.1 華為商城購物車中，用戶 ID、商品 ID、商品數(shù)量及 exhash 類型命令的使用。

三、總結(jié)

本文介紹了 GeminiDB Redis 接口的 exHash 類型的特性、使用方法及應(yīng)用場景。為客戶提供了一種語法與原生 Redis Hash 類型類似、和 Hash 類型的使用相互隔離、支持給 Field 單獨(dú)設(shè)置過期時(shí)間和版本的 exHash 類型作為各種復(fù)雜場景的解決方案。未來，GeminiDB Redis 接口將持續(xù)致力于開發(fā)更多好用的企業(yè)級特性，幫助客戶輕松運(yùn)維，高效開發(fā)。

如果你的業(yè)務(wù)需要一款穩(wěn)定可靠的 KV 數(shù)據(jù)庫，可以試試 GeminiDB Redis 接口。

審核編輯 黃宇