GeminiDB 新特性：讓 Redis 廣告頻控愛不釋手的 exHASH

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

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

一、exHash 命令使用簡(jiǎn)介

命令語法定義如下：

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

斜體：變量。

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

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

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

二、應(yīng)用場(chǎng)景

1.頻控場(chǎng)景

頻控指的是對(duì)用戶在一定時(shí)間內(nèi)（例如一天、一周、一個(gè)月）進(jìn)行某種操作的次數(shù)進(jìn)行限制，可以控制特定廣告或信息在一定時(shí)間內(nèi)在特定平臺(tái)上的展示次數(shù)，以避免過度曝光和廣告疲勞，同時(shí)優(yōu)化廣告效果和用戶體驗(yàn)；對(duì)于廣告來說，也可以提高廣告的效果和轉(zhuǎn)化率。此外，頻控還可以避免惡意行為，如刷流量、刷評(píng)論、刷點(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)清理，這樣便可以簡(jiǎn)單地實(shí)現(xiàn)頻控。但這個(gè)方案的缺點(diǎn)在于對(duì)于每個(gè)用戶（即每個(gè) key）只能設(shè)置一個(gè)過期時(shí)間，無法做到例如 8 小時(shí) 3 次這樣指定時(shí)間段內(nèi)的靈活的頻控策略。

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

如最右圖所示，支持給 field 設(shè)置過期時(shí)間的 exHash 類型可以很完美地解決 Hash 類型面對(duì)頻控場(chǎng)景的缺點(diǎn)。由于 Field 支持過期時(shí)間設(shè)置，那么該場(chǎng)景下，平臺(tái)可以給每個(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ù)平臺(tái)頻控策略，不應(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.購物車場(chǎng)景

最近雙十一期間，相信很多同學(xué)購物車?yán)锒继顫M了各種想要清空的寶貝，這里就以購物車場(chǎng)景為例介紹該場(chǎng)景的幾種不同 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 對(duì)應(yīng)的 value 為購物車中用戶準(zhǔn)備購買的數(shù)量，其中可能有部分商品為限時(shí)特購，所以有過期時(shí)間，為 key 對(duì)應(yīng)的過期時(shí)間。

涉及命令如下：

該方案會(huì)存在如下問題：

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

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

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

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

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

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

涉及命令如下：

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

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

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

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

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

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

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

涉及命令如下：

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

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

三、總結(jié)

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

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

審核編輯 黃宇