Redis為我們提供了5種數(shù)據(jù)類(lèi)型，基本上我們使用頻率***的就是String，而對(duì)其他四種數(shù)據(jù)類(lèi)型使用的頻次稍弱于String。原因在于：

• String使用起來(lái)比較簡(jiǎn)單，可以方便存儲(chǔ)復(fù)雜的對(duì)象，使用場(chǎng)景比較多;
• 由于Redis expire time只能設(shè)置在key上，像List、Hash、Set、Zset屬于集合類(lèi)型，會(huì)管理一組item，我們無(wú)法在這些集合的item上設(shè)置過(guò)期時(shí)間，所以使用expiretime來(lái)處理集合的cache失效會(huì)變得稍微復(fù)雜些。但是String使用expire time來(lái)管理過(guò)期策略會(huì)比較簡(jiǎn)單，因?yàn)樗捻?xiàng)少。這里說(shuō)的集合是寬泛的類(lèi)似集合。
• 從更深層次來(lái)看，我們對(duì)另外四種數(shù)據(jù)類(lèi)型的使用和原理并不是太了解。所以這個(gè)時(shí)候往往會(huì)忽視在特定場(chǎng)景下使用某種數(shù)據(jù)類(lèi)型會(huì)比String性能高出很多的可能性，比如使用Hash結(jié)構(gòu)來(lái)提高某實(shí)體某個(gè)項(xiàng)的修改等。

這里我們不打算羅列這5種數(shù)據(jù)類(lèi)型的使用方法，因?yàn)檫@些資料網(wǎng)上有很多。我們主要討論這5種數(shù)據(jù)類(lèi)型的功能特點(diǎn)，弄清楚它們分別適合用于處理哪些現(xiàn)實(shí)的業(yè)務(wù)場(chǎng)景，我們又該如何組合性使用這5種數(shù)據(jù)類(lèi)型，找到解決復(fù)雜cache問(wèn)題的***方案。

一、Redis的數(shù)據(jù)類(lèi)型及特點(diǎn)

我們來(lái)簡(jiǎn)要了解一下String、List、Hash、Set及Zset：

1)String

String是Redis提供的字符串類(lèi)型。可以針對(duì)String類(lèi)型獨(dú)立設(shè)置expire time，通常用來(lái)存儲(chǔ)長(zhǎng)字符串?dāng)?shù)據(jù)，比如某個(gè)對(duì)象的json字符串。

在使用上，String類(lèi)型最巧妙的是可以動(dòng)態(tài)拼接key。通常我們可以將一組id放在Set里，然后動(dòng)態(tài)查找String還是否存在，如果不存在說(shuō)明已經(jīng)過(guò)期或者由于數(shù)據(jù)修改主動(dòng)delete了，需要再做一次cache數(shù)據(jù)load。

雖然Set無(wú)法設(shè)置item的過(guò)期時(shí)間，但是我們可以將Set Item與String Key關(guān)聯(lián)來(lái)達(dá)到相同的效果。

下圖中的左邊是一個(gè)key為Set:order:ids的Set集合，它可能是一個(gè)全量集合，也可能是某個(gè)查詢(xún)條件獲取出來(lái)的一個(gè)集合：

 

 

有時(shí)候復(fù)雜點(diǎn)的場(chǎng)景需要多個(gè)Set集合來(lái)支撐計(jì)算，在Redis服務(wù)器里可能會(huì)有很多類(lèi)似這樣的集合。這些集合我們可以稱(chēng)為功能數(shù)據(jù)，這些數(shù)據(jù)是用來(lái)輔助cache計(jì)算的，當(dāng)進(jìn)行各種集合運(yùn)算之后會(huì)得出當(dāng)前查詢(xún)需要返回的子集，***我們才會(huì)去獲取某個(gè)訂單真正的數(shù)據(jù)。

這些String:order:{orderId}字符串key并不一定是為了服務(wù)一種場(chǎng)景，而是整個(gè)系統(tǒng)***層的數(shù)據(jù)，各種場(chǎng)景***都需要獲取這些數(shù)據(jù)。那些Set集合可以認(rèn)為是查詢(xún)條件數(shù)據(jù)，用來(lái)輔助查詢(xún)條件的計(jì)算。

Redis為我們提供了TYPE命令來(lái)查看某個(gè)key的數(shù)據(jù)類(lèi)型，如String類(lèi)型：

 

SET string:order:100 order-100  
TYPE string:order:100  
string 

 

2)List

List在提高throughput的場(chǎng)景中非常適用，因?yàn)樗赜械腖PUSH、RPUSH、LPOP、RPOP功能可以無(wú)縫的支持生產(chǎn)者、消費(fèi)者架構(gòu)模式。

這非常適合實(shí)現(xiàn)類(lèi)似Java Concurrency Fork/Join框架中的work-stealing算法(工作竊取)。

注：Java Fork/Join框架使用并行來(lái)提高性能，但是會(huì)帶來(lái)由于并發(fā)take task帶來(lái)的race condition(競(jìng)態(tài)條件)問(wèn)題，所以采用work-stealing算法來(lái)解決由于競(jìng)爭(zhēng)問(wèn)題帶來(lái)的性能損耗。

下圖中模擬了一個(gè)典型的支付callback峰值場(chǎng)景：

 

 

在峰值出現(xiàn)的地方一般我們都會(huì)使用加buffer的方式來(lái)加快請(qǐng)求處理速度，這樣才能提高并發(fā)處理能力，提高through put。

支付gateway收到callback之后不做任何處理直接交給分發(fā)器。

分發(fā)器是一個(gè)無(wú)狀態(tài)的cluster，每個(gè)node通過(guò)向注冊(cè)中心pull handler queue list，也就是獲取下游處理器注冊(cè)到注冊(cè)中心里的消息通道。每一個(gè)分發(fā)器node會(huì)維護(hù)一個(gè)本地queue list，然后順序推送消息到這些queue list即可。

這里會(huì)有點(diǎn)小問(wèn)題，就是支付gateway調(diào)用分發(fā)器的時(shí)候，是如何做load balance?如果不是平均負(fù)載可能會(huì)有某個(gè)queue list高出其他queue list。

而分發(fā)器不需要做soft load balance，因?yàn)槟呐履硞€(gè)queue list比其他queue list多也無(wú)所謂，因?yàn)橄掠蝝essage handler會(huì)根據(jù)work-stealing算法來(lái)竊取其他消費(fèi)慢的queue list。

Redis List的LPUSH、RPUSH、LPOP、RPOP特性確實(shí)可以在很多場(chǎng)景下提高這種橫向擴(kuò)展計(jì)算能力。

3)Hash

Hash數(shù)據(jù)類(lèi)型很明顯是基于Hash算法的，對(duì)于項(xiàng)的查找時(shí)間復(fù)雜度是O(1)的，在極端情況下可能出現(xiàn)項(xiàng)Hash沖突問(wèn)題，Redis內(nèi)部是使用鏈表加key判斷來(lái)解決的。具體Redis內(nèi)部的數(shù)據(jù)結(jié)構(gòu)我們?cè)诤竺嬗薪榻B，這里就不展開(kāi)了。

Hash數(shù)據(jù)類(lèi)型的特點(diǎn)通?？梢杂脕?lái)解決帶有映射關(guān)系，同時(shí)又需要對(duì)某些項(xiàng)進(jìn)行更新或者刪除等操作。如果不是某個(gè)項(xiàng)需要維護(hù)，那么一般可以通過(guò)使用String來(lái)解決。

如果有需要對(duì)某個(gè)字段進(jìn)行修改，使用String很明顯會(huì)多出很多開(kāi)銷(xiāo)，需要讀取出來(lái)反序列化成對(duì)象然后操作，然后再序列化寫(xiě)回Redis，這中間可能還有并發(fā)問(wèn)題。

那我們可以使用Redis Hash提供的實(shí)體屬性Hash存儲(chǔ)特性，我們可以認(rèn)為Hash Value是一個(gè)Hash Table，實(shí)體的每一個(gè)屬性都是通過(guò)Hash得到屬性的最終數(shù)據(jù)索引。

下圖使用Hash數(shù)據(jù)類(lèi)型來(lái)記錄頁(yè)面的a/bmetrics：

 

 

左邊的是首頁(yè)index的各個(gè)區(qū)域的統(tǒng)計(jì)，右邊是營(yíng)銷(xiāo)marketing的各個(gè)區(qū)域統(tǒng)計(jì)。

在程序里我們可以很方便的使用Redis的atomic特性對(duì)Hash某個(gè)項(xiàng)進(jìn)行累加操作。

 

HMSET hash:mall:page:ab:metrics:index topbanner 10 leftbanner 5 rightbanner 8 bottombanner 20 productmore 10 topshopping 8  
OK  
HGETALL hash:mall:page:ab:metrics:index  
 1) "topbanner"  
 2) "10"  
 3) "leftbanner"  
 4) "5"  
 5) "rightbanner"  
 6) "8"  
 7) "bottombanner"  
 8) "20"  
 9) "productmore"  
10) "10"  
11) "topshopping"  
12) "8" 
HINCRBY hash:mall:page:ab:metrics:index topbanner 1
(integer) 11

使用Redis Hash Increment進(jìn)行原子增加操作。HINCRBY命令可以原子增加任何給定的整數(shù)，也可以通過(guò)HINCRBYFLOAT來(lái)原子增加浮點(diǎn)類(lèi)型數(shù)據(jù)。

4)Set

Set集合數(shù)據(jù)類(lèi)型可以支持集合運(yùn)算，不能存儲(chǔ)重復(fù)數(shù)據(jù)。

Set***的特點(diǎn)就是集合的計(jì)算能力，inter交集、union并集、diff差集，這些特點(diǎn)可以用來(lái)做高性能的交叉計(jì)算或者剔除數(shù)據(jù)。

Set集合在使用場(chǎng)景上還是比較多和自由的。舉個(gè)簡(jiǎn)單的例子，在應(yīng)用系統(tǒng)中比較常見(jiàn)的就是商品、活動(dòng)類(lèi)場(chǎng)景。用一個(gè)Set緩存有效商品集合，再用一個(gè)Set緩存活動(dòng)商品集合。如果商品出現(xiàn)上下架操作只需要維護(hù)有效商品Set，每次獲取活動(dòng)商品的時(shí)候需要過(guò)濾下是否有下架商品，如果有就需要從活動(dòng)商品中剔除。

當(dāng)然，下架的時(shí)候可以直接刪除緩存的活動(dòng)商品，但是活動(dòng)是從marketing系統(tǒng)中l(wèi)oad出來(lái)的，就算我將cache里的活動(dòng)商品刪除，當(dāng)下次再?gòu)膍arketing系統(tǒng)中l(wèi)oad活動(dòng)商品時(shí)候還是會(huì)有下架商品。

當(dāng)然這只是舉例，一個(gè)場(chǎng)景有不同的實(shí)現(xiàn)方法。

下圖中左右兩邊是兩個(gè)不同的集合：

 

 

左邊是營(yíng)銷(xiāo)域中的可用商品ids集合，右邊是營(yíng)銷(xiāo)域中活動(dòng)商品ids集合，中間計(jì)算出兩個(gè)集合的交集。

 

SADD set:marketing:product:available:ids 1000100 1000120 1000130 1000140 1000150 1000160  
 
SMEMBERS set:marketing:product:available:ids  
1) "1000100"  
2) "1000120"  
3) "1000130"  
4) "1000140"  
5) "1000150"  
6) "1000160"   
SADD set:marketing:activity:product:ids 1000100 1000120 1000130 1000140 1000200 1000300  
 
SMEMBERS set:marketing:activity:product:ids  
1) "1000100"  
2) "1000120"  
3) "1000130"  
4) "1000140"  
5) "1000200"  
6) "1000300"  
 
SINTER set:marketing:product:available:ids set:marketing:activity:product:ids  
1) "1000100"  
2) "1000120"  
3) "1000130"  
4) "1000140" 

 

在一些復(fù)雜的場(chǎng)景中，也可以使用SINTERSTORE命令將交集計(jì)算后的結(jié)果存儲(chǔ)在一個(gè)目標(biāo)集合中。這在使用pipeline命令管道中特別有用，將SINTERSTORE命令包裹在pipeline命令串中可以重復(fù)使用計(jì)算出來(lái)的結(jié)果集。

由于Redis是Signle-Thread單線程模型，基于這個(gè)特性我們就可以使用Redis提供的pipeline管道來(lái)提交一連串帶有邏輯的命令集合，這些命令在處理期間不會(huì)被其他客戶(hù)端的命令干擾。

5)Zset

Zset排序集合與Set集合類(lèi)似，但是Zset提供了排序的功能。在介紹Set集合的時(shí)候我們知道Set集合中的成員是無(wú)序的，Zset填補(bǔ)了集合可以排序的空隙。

Zset***大的功能就是可以根據(jù)某個(gè)score比分值進(jìn)行排序，這在很多業(yè)務(wù)場(chǎng)景中非常急需。比如，在促銷(xiāo)活動(dòng)里根據(jù)商品的銷(xiāo)售數(shù)量來(lái)排序商品，在旅游景區(qū)里根據(jù)流入人數(shù)來(lái)排序熱門(mén)景點(diǎn)等?；旧先藗?cè)谧鋈魏问虑槎夹枰鶕?jù)某些條件進(jìn)行排序。

其實(shí)Zset在我們應(yīng)用系統(tǒng)中能用到地方到處都是，這里我們舉一個(gè)簡(jiǎn)單的例子，在團(tuán)購(gòu)系統(tǒng)中我們通常需要根據(jù)參團(tuán)人數(shù)來(lái)排序成團(tuán)列表，大家都希望參加那些即將成團(tuán)的團(tuán)。

下圖是一個(gè)根據(jù)團(tuán)購(gòu)code創(chuàng)建的Zset，score分值就是參團(tuán)人數(shù)累加和：

 

 

 

ZADD zset:marketing:groupon:group:codes 5 G_PXYJY9QQFA 8 G_4EXMT6NZJQ 20 G_W7BMF5QC2P 10 G_429DHBTGZX 8 G_KHZGH9U4PP  
ZREVRANGEBYSCORE zset:marketing:groupon:group:codes 1000 0  
1) "G_W7BMF5QC2P"  
2) "G_ZMZ69HJUCB"  
3) "G_429DHBTGZX"  
4) "G_KHZGH9U4PP"  
5) "G_4EXMT6NZJQ"  
6) "G_PXYJY9QQFA"   
 
ZREVRANGEBYSCORE zset:marketing:groupon:group:codes 1000 0 withscores  
 1) "G_W7BMF5QC2P"  
 2) "20"  
 3) "G_ZMZ69HJUCB"  
 4) "10" 
 5) "G_429DHBTGZX"  
 6) "10"  
 7) "G_KHZGH9U4PP"  
 8) "8"  
 9) "G_4EXMT6NZJQ"  
10) "8"  
11) "G_PXYJY9QQFA"  
12) "5" 

 

Zset本身提供了很多方法用來(lái)進(jìn)行集合的排序，如果需要score分值，可以使用withscore字句帶出每一項(xiàng)的分值。

在一些比較特殊的場(chǎng)合可能需要組合排序，可能有多個(gè)Zset分別用來(lái)對(duì)同一個(gè)實(shí)體在不同維度的排序，按時(shí)間排序、按人數(shù)排序等。這個(gè)時(shí)候就可以組合使用Zset帶來(lái)的便捷性，利用pipeline再結(jié)合多個(gè)Zset最終得出組合排序集合。

二、案例：滬江團(tuán)購(gòu)系統(tǒng)大促hot-top接口cache設(shè)計(jì)

以滬江團(tuán)購(gòu)系統(tǒng)大促hot-top接口cache設(shè)計(jì)為例，我們總結(jié)了Redis提供的5種數(shù)據(jù)類(lèi)型的各自特點(diǎn)和一般的使用場(chǎng)景。但是我們不僅僅可以分開(kāi)使用這些數(shù)據(jù)類(lèi)型，我們完全可以綜合使用這些數(shù)據(jù)類(lèi)型來(lái)完成復(fù)雜的cache場(chǎng)景。

下面我們分享一個(gè)使用多個(gè)Zset、String來(lái)優(yōu)化團(tuán)購(gòu)系統(tǒng)前臺(tái)接口的例子。由于篇幅和時(shí)間限制，這里只介紹跟本次案例相關(guān)的信息。

注：hot-top接口是指熱點(diǎn)、排名接口的意思，表示它的瀏覽量、并發(fā)量比較高，一般大促的時(shí)候都會(huì)有幾個(gè)這種性能要求比較高的接口。

我們先來(lái)分析一個(gè)查詢(xún)接口所包含的常規(guī)信息。

首先一個(gè)查詢(xún)接口肯定是有query condition查詢(xún)條件，然后是sort排序信息、***是page分頁(yè)信息。這是一般接口所承擔(dān)的基本職責(zé)，當(dāng)然，特殊場(chǎng)景下還需要支持master/slave replication時(shí)關(guān)于數(shù)據(jù)session一致性的要求，需要提供跟蹤標(biāo)記來(lái)回master查詢(xún)數(shù)據(jù)，這里就不展開(kāi)了。

我們可以抽象出這幾個(gè)維度的信息：

• querycondition：查詢(xún)條件，companyid =100，sellerid=1010101諸如此類(lèi)。
• sort：排序信息，一般是默認(rèn)一個(gè)列排序，但是在復(fù)雜的場(chǎng)景下會(huì)有可能讓接口使用者定制排序字段，比如一些租戶(hù)信息列。
• page：分頁(yè)信息，簡(jiǎn)單理解就是數(shù)據(jù)記錄排完序之后的第幾行到第幾行。

由于這里我們純粹用Redis來(lái)提高cache能力，不涉及到有關(guān)于任何搜索的能力，所以這里忽略其他復(fù)雜查詢(xún)的情況。其實(shí)我們?cè)趶?fù)雜的地方使用了Elastcsearch來(lái)提高搜索能力。

上述我們分析總結(jié)出了一個(gè)查詢(xún)接口的基本信息，這里還有一個(gè)有關(guān)于高并發(fā)接口的設(shè)計(jì)原則，就是將hot-top接口和一般search接口分離開(kāi)，因?yàn)橹挥蟹侄沃拍芊謩e根據(jù)特點(diǎn)選用不同的技術(shù)。

如果我們不分職責(zé)將所有的查詢(xún)場(chǎng)景封裝在一個(gè)接口里，那么在后面優(yōu)化接口性能的時(shí)候基本就很麻煩了，有些場(chǎng)景是無(wú)法或者很難用cache來(lái)解決的，因?yàn)榻涌诶锺詈狭烁鞣N場(chǎng)景邏輯，就算勉強(qiáng)能實(shí)現(xiàn)性能也不會(huì)高。

前面做這些鋪墊是為了能在介紹案例的時(shí)候達(dá)成一個(gè)基本的共識(shí)?，F(xiàn)在我們來(lái)看下這個(gè)團(tuán)購(gòu)系統(tǒng)的hot-top接口的具體邏輯。

注：在大促的時(shí)候需要展現(xiàn)團(tuán)購(gòu)列表，這個(gè)接口的訪問(wèn)量是非常大的，團(tuán)購(gòu)活動(dòng)需要根據(jù)參團(tuán)人數(shù)倒序排序，并且分頁(yè)返回指定數(shù)量的團(tuán)列表。我們假設(shè)這個(gè)接口名為getTopGroups(getTopGroupsRequestrequest)。

1)query condition查詢(xún)條件問(wèn)題

我們來(lái)仔細(xì)分析下，首先不同的查詢(xún)條件從DB里查詢(xún)出來(lái)的數(shù)據(jù)是不一樣的，也就是說(shuō)查詢(xún)出來(lái)的團(tuán)列表是不一樣的，可能有company公司、channel渠道等過(guò)濾條件。

由于一個(gè)團(tuán)購(gòu)活動(dòng)下不會(huì)有太多團(tuán)，頂多上百個(gè)是極限了，所以一個(gè)查詢(xún)條件出來(lái)的團(tuán)列表也頂多幾十個(gè)，而且根據(jù)場(chǎng)景分析熱點(diǎn)查詢(xún)條件不會(huì)超過(guò)十個(gè)，所以我們選擇將查詢(xún)條件Hash出一個(gè)code來(lái)緩存本次查詢(xún)條件的全量團(tuán)列表集合，但是這些結(jié)果集是沒(méi)有任何排序的。

2)sort排序問(wèn)題

再看根據(jù)參團(tuán)人數(shù)排序問(wèn)題，我們立刻就可以想到使用Zset來(lái)處理團(tuán)排序問(wèn)題，因?yàn)橹挥幸粋€(gè)排序維度，所以一個(gè)Zset就夠了。我們使用一個(gè)Zset來(lái)緩存所有團(tuán)的參團(tuán)人數(shù)集合，它是一個(gè)全量的團(tuán)排序集合。

那么我們?nèi)绾螌⒂脩?hù)的查詢(xún)條件出來(lái)的團(tuán)列表根據(jù)參團(tuán)人數(shù)排序呢?剛好可以使用Zset的交集運(yùn)算，直接計(jì)算出當(dāng)前這個(gè)集合的Zset子集。

3)page分頁(yè)問(wèn)題

通過(guò)對(duì)已經(jīng)排序之后的團(tuán)列表Zset使用Zrange來(lái)獲取出分頁(yè)集合。我們來(lái)看下完整的流程，如何處理查詢(xún)、排序、分頁(yè)的。

下圖從query condition計(jì)算Hash Code，然后通過(guò)DB查詢(xún)出當(dāng)前條件全量團(tuán)列表：

 

zset:marketing:groupon:hottop:available:groupkey表示全量團(tuán)的參團(tuán)人數(shù)，用一個(gè)Zset來(lái)緩存。接著將這兩個(gè)Zset計(jì)算交集，就可以得出當(dāng)前查詢(xún)所需要的帶有參團(tuán)人數(shù)的Zset，***在使用Zrevrange獲取分頁(yè)區(qū)間。

 

ZADD zset:marketing:groupon:hottop:condition:2986080 0 G4ZD5732YZQ 0 G5VW3YF42UC 0 GF773FEJ7CC 0 GFW8DUEND8S 0 GKPKKW8XEY9 0 GL324DGWMZM  
(integer) 6  
ZADD zset:marketing:groupon:hottop:available:group 5 GN7KQH36ZWK 10 GS7VB22AWD4 15 GF773FEJ7CC 17 G5VW3YF42UC 18 G4ZD5732YZQ 32 GTYJKCEJBRR 40 GKPKKW8XEY9 45 GL324DGWMZM 50 GFW8DUEND8S 60 GYTKY4ACWLT  
(integer) 10  
ZINTERSTORE zset:marketing:groupon:hottop:condition:interstore 2 zset:marketing:groupon:hottop:condition:2986080 zset:marketing:groupon:hottop:available:group  
(integer) 6  
ZRANGE zset:marketing:groupon:hottop:condition:interstore 0 -1 withscores  
1) "GF773FEJ7CC"  
2) "15"  
3) "G5VW3YF42UC"  
4) "17"  
5) "G4ZD5732YZQ"  
6) "18"  
7) "GKPKKW8XEY9"  
8) "40"  
9) "GL324DGWMZM"  
10) "45"  
11) "GFW8DUEND8S"  
12) "50"  
ZREVRANGE zset:marketing:groupon:hottop:condition:interstore 2 4 withscores  
1) "GKPKKW8XEY9"  
2) "40"  
3) "G4ZD5732YZQ"  
4) "18"  
5) "G5VW3YF42UC"  
6) "17" 

 

有了返回的團(tuán)code集合之后就可以通過(guò)mget來(lái)批量獲取String類(lèi)型的團(tuán)詳情信息，這里就不貼出代碼了。

由于篇幅和時(shí)間關(guān)系，我們不展開(kāi)太多的業(yè)務(wù)場(chǎng)景介紹了。這其中還涉及到計(jì)算cache過(guò)期時(shí)間的問(wèn)題，這也跟促銷(xiāo)活動(dòng)的運(yùn)營(yíng)規(guī)則有關(guān)系，還涉及到有可能query condition hash沖突問(wèn)題等，但是這些已經(jīng)不與我們本節(jié)主題相關(guān)。

下一期我們將會(huì)著重講講Redis內(nèi)存數(shù)據(jù)結(jié)構(gòu)與編碼，弄清Redis內(nèi)部到底是如何支持這5種數(shù)據(jù)類(lèi)型的。歡迎大家留言討論。