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

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

一、exHash 命令使用簡介

命令語法定義如下：

大寫關鍵字：命令關鍵字。

斜體：變量。

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

A|B：該組參數互斥，請進行二選一或多選一。

...：前面的內容可重復。

二、應用場景

1.頻控場景

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

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

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

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

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

2.購物車場景

最近雙十一期間，相信很多同學購物車里都填滿了各種想要清空的寶貝，這里就以購物車場景為例介紹該場景的幾種不同 Redis 類型的實現，并比較這幾種實現方案的優(yōu)缺點。

1）基于 String 實現購物車功能

如圖所示基于 String 可以輕松地實現各個用戶的購物車功能，該方案需要將用戶 ID 與商品 ID 進行拼接作為 key，例如 User_1#Earphones_1，key 對應的 value 為購物車中用戶準備購買的數量，其中可能有部分商品為限時特購，所以有過期時間，為 key 對應的過期時間。

涉及命令如下：

該方案會存在如下問題：

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

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

想要直接獲取清單長度時，仍然需要遍歷整個前綴 key 的數目，方法復雜。

存在大量重復的用戶名前綴，浪費存儲空間。

2）基于 Hash 實現購物車功能

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

涉及命令如下：

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

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

獲取某個用戶的清單長度時直接 hlen 獲取即可

不存在大量重復的用戶名前綴問題

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

3）基于 exHash 實現購物車功能

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

涉及命令如下：

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

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

三、總結

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

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

審核編輯 黃宇