資料類型

07-資料類型-資料類型簡介

08-資料類型-string基本操作

09-資料類型-string擴充操作

10-資料類型-string應用場景與key命名約定

11-資料類型-hash基本操作

12-資料類型-hash擴充操作

13-資料類型-hash應用場景

14-資料類型-list基本操作

15-資料類型-list擴充操作

16-資料類型-list應用場景

17-資料類型-set基本操作

18-資料類型-set擴充操作

19-資料類型-set應用場景

20-資料類型-實踐案例

在這個部分，我們将學習一共要學習三大塊内容，首先需要了解一下資料類型，接下來将針對着我們要學習的資料類型進行逐一的講解，如string、hash、list、set等，最後我們通過一個案例來總結前面的資料類型的使用場景。

在講解資料類型之前，我們得先思考一個問題，資料類型既然是用來描述資料的存儲格式的，如果你不知道哪些資料未來會進入到我們來的redis中，那麼對應的資料類型的選擇，你就會出現問題，我們一塊來看一下：

（1）原始業務功能設計

秒殺。他這個裡邊資料變化速度特别的快，通路量也特别的高，使用者大量湧入以後都會針對着一部分資料進行操作，這一類要記住。

618活動。對于我們京東的618活動、以及天貓的雙11活動，相信大家不用說都知道這些資料一定要進去，因為他們的通路頻度實在太高了。

排隊購票。我們12306的票務資訊。這些資訊在原始設計的時候，他們就注定了要進redis。

（2）營運平台監控到的突發高頻通路資料

此類平台臨時監控到的這些資料，比如說現在出來的一個八卦的資訊，這個新聞一旦出現以後呢，順速的被圍觀了，那麼這個時候，這個資料就會變得訪量特别高，那麼這類資訊也要進入進去。

（3）高頻、複雜的統計資料

線上人數。比如說直播現在很火，直播裡邊有很多資料，例如線上人數。進一個人出一個人，這個資料就要跳動，那麼這個通路速度非常的快，而且訪量很高，并且它裡邊有一個複雜的資料統計，在這裡這種資訊也要進入到我們的redis中。

投票排行榜。投票投票類的資訊他的變化速度也比較快，為了追求一個更快的一個即時投票的名次變化，這種資料最好也放到redis中。

基于以上資料特征我們進行分析，最終得出來我們的Redis中要設計5種 資料類型：

string、hash、list、set、sorted_set/zset（應用性較低）

在學習第一個資料類型之前，先給大家介紹一下，在随後這部分内容的學習過程中，我們每一種資料類型都分成三塊來講：首先是講下它的基本操作，接下來講一些它的擴充操作，最後我們會去做一個小的案例分析。

在學習string這個資料形式之前，我們先要明白string到底是修飾什麼的。我們知道redis 自身是一個 Map，其中所有的資料都是采用 key : value 的形式存儲。

對于這種結構來說，我們用來存儲資料一定是一個值前面對應一個名稱。我們通過名稱來通路後面的值。按照這種形勢，我們可以對出來我們的存儲格式。前面這一部分我們稱為key。後面的一部分稱為value，而我們的資料類型，他一定是修飾value的。

[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-vlED5Lo4-1602588283687)(img\redis存儲空間.png)]

資料類型指的是存儲的資料的類型，也就是 value 部分的類型，key 部分永遠都是字元串。

（1）存儲的資料：單個資料，最簡單的資料存儲類型，也是最常用的資料存儲類型。

string，他就是存一個字元串兒，注意是value那一部分是一個字元串，它是redis中最基本、最簡單的存儲資料的格式。

（2）存儲資料的格式：一個存儲空間儲存一個資料

每一個空間中隻能儲存一個字元串資訊，這個資訊裡邊如果是存的純數字，他也能當數字使用，我們來看一下，這是我們的資料的存儲空間。

（3）存儲内容：通常使用字元串，如果字元串以整數的形式展示，可以作為數字操作使用.

[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-J1tKG91D-1602588283688)(img\redis存儲空間2.png)]

一個key對一個value，而這個itheima就是我們所說的string類型，當然它也可以是一個純數字的格式。

（1）基礎指令

添加/修改資料添加/修改資料

擷取資料

删除資料

判定性添加資料

添加/修改多個資料

擷取多個資料

擷取資料字元個數（字元串長度）

追加資訊到原始資訊後部（如果原始資訊存在就追加，否則建立）

（2）單資料操作與多資料操作的選擇之惑

即set 與mset的關系。這對于這兩個操作來說，沒有什麼你應該選哪個，而是他們自己的特征是什麼，你要根據這個特征去比對你的業務，看看究竟适用于哪個。

[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-gznhQ4aq-1602588283689)(img\set.png)]

假如說這是我們現在的伺服器，他要向redis要資料的話，它會發出一條指令。那麼當這條指令發過來的時候，比如說是這個set指令過來，那麼它會把這個結果傳回給你，這個時候我們要思考這裡邊一共經過了多長時間。

首先，發送set指令要時間，這是網絡的一個時間，接下來redis要去運作這個指令要消耗時間，最終把這個結果傳回給你又有一個時間，這個時間又是一個網絡的時間，那我們可以了解為：一個指令發送的過程中需要消耗這樣的時間.

但是如果說現在不是一條指令了，你要發3個set的話，還要多長時間呢？對應的發送時間要乘3了，因為這是三個單條指令,而運作的操作時間呢，它也要乘3了，但最終傳回的也要發3次，是以這邊也要乘3。

于是我們可以得到一個結論：單指令發3條它需要的時間，假定他們兩個一樣，是6個網絡時間加3個處理時間，如果我們把它合成一個mset呢，我們想一想。

假如說用多指令發3個指令的話，其實隻需要發一次就行了。這樣我們可以得到一個結論，多指令發3個指令的話，其實它是兩個網絡時間加上3個redis的操作時間，為什麼這寫一個小加号呢，就是因為畢竟發的資訊量變大了，是以網絡時間有可能會變長。

那麼通過這張圖，你就可以得到一個結論，我們單指令和多指令他們的差别就在于你發送的次數是多還是少。當你影響的資料比較少的時候，你可以用單指令，也可以用多指令。但是一旦這個量大了，你就要選擇多指令了，他的效率會高一些。

下面我們來看一string的擴充操作，分成兩大塊：一塊是對數字進行操作的，第二塊是對我們的key的時間進行操作的。

設定數值資料增加指定範圍的值

設定數值資料減少指定範圍的值

設定資料具有指定的生命周期

(1)資料操作不成功的回報與資料正常操作之間的差異

表示運作結果是否成功

(integer) 0 → false 失敗

(integer) 1 → true 成功

表示運作結果值

(integer) 3 → 3 3個

(integer) 1 → 1 1個

(2)資料未擷取到時，對應的資料為（nil），等同于null

(3)資料最大存儲量：512MB

(4)string在redis内部存儲預設就是一個字元串，當遇到增減類操作incr，decr時會轉成數值型進行計算

(5)按數值進行操作的資料，如果原始資料不能轉成數值，或超越了redis 數值上限範圍，将報錯

9223372036854775807（java中Long型資料最大值，Long.MAX_VALUE）

(6)redis所有的操作都是原子性的，采用單線程處理所有業務，指令是一個一個執行的，是以無需考慮并發帶來的資料影響.

它的應用場景在于：首頁高頻通路資訊顯示控制，例如新浪微網誌大V首頁顯示粉絲數與微網誌數量。

[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-vtu7u6qH-1602588283691)(img\string應用場景.png)]

我們來思考一下：這些資訊是不是你進入大V的頁面兒以後就要讀取這寫資訊的啊，那這種資訊一定要存儲到我們的redis中，因為他的通路量太高了！那這種資料應該怎麼存呢？我們來一塊兒看一下方案！

（1）在redis中為大V使用者設定使用者資訊，以使用者主鍵和屬性值作為key，背景設定定時重新整理政策即可。

（2）也可以使用json格式儲存資料

（3） key 的設定約定

資料庫中的熱點資料key命名慣例

表名

主鍵名

主鍵值

字段名

eg1：

order

id

29437595

name

eg2：

equip

390472345

type

eg3：

news

202004150

title

下面我們來學習第二個資料類型hash。

對象類資料的存儲如果具有較頻繁的更新需求操作會顯得笨重！

在正式學習之前，我們先來看一個關于資料存儲的困惑：

[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-8aof3xe4-1602588283692)(img\hash存儲.png)]

比如說前面我們用以上形式存了資料，如果我們用單條去存的話，它存的條數會很多。但如果我們用json格式，它存一條資料就夠了。問題來了，假如說現在粉絲數量發生變化了，你要把整個值都改了。但是用單條存的話就不存在這個問題，你隻需要改其中一個就行了。這個時候我們就想，有沒有一種新的存儲結構，能幫我們解決這個問題呢。

我們一塊兒來分析一下：

[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-0OYBMpJ4-1602588283694)(img\資料.png)]

如上圖所示：單條的話是對應的資料在後面放着。仔細觀察：我們看左邊是不是長得都一模一樣啊，都是對應的表名、ID等的一系列的東西。我們可以将右邊紅框中的這個區域給他封起來。

那如果要是這樣的形式的話，如下圖，我們把它一合并，并把右邊的東西給他變成這個格式，這不就行了嗎？

[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-6bDy9RhF-1602588283696)(img\hash資料.png)]

這個圖其實大家并不陌生，第一，你前面學過一個東西叫hashmap不就這格式嗎？第二，redis自身不也是這格式嗎？那是什麼意思呢？注意，這就是我們要講的第二種格式，hash。

[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-oq5MD1Zs-1602588283697)(img\hash結構.png)]

在右邊對應的值，我們就存具體的值，那左邊兒這就是我們的key。問題來了，那中間的這一塊叫什麼呢？這個東西我們給他起個名兒，叫做field字段。那麼右邊兒整體這塊兒空間我們就稱為hash，也就是說hash是存了一個key value的存儲空間。

新的存儲需求：對一系列存儲的資料進行編組，友善管理，典型應用存儲對象資訊

需要的存儲結構：一個存儲空間儲存多個鍵值對資料

hash類型：底層使用哈希表結構實作資料存儲

[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-OcjTCpDG-1602588283698)(img\hash結構圖.png)]

如上圖所示，這種結構叫做hash，左邊一個key，對右邊一個存儲空間。這裡要明确一點，右邊這塊兒存儲空間叫hash，也就是說hash是指的一個資料類型，他指的不是一個資料，是這裡邊的一堆資料，那麼它底層呢，是用hash表的結構來實作的。

值得注意的是：

如果field數量較少，存儲結構優化為類數組結構

如果field數量較多，存儲結構使用HashMap結構

添加/修改資料

設定field的值，如果該field存在則不做任何操作

擷取哈希表中字段的數量

擷取哈希表中是否存在指定的字段

在看完hash的基本操作後，我們再來看他的拓展操作，他的拓展操作相對比較簡單：

擷取哈希表中所有的字段名或字段值

設定指定字段的數值資料增加指定範圍的值

(1)hash類型中value隻能存儲字元串，不允許存儲其他資料類型，不存在嵌套現象。如果資料未擷取到，對應的值為（nil）。

(2）每個 hash 可以存儲 232 - 1 個鍵值對

hash類型十分貼近對象的資料存儲形式，并且可以靈活添加删除對象屬性。但hash設計初衷不是為了存儲大量對象而設計 的，切記不可濫用，更不可以将hash作為對象清單使用。

(3)hgetall 操作可以擷取全部屬性，如果内部field過多，周遊整體資料效率就很會低，有可能成為資料通路瓶頸。

雙11活動日，銷售手機儲值卡的商家對移動、聯通、電信的30元、50元、100元商品推出搶購活動，每種商品搶購上限1000 張。

[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-QSbtS0qM-1602588283700)(img\hash應用.png)]

也就是商家有了，商品有了，數量有了。最終我們的使用者買東西就是在改變這個數量。那你說這個結構應該怎麼存呢？對應的商家的ID作為key，然後這些儲值卡的ID作為field，最後這些數量作為value。而我們所謂的操作是其實就是increa這個操作，隻不過你傳負值就行了。看一看對應的解決方案：

以商家id作為key

将參與搶購的商品id作為field

将參與搶購的商品數量作為對應的value

搶購時使用降值的方式控制産品數量

注意：實際業務中還有超賣等實際問題，這裡不做讨論

前面我們存資料的時候呢，單個資料也能存，多個資料也能存，但是這裡面有一個問題，我們存多個資料用hash的時候它是沒有順序的。我們平時操作，實際上資料很多情況下都是有順序的，那有沒有一種能夠用來存儲帶有順序的這種資料模型呢，list就專門來幹這事兒。

資料存儲需求：存儲多個資料，并對資料進入存儲空間的順序進行區分

需要的存儲結構：一個存儲空間儲存多個資料，且通過資料可以展現進入順序

list類型：儲存多個資料，底層使用雙向連結清單存儲結構實作

先來通過一張圖，回憶一下順序表、連結清單、雙向連結清單。

[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-76HFiAoX-1602588283702)(img\list1.png)]

list對應的存儲結構是什麼呢？裡邊存的這個東西是個清單，他有一個對應的名稱。就是key存一個list的這樣結構。對應的基本操作，你其實是可以想到的。

[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-sKSb3PkP-1602588283703)(img\list2.png)]

來看一下，因為它是雙向的，是以他左邊右邊都能操作，它對應的操作結構兩邊都能進資料。這就是連結清單的一個存儲結構。往外拿資料的時候怎麼拿呢？通常是從一端拿，當然另一端也能拿。如果兩端都能拿的話，這就是個雙端隊列，兩邊兒都能操作。如果隻能從一端進一端出，這個模型咱們前面了解過，叫做棧。

最後看一下他的基本操作

擷取并移除資料

移除指定資料

規定時間内擷取并移除資料

（1）list中儲存的資料都是string類型的，資料總容量是有限的，最多232 - 1 個元素(4294967295)。

（2）list具有索引的概念，但是操作資料時通常以隊列的形式進行入隊出隊操作，或以棧的形式進行入棧出棧操作

（3）擷取全部資料操作結束索引設定為-1

（4）list可以對資料進行分頁操作，通常第一頁的資訊來自于list，第2頁及更多的資訊通過資料庫的形式加載

企業營運過程中，系統将産生出大量的營運資料，如何保障多台伺服器記錄檔的統一順序輸出？

[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-em0mdOC1-1602588283704)(img\list應用.png)]

假如現在你有多台伺服器，每一台伺服器都會産生它的日志，假設你是一個運維人員，你想看它的記錄檔，你怎麼看呢？打開A機器的日志看一看，打開B機器的日志再看一看嗎？這樣的話你會可能會瘋掉的！因為左邊看的有可能它的時間是11:01，右邊11:02，然後再看左邊11:03，它們本身是連續的，但是你在看的時候就分成四個檔案了，這個時候你看起來就會很麻煩。能不能把他們合并呢？答案是可以的！怎麼做呢？建立起redis伺服器。當他們需要記日志的時候，記在哪兒,全部發給redis。等到你想看的時候，通過伺服器通路redis擷取日志。然後得到以後，就會得到一個完整的日志資訊。那麼這裡面就可以擷取到完整的日志了，依靠什麼來實作呢？就依靠我們的list的模型的順序來實作。進來一組資料就往裡加，誰先進來誰先加進去，它是有一定的順序的。

依賴list的資料具有順序的特征對資訊進行管理

使用隊列模型解決多路資訊彙總合并的問題

使用棧模型解決最新消息的問題

新的存儲需求：存儲大量的資料，在查詢方面提供更高的效率

需要的存儲結構：能夠儲存大量的資料，高效的内部存儲機制，便于查詢

set類型：與hash存儲結構完全相同，僅存儲鍵，不存儲值（nil），并且值是不允許重複的

[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-88UApSWB-1602588283706)(img\set模型.png)]

通過這個名稱，大家也基本上能夠認識到和我們Java中的set完全一樣。我們現在要存儲大量的資料，并且要求提高它的查詢效率。用list這種連結清單形式，它的查詢效率是不高的，那怎麼辦呢？這時候我們就想，有沒有高效的存儲機制。其實前面咱講Java的時候說過hash表的結構就非常的好，但是這裡邊我們已經有hash了，他做了這麼一個設定，幹嘛呢，他把hash的存儲空間給改一下，右邊你原來存資料改掉,全部存空，那你說資料放哪兒了？放到原來的filed的位置，也就在這裡邊存真正的值，那麼這個模型就是我們的set 模型。

set類型：與hash存儲結構完全相同，僅存儲鍵，不存儲值（nil），并且值是不允許重複的。

看一下它的整個結構：

[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-U5UxLYXK-1602588283707)(img\set4.png)]

添加資料

擷取全部資料

擷取集合資料總量

判斷集合中是否包含指定資料

随機擷取集合中指定數量的資料

随機擷取集中的某個資料并将該資料移除集合

求兩個集合的交、并、差集

求兩個集合的交、并、差集并存儲到指定集合中

将指定資料從原始集合中移動到目标集合中

通過下面一張圖回憶一下交、并、差

[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-B3Vys0CS-1602588283709)(img\交并差.png)]

set 類型不允許資料重複，如果添加的資料在 set 中已經存在，将隻保留一份。

set 雖然與hash的存儲結構相同，但是無法啟用hash中存儲值的空間。

（1）黑名單

資訊類資訊類網站追求高通路量，但是由于其資訊的價值，往往容易被不法分子利用，通過爬蟲技術， 快速擷取資訊，個别特種行業網站資訊通過爬蟲擷取分析後，可以轉換成商業機密進行出售。例如第三方火 車票、機票、酒店刷票代購軟體，電商刷評論、刷好評。

同時爬蟲帶來的僞流量也會給經營者帶來錯覺，産生錯誤的決策，有效避免網站被爬蟲反複爬取成為每個網站都要考慮的基本問題。在基于技術層面區分出爬蟲使用者後，需要将此類使用者進行有效的屏蔽，這就是黑名單的典型應用。

ps:不是說爬蟲一定做摧毀性的工作，有些小型網站需要爬蟲為其帶來一些流量。

（2）白名單

對于安全性更高的應用通路，僅僅靠黑名單是不能解決安全問題的，此時需要設定可通路的使用者群體， 依賴白名單做更為苛刻的通路驗證。

基于經營戰略設定問題使用者發現、鑒别規則

周期性更新滿足規則的使用者黑名單，加入set集合

使用者行為資訊達到後與黑名單進行比對，确認行為去向

黑名單過濾IP位址：應用于開放遊客通路權限的資訊源

黑名單過濾裝置資訊：應用于限定通路裝置的資訊源

黑名單過濾使用者：應用于基于通路權限的資訊源

使用微信的過程中，當微信接收消息後，會預設将最近接收的消息置頂，當多個好友及關注的訂閱号同時發 送消息時，該排序會不停的進行交替。同時還可以将重要的會話設定為置頂。一旦使用者離線後，再次打開微信時，消息該按照什麼樣的順序顯示。

我們分析一下：

[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-9jDD4mPK-1602588283711)(img\set案例.png)]

100這台手機代表你。而200、300、400這三台代表你好友的手機。在這裡有一些東西需要交代一下，因為我們每個人的都會對自己的微信中的一些比較重要的人設定會話置頂，将他的那條對話放在最上面。我們假定這個人有兩個會話置頂的好友，分别是400和500，而這裡邊就包含400.

下面呢，我們就來發這個消息，第一個發消息的是300，他發了個消息給100。發完以後，這個東西應該怎麼存儲呢？在這裡面一定要分開，記錄置頂的這些人的會話，對應的會話顯示順序和非置頂的一定要分兩。

這裡面我們建立兩個模型，一個是普通的，一個是置頂的，而上面的這個置頂的使用者呢，我們用set來存儲，因為不重複。而下面這些因為有順序，很容易想到用list去存儲,不然你怎麼表達順序呢？

[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-wA9v5ZYk-1602588283712)(img\300.png)]

那當300發給消息給100以後，這個時候我們先判定你在置頂人群中嗎？不在,那好，300的消息對應的順序就應該放在普通的清單裡邊。而在這裡邊，我們把300加進去。第一個資料也就是現在300。

[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-rl78AcMi-1602588283713)(img\400.png)]

接下來400，發了個消息。判斷一下，他是需要置頂的，是以400将進入list的置頂裡邊放着。目前還沒有特殊的地方。

[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-iZj0dj5S-1602588283715)(img\200.png)]

再來200發消息了，和剛才的判定方法一樣，先看在不在置頂裡，不在的話進普通，然後在普通裡邊把200加入就行了，OK，到這裡目前還沒有順序變化。

接下來200又發消息過來，同一個人給你連發了兩條，那這個時候200的消息到達以後，先判斷是否在置頂範圍，不在，接下來他要放在list普通中，這裡你要注意一點，因為這裡邊已經有200，是以進來以後先幹一件事兒，把200殺掉，沒有200，然後再把200加進來，那你想一下，現在這個位置順序是什麼呢？就是新的都在右邊，對不對？

還記得我們說list模型，如果是一個雙端隊列，它是可以兩頭進兩頭出。當然我們雙端從一頭進一頭出，這就是棧模型，現在咱們運用的就是list模型中的棧模型。

[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-HpManXao-1602588283716)(img\3002.png)]

現在300發消息，先判定他在不在，不在，用普通的隊列，接下來按照剛才的操作，不管你裡邊原來有沒有300，我先把300殺掉，沒了，200自然就填到300的位置了，他現在是list裡面唯一一個，然後讓300進來，注意是從右側進來的，那麼現在300就是最新的。

[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-JeDAQoDr-1602588283718)(img\分析.png)]

那麼到這裡呢，我們讓100來讀取消息。你覺得這個消息順序應該是什麼樣的？首先置頂的400有一個，他跑在最上面，然後list普通如果出來的話，300是最新的消息，而200在他後面的。用這種形式，我們就可以做出來他的消息順序來。

看一下最終的解決方案：

依賴list的資料具有順序的特征對消息進行管理，将list結構作為棧使用

置頂與普通會話分别建立獨立的list分别管理

當某個list中接收到使用者消息後，将消息發送方的id從list的一側加入list（此處設定左側）

多個相同id發出的消息反複入棧會出現問題，在入棧之前無論是否具有目前id對應的消息，先删除對應id

推送消息時先推送置頂會話list，再推送普通會話list，推送完成的list清除所有資料

消息的數量，也就是微信使用者對話數量采用計數器的思想另行記錄，伴随list操作同步更新

總結一下，在整個資料類型的部分，我們主要介紹了哪些内容：

首先我們了解了一下資料類型，接下來針對着我們要學習的資料類型，進行逐一講解了string、hash、list、set等，最後通過一個案例總結了一下前面的資料類型的使用場景。