小編給大家分享一下redis的數(shù)據(jù)類型及特點有哪些，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

武川網(wǎng)站建設(shè)公司創(chuàng)新互聯(lián)建站,武川網(wǎng)站設(shè)計制作，有大型網(wǎng)站制作公司豐富經(jīng)驗。已為武川1000多家提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\外貿(mào)網(wǎng)站建設(shè)要多少錢，請找那個售后服務(wù)好的武川做網(wǎng)站的公司定做！

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

• String使用起來比較簡單，可以方便存儲復(fù)雜的對象，使用場景比較多;

• 由于Redis expire  time只能設(shè)置在key上，像List、Hash、Set、Zset屬于集合類型，會管理一組item，我們無法在這些集合的item上設(shè)置過期時間，所以使用expiretime來處理集合的cache失效會變得稍微復(fù)雜些。但是String使用expire  time來管理過期策略會比較簡單，因為它包含的項少。這里說的集合是寬泛的類似集合。

• 從更深層次來看，我們對另外四種數(shù)據(jù)類型的使用和原理并不是太了解。所以這個時候往往會忽視在特定場景下使用某種數(shù)據(jù)類型會比String性能高出很多的可能性，比如使用Hash結(jié)構(gòu)來提高某實體某個項的修改等。

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

一、Redis的數(shù)據(jù)類型及特點

我們來簡要了解一下String、List、Hash、Set及Zset：

1)String

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

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

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

下圖中的左邊是一個key為Set:order:ids的Set集合，它可能是一個全量集合，也可能是某個查詢條件獲取出來的一個集合：

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

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

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

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

2)List

List在提高throughput的場景中非常適用，因為它特有的LPUSH、RPUSH、LPOP、RPOP功能可以無縫的支持生產(chǎn)者、消費者架構(gòu)模式。

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

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

下圖中模擬了一個典型的支付callback峰值場景：

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

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

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

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

而分發(fā)器不需要做soft load balance，因為哪怕某個queue list比其他queue list多也無所謂，因為下游message  handler會根據(jù)work-stealing算法來竊取其他消費慢的queue list。

Redis List的LPUSH、RPUSH、LPOP、RPOP特性確實可以在很多場景下提高這種橫向擴展計算能力。

3)Hash

Hash數(shù)據(jù)類型很明顯是基于Hash算法的，對于項的查找時間復(fù)雜度是O(1)的，在極端情況下可能出現(xiàn)項Hash沖突問題，Redis內(nèi)部是使用鏈表加key判斷來解決的。具體Redis內(nèi)部的數(shù)據(jù)結(jié)構(gòu)我們在后面有介紹，這里就不展開了。

Hash數(shù)據(jù)類型的特點通?？梢杂脕斫鉀Q帶有映射關(guān)系，同時又需要對某些項進行更新或者刪除等操作。如果不是某個項需要維護，那么一般可以通過使用String來解決。

如果有需要對某個字段進行修改，使用String很明顯會多出很多開銷，需要讀取出來反序列化成對象然后操作，然后再序列化寫回Redis，這中間可能還有并發(fā)問題。

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

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

左邊的是首頁index的各個區(qū)域的統(tǒng)計，右邊是營銷marketing的各個區(qū)域統(tǒng)計。

在程序里我們可以很方便的使用Redis的atomic特性對Hash某個項進行累加操作。

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進行原子增加操作。HINCRBY命令可以原子增加任何給定的整數(shù)，也可以通過HINCRBYFLOAT來原子增加浮點類型數(shù)據(jù)。

4)Set

Set集合數(shù)據(jù)類型可以支持集合運算，不能存儲重復(fù)數(shù)據(jù)。

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

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

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

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

下圖中左右兩邊是兩個不同的集合：

左邊是營銷域中的可用商品ids集合，右邊是營銷域中活動商品ids集合，中間計算出兩個集合的交集。

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ù)雜的場景中，也可以使用SINTERSTORE命令將交集計算后的結(jié)果存儲在一個目標(biāo)集合中。這在使用pipeline命令管道中特別有用，將SINTERSTORE命令包裹在pipeline命令串中可以重復(fù)使用計算出來的結(jié)果集。

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

5)Zset

Zset排序集合與Set集合類似，但是Zset提供了排序的功能。在介紹Set集合的時候我們知道Set集合中的成員是無序的，Zset填補了集合可以排序的空隙。

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

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

下圖是一個根據(jù)團購code創(chuàng)建的Zset，score分值就是參團人數(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本身提供了很多方法用來進行集合的排序，如果需要score分值，可以使用withscore字句帶出每一項的分值。

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

二、案例：滬江團購系統(tǒng)大促hot-top接口cache設(shè)計

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

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

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

我們先來分析一個查詢接口所包含的常規(guī)信息。

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

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

• querycondition：查詢條件，companyid =100，sellerid=1010101諸如此類。

• sort：排序信息，一般是默認一個列排序，但是在復(fù)雜的場景下會有可能讓接口使用者定制排序字段，比如一些租戶信息列。

• page：分頁信息，簡單理解就是數(shù)據(jù)記錄排完序之后的第幾行到第幾行。

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

上述我們分析總結(jié)出了一個查詢接口的基本信息，這里還有一個有關(guān)于高并發(fā)接口的設(shè)計原則，就是將hot-top接口和一般search接口分離開，因為只有分而治之才能分別根據(jù)特點選用不同的技術(shù)。

如果我們不分職責(zé)將所有的查詢場景封裝在一個接口里，那么在后面優(yōu)化接口性能的時候基本就很麻煩了，有些場景是無法或者很難用cache來解決的，因為接口里耦合了各種場景邏輯，就算勉強能實現(xiàn)性能也不會高。

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

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

1)query condition查詢條件問題

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

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

2)sort排序問題

再看根據(jù)參團人數(shù)排序問題，我們立刻就可以想到使用Zset來處理團排序問題，因為只有一個排序維度，所以一個Zset就夠了。我們使用一個Zset來緩存所有團的參團人數(shù)集合，它是一個全量的團排序集合。

那么我們?nèi)绾螌⒂脩舻牟樵儣l件出來的團列表根據(jù)參團人數(shù)排序呢?剛好可以使用Zset的交集運算，直接計算出當(dāng)前這個集合的Zset子集。

3)page分頁問題

通過對已經(jīng)排序之后的團列表Zset使用Zrange來獲取出分頁集合。我們來看下完整的流程，如何處理查詢、排序、分頁的。

下圖從query condition計算Hash Code，然后通過DB查詢出當(dāng)前條件全量團列表：

zset:marketing:groupon:hottop:available:groupkey表示全量團的參團人數(shù)，用一個Zset來緩存。接著將這兩個Zset計算交集，就可以得出當(dāng)前查詢所需要的帶有參團人數(shù)的Zset，***在使用Zrevrange獲取分頁區(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"

有了返回的團code集合之后就可以通過mget來批量獲取String類型的團詳情信息，這里就不貼出代碼了。

以上是“Redis的數(shù)據(jù)類型及特點有哪些”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對大家有所幫助，如果還想學(xué)習(xí)更多知識，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道！

本文題目：Redis的數(shù)據(jù)類型及特點有哪些
本文鏈接：http://chinadenli.net/article48/pgoehp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供域名注冊、做網(wǎng)站、響應(yīng)式網(wǎng)站、品牌網(wǎng)站建設(shè)、網(wǎng)站改版、企業(yè)網(wǎng)站制作

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)