偷偷摘套内射激情视频,久久精品99国产国产精,中文字幕无线乱码人妻,中文在线中文a,性爽19p

Redis存儲(chǔ)總用String?你大概錯(cuò)過(guò)了更優(yōu)的使用方法

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

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)型:

 

  1. SET string:order:100 order-100  
  2. TYPE string:order:100  
  3. 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)行累加操作。

 

  1. HMSET hash:mall:page:ab:metrics:index topbanner 10 leftbanner 5 rightbanner 8 bottombanner 20 productmore 10 topshopping 8  
  2. OK  
  3. HGETALL hash:mall:page:ab:metrics:index  
  4.  1) "topbanner"  
  5.  2) "10"  
  6.  3) "leftbanner"  
  7.  4) "5"  
  8.  5) "rightbanner"  
  9.  6) "8"  
  10.  7) "bottombanner"  
  11.  8) "20"  
  12.  9) "productmore"  
  13. 10) "10"  
  14. 11) "topshopping"  
  15. 12) "8" 
  16. HINCRBY hash:mall:page:ab:metrics:index topbanner 1
  17. (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è)集合的交集。

 

  1. SADD set:marketing:product:available:ids 1000100 1000120 1000130 1000140 1000150 1000160  
  2.  
  3. SMEMBERS set:marketing:product:available:ids  
  4. 1) "1000100"  
  5. 2) "1000120"  
  6. 3) "1000130"  
  7. 4) "1000140"  
  8. 5) "1000150"  
  9. 6) "1000160"   
  10. SADD set:marketing:activity:product:ids 1000100 1000120 1000130 1000140 1000200 1000300  
  11.  
  12. SMEMBERS set:marketing:activity:product:ids  
  13. 1) "1000100"  
  14. 2) "1000120"  
  15. 3) "1000130"  
  16. 4) "1000140"  
  17. 5) "1000200"  
  18. 6) "1000300"  
  19.  
  20. SINTER set:marketing:product:available:ids set:marketing:activity:product:ids  
  21. 1) "1000100"  
  22. 2) "1000120"  
  23. 3) "1000130"  
  24. 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ù)累加和:

 

 

 

  1. ZADD zset:marketing:groupon:group:codes 5 G_PXYJY9QQFA 8 G_4EXMT6NZJQ 20 G_W7BMF5QC2P 10 G_429DHBTGZX 8 G_KHZGH9U4PP  
  2. ZREVRANGEBYSCORE zset:marketing:groupon:group:codes 1000 0  
  3. 1) "G_W7BMF5QC2P"  
  4. 2) "G_ZMZ69HJUCB"  
  5. 3) "G_429DHBTGZX"  
  6. 4) "G_KHZGH9U4PP"  
  7. 5) "G_4EXMT6NZJQ"  
  8. 6) "G_PXYJY9QQFA"   
  9.  
  10. ZREVRANGEBYSCORE zset:marketing:groupon:group:codes 1000 0 withscores  
  11.  1) "G_W7BMF5QC2P"  
  12.  2) "20"  
  13.  3) "G_ZMZ69HJUCB"  
  14.  4) "10" 
  15.  5) "G_429DHBTGZX"  
  16.  6) "10"  
  17.  7) "G_KHZGH9U4PP"  
  18.  8) "8"  
  19.  9) "G_4EXMT6NZJQ"  
  20. 10) "8"  
  21. 11) "G_PXYJY9QQFA"  
  22. 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ū)間。

 

  1. ZADD zset:marketing:groupon:hottop:condition:2986080 0 G4ZD5732YZQ 0 G5VW3YF42UC 0 GF773FEJ7CC 0 GFW8DUEND8S 0 GKPKKW8XEY9 0 GL324DGWMZM  
  2. (integer) 6  
  3. 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  
  4. (integer) 10  
  5. ZINTERSTORE zset:marketing:groupon:hottop:condition:interstore 2 zset:marketing:groupon:hottop:condition:2986080 zset:marketing:groupon:hottop:available:group  
  6. (integer) 6  
  7. ZRANGE zset:marketing:groupon:hottop:condition:interstore 0 -1 withscores  
  8. 1) "GF773FEJ7CC"  
  9. 2) "15"  
  10. 3) "G5VW3YF42UC"  
  11. 4) "17"  
  12. 5) "G4ZD5732YZQ"  
  13. 6) "18"  
  14. 7) "GKPKKW8XEY9"  
  15. 8) "40"  
  16. 9) "GL324DGWMZM"  
  17. 10) "45"  
  18. 11) "GFW8DUEND8S"  
  19. 12) "50"  
  20. ZREVRANGE zset:marketing:groupon:hottop:condition:interstore 2 4 withscores  
  21. 1) "GKPKKW8XEY9"  
  22. 2) "40"  
  23. 3) "G4ZD5732YZQ"  
  24. 4) "18"  
  25. 5) "G5VW3YF42UC"  
  26. 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)型的。歡迎大家留言討論。 

責(zé)任編輯:龐桂玉 來(lái)源: Java團(tuán)長(zhǎng)
相關(guān)推薦

2020-03-06 15:20:34

Redis存儲(chǔ)String

2019-12-27 15:18:01

微軟

2019-01-08 11:57:10

Redis存儲(chǔ)數(shù)據(jù)結(jié)構(gòu)

2024-05-24 10:51:51

框架Java

2018-11-27 05:46:10

等待時(shí)間悖論公交車(chē)數(shù)據(jù)分析

2023-04-11 16:31:10

開(kāi)發(fā)React 庫(kù)Web

2017-08-01 10:47:12

瓦戈

2022-09-19 00:46:18

JavaScrip功能開(kāi)發(fā)

2011-02-24 13:09:10

FireFTP

2012-01-13 09:55:54

jQuery

2018-02-04 14:44:11

2012-11-14 13:55:10

2020-09-01 15:10:15

編程CSSJava

2016-03-04 11:06:20

更優(yōu)秀程序員

2009-12-24 16:36:06

WPF InkCanv

2017-09-13 09:45:37

iPhone XiPhone 8

2010-10-08 16:01:17

mysql UPDAT

2013-07-15 15:12:40

iOS多線程NSOperationNSOperation

2009-12-02 16:04:44

PHP fsockop
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)