[[263444]]

是數(shù)據(jù)結構而非類型

很多文章都會說，redis支持5種常用的數(shù)據(jù)類型，這其實是存在很大的歧義。redis里存的都是二進制數(shù)據(jù)，其實就是字節(jié)數(shù)組(byte[])，這些字節(jié)數(shù)據(jù)是沒有數(shù)據(jù)類型的，只有把它們按照合理的格式解碼后，可以變成一個字符串，整數(shù)或對象，此時才具有數(shù)據(jù)類型。

這一點必須要記住。所以任何東西只要能轉化成字節(jié)數(shù)組(byte[])的，都可以存到redis里。管你是字符串、數(shù)字、對象、圖片、聲音、視頻、還是文件，只要變成byte數(shù)組。

因此redis里的String指的并不是字符串，它其實表示的是一種最簡單的數(shù)據(jù)結構，即一個key只能對應一個value。這里的key和value都是byte數(shù)組，只不過key一般是由一個字符串轉換成的byte數(shù)組，value則根據(jù)實際需要而定。

在特定情況下，對value也會有一些要求，比如要進行自增或自減操作，那value對應的byte數(shù)組必須要能被解碼成一個數(shù)字才行，否則會報錯。

那么List這種數(shù)據(jù)結構，其實表示一個key可以對應多個value，且value之間是有先后順序的，value值可以重復。

Set這種數(shù)據(jù)結構，表示一個key可以對應多個value，且value之間是沒有先后順序的，value值也不可以重復。

Hash這種數(shù)據(jù)結構，表示一個key可以對應多個key-value對，此時這些key-value對之間的先后順序一般意義不大，這是一個按照名稱語義來訪問的數(shù)據(jù)結構，而非位置語義。

Sorted Set這種數(shù)據(jù)結構，表示一個key可以對應多個value，value之間是有大小排序的，value值不可以重復。每個value都和一個浮點數(shù)相關聯(lián)，該浮點數(shù)叫score。元素排序規(guī)則是：先按score排序，再按value排序。

相信現(xiàn)在你對這5種數(shù)據(jù)結構有了更清晰的認識，那它們的對應命令對你來說就是小case了。

集群帶來的問題與解決思路

集群帶來的好處是顯而易見的，比如容量增加、處理能力增強，還可以按需要進行動態(tài)的擴容、縮容。但同時也會引入一些新的問題，至少會有下面這兩個。

一是數(shù)據(jù)分配：存數(shù)據(jù)時應該放到哪個節(jié)點上，取數(shù)據(jù)時應該去哪個節(jié)點上找。二是數(shù)據(jù)移動：集群擴容，新增加節(jié)點時，該節(jié)點上的數(shù)據(jù)從何處來;集群縮容，要剔除節(jié)點時，該節(jié)點上的數(shù)據(jù)往何處去。

上面這兩個問題有一個共同點就是，如何去描述和存儲數(shù)據(jù)與節(jié)點的映射關系。又因為數(shù)據(jù)的位置是由key決定的，所以問題就演變?yōu)槿绾谓⑵鸶鱾€key和集群所有節(jié)點的關聯(lián)關系。

集群的節(jié)點是相對固定和少數(shù)的，雖然有增加節(jié)點和剔除節(jié)點。但集群里存儲的key，則是完全隨機、沒有規(guī)律、不可預測、數(shù)量龐多，還非?，嵥?。

這就好比一所大學和它的所有學生之間的關系。如果大學和學生直接掛鉤的話，一定會比較混亂?，F(xiàn)實是它們之間又加入了好幾層，首先有院系，其次有專業(yè)，再者有年級，***還有班級。經過這四層映射之后，關系就清爽很多了。

這其實是一個非常重要的結論，這個世界上沒有什么問題是不能通過加入一層來解決的。如果有，那就再加入一層。計算機里也是這樣的。

redis在數(shù)據(jù)和節(jié)點之間又加入了一層，把這層稱為槽(slot)，因該槽主要和哈希有關，又叫哈希槽。

***變成了，節(jié)點上放的是槽，槽里放的是數(shù)據(jù)。槽解決的是粒度問題，相當于把粒度變大了，這樣便于數(shù)據(jù)移動。哈希解決的是映射問題，使用key的哈希值來計算所在的槽，便于數(shù)據(jù)分配。

可以這樣來理解，你的學習桌子上堆滿了書，亂的很，想找到某本書非常困難。于是你買了幾個大的收納箱，把這些書按照書名的長度放入不同的收納箱，然后把這些收納箱放到桌子上。

這樣就變成了，桌子上是收納箱，收納箱里是書籍。這樣書籍移動很方便，搬起一個箱子就走了。尋找書籍也很方便，只要數(shù)一數(shù)書名的長度，去對應的箱子里找就行了。

其實我們也沒做什么，只是買了幾個箱子，按照某種規(guī)則把書裝入箱子。就這么簡單的舉動，就徹底改變了原來一盤散沙的狀況。是不是有點小小的神奇呢。

一個集群只能有16384個槽，編號0-16383。這些槽會分配給集群中的所有主節(jié)點，分配策略沒有要求。可以指定哪些編號的槽分配給哪個主節(jié)點。集群會記錄節(jié)點和槽的對應關系。

接下來就需要對key求哈希值，然后對16384取余，余數(shù)是幾key就落入對應的槽里。slot = CRC16(key) % 16384。

以槽為單位移動數(shù)據(jù)，因為槽的數(shù)目是固定的，處理起來比較容易，這樣數(shù)據(jù)移動問題就解決了。

使用哈希函數(shù)計算出key的哈希值，這樣就可以算出它對應的槽，然后利用集群存儲的槽和節(jié)點的映射關系查詢出槽所在的節(jié)點，于是數(shù)據(jù)和節(jié)點就映射起來了，這樣數(shù)據(jù)分配問題就解決了。

我想說的是，一般的人只會去學習各種技術，高手更在乎如何跳出技術，尋求一種解決方案或思路方向，順著這個方向走下去，八九不離十能找到你想要的答案。

集群對命令操作的取舍

客戶端只要和集群中的一個節(jié)點建立鏈接后，就可以獲取到整個集群的所有節(jié)點信息。此外還會獲取所有哈希槽和節(jié)點的對應關系信息，這些信息數(shù)據(jù)都會在客戶端緩存起來，因為這些信息相當有用。

客戶端可以向任何節(jié)點發(fā)送請求，那么拿到一個key后到底該向哪個節(jié)點發(fā)請求呢?其實就是把集群里的那套key和節(jié)點的映射關系理論搬到客戶端來就行了。

所以客戶端需要實現(xiàn)一個和集群端一樣的哈希函數(shù)，先計算出key的哈希值，然后再對16384取余，這樣就找到了該key對應的哈希槽，利用客戶端緩存的槽和節(jié)點的對應關系信息，就可以找到該key對應的節(jié)點了。

接下來發(fā)送請求就可以了。還可以把key和節(jié)點的映射關系緩存起來，下次再請求該key時，直接就拿到了它對應的節(jié)點，不用再計算一遍了。

理論和現(xiàn)實總是有差距的，集群已經發(fā)生了變化，客戶端的緩存還沒來得及更新?？隙〞霈F(xiàn)拿到一個key向對應的節(jié)點發(fā)請求，其實這個key已經不在那個節(jié)點上了。此時這個節(jié)點應該怎么辦?

這個節(jié)點可以去key實際所在的節(jié)點上拿到數(shù)據(jù)再返回給客戶端，也可以直接告訴客戶端key已經不在我這里了，同時附上key現(xiàn)在所在的節(jié)點信息，讓客戶端再去請求一次，類似于HTTP的302重定向。

這其實是個選擇問題，也是個哲學問題。結果就是redis集群選擇了后者。因此，節(jié)點只處理自己擁有的key，對于不擁有的key將返回重定向錯誤，即-MOVED key 127.0.0.1:6381，客戶端重新向這個新節(jié)點發(fā)送請求。

所以說選擇是一種哲學，也是個智慧。稍后再談這個問題。先來看看另一個情況，和這個問題有些相同點。

redis有一種命令可以一次帶多個key，如MGET，我把這些稱為多key命令。這個多key命令的請求被發(fā)送到一個節(jié)點上，這里有一個潛在的問題，不知道大家有沒有想到，就是這個命令里的多個key一定都位于那同一個節(jié)點上嗎?

就分為兩種情況了，如果多個key不在同一個節(jié)點上，此時節(jié)點只能返回重定向錯誤了，但是多個key完全可能位于多個不同的節(jié)點上，此時返回的重定向錯誤就會非常亂，所以redis集群選擇不支持此種情況。

如果多個key位于同一個節(jié)點上呢，理論上是沒有問題的，redis集群是否支持就和redis的版本有關系了，具體使用時自己測試一下就行了。

在這個過程中我們發(fā)現(xiàn)了一件頗有意義的事情，就是讓一組相關的key映射到同一個節(jié)點上是非常有必要的，這樣可以提高效率，通過多key命令一次獲取多個值。

那么問題來了，如何給這些key起名字才能讓他們落到同一個節(jié)點上，難不成都要先計算個哈希值，再取個余數(shù)，太麻煩了吧。當然不是這樣了，redis已經幫我們想好了。

可以來簡單推理下，要想讓兩個key位于同一個節(jié)點上，它們的哈希值必須要一樣。要想哈希值一樣，傳入哈希函數(shù)的字符串必須一樣。那我們只能傳進去兩個一模一樣的字符串了，那不就變成同一個key了，后面的會覆蓋前面的數(shù)據(jù)。

這里的問題是我們都是拿整個key去計算哈希值，這就導致key和參與計算哈希值的字符串耦合了，需要將它們解耦才行，就是key和參與計算哈希值的字符串有關但是又不一樣。

redis基于這個原理為我們提供了方案，叫做key哈希標簽。先看例子，{user1000}.following，{user1000}.followers，相信你已經看出了門道，就是僅使用Key中的位于{和}間的字符串參與計算哈希值。

這樣可以保證哈希值相同，落到相同的節(jié)點上。但是key又是不同的，不會互相覆蓋。使用哈希標簽把一組相關的key關聯(lián)了起來，問題就這樣被輕松愉快地解決了。

相信你已經發(fā)現(xiàn)了，要解決問題靠的是巧妙的奇思妙想，而不是非要用牛逼的技術牛逼的算法。這就是小強，小而強大。

***再來談選擇的哲學。redis的核心就是以最快的速度進行常用數(shù)據(jù)結構的key/value存取，以及圍繞這些數(shù)據(jù)結構的運算。對于與核心無關的或會拖累核心的都選擇弱化處理或不處理，這樣做是為了保證核心的簡單、快速和穩(wěn)定。

其實就是在廣度和深度面前，redis選擇了深度。所以節(jié)點不去處理自己不擁有的key，集群不去支持多key命令。這樣一方面可以快速地響應客戶端，另一方面可以避免在集群內部有大量的數(shù)據(jù)傳輸與合并。

單線程模型

redis集群的每個節(jié)點里只有一個線程負責接受和執(zhí)行所有客戶端發(fā)送的請求。技術上使用多路復用I/O，使用Linux的epoll函數(shù)，這樣一個線程就可以管理很多socket連接。

除此之外，選擇單線程還有以下這些原因：

1、redis都是對內存的操作，速度極快(10W+QPS)

2、整體的時間主要都是消耗在了網(wǎng)絡的傳輸上

3、如果使用了多線程，則需要多線程同步，這樣實現(xiàn)起來會變的復雜

4、線程的加鎖時間甚至都超過了對內存操作的時間

5、多線程上下文頻繁的切換需要消耗更多的CPU時間

6、還有就是單線程天然支持原子操作，而且單線程的代碼寫起來更簡單

事務

事務大家都知道，就是把多個操作捆綁在一起，要么都執(zhí)行(成功了)，要么一個也不執(zhí)行(回滾了)。redis也是支持事務的，但可能和你想要的不太一樣，一起來看看吧。

redis的事務可以分為兩步，定義事務和執(zhí)行事務。使用multi命令開啟一個事務，然后把要執(zhí)行的所有命令都依次排上去。這就定義好了一個事務。此時使用exec命令來執(zhí)行這個事務，或使用discard命令來放棄這個事務。

你可能希望在你的事務開始前，你關心的key不想被別人操作，那么可以使用watch命令來監(jiān)視這些key，如果開始執(zhí)行前這些key被其它命令操作了則會取消事務的。也可以使用unwatch命令來取消對這些key的監(jiān)視。

redis事務具有以下特點：

1、如果開始執(zhí)行事務前出錯，則所有命令都不執(zhí)行

2、一旦開始，則保證所有命令一次性按順序執(zhí)行完而不被打斷

3、如果執(zhí)行過程中遇到錯誤，會繼續(xù)執(zhí)行下去，不會停止的

4、對于執(zhí)行過程中遇到錯誤，是不會進行回滾的

看完這些，真想問一句話，你這能叫事務嗎?很顯然，這并不是我們通常認為的事務，因為它連原子性都保證不了。保證不了原子性是因為redis不支持回滾，不過它也給出了不支持的理由。

不支持回滾的理由：

1、redis認為，失敗都是由命令使用不當造成

2、redis這樣做，是為了保持內部實現(xiàn)簡單快速

3、redis還認為，回滾并不能解決所有問題

哈哈，這就是霸王條款，因此，好像使用redis事務的不太多

管道

客戶端和集群的交互過程是串行化阻塞式的，即客戶端發(fā)送了一個命令后必須等到響應回來后才能發(fā)第二個命令，這一來一回就是一個往返時間。如果你有很多的命令，都這樣一個一個的來進行，會變得很慢。

redis提供了一種管道技術，可以讓客戶端一次發(fā)送多個命令，期間不需要等待服務器端的響應，等所有的命令都發(fā)完了，再依次接收這些命令的全部響應。這就極大地節(jié)省了許多時間，提升了效率。

聰明的你是不是意識到了另外一個問題，多個命令就是多個key啊，這不就是上面提到的多key操作嘛，那么問題來了，你如何保證這多個key都是同一個節(jié)點上的啊，哈哈，redis集群又放棄了對管道的支持。

不過可以在客戶端模擬實現(xiàn)，就是使用多個連接往多個節(jié)點同時發(fā)送命令，然后等待所有的節(jié)點都返回了響應，再把它們按照發(fā)送命令的順序整理好，返回給用戶代碼。哎呀，好麻煩呀。

協(xié)議

簡單了解下redis的協(xié)議，知道redis的數(shù)據(jù)傳輸格式。

發(fā)送請求的協(xié)議：

*參數(shù)個數(shù)CRLF$參數(shù)1的字節(jié)數(shù)CRLF參數(shù)1的數(shù)據(jù)CRLF...$參數(shù)N的字節(jié)數(shù)CRLF參數(shù)N的數(shù)據(jù)CRLF

例如，SET name lixinjie，實際發(fā)送的數(shù)據(jù)是：

*3\r\n$3\r\nSET\r\n$4\r\nname\r\n$8\r\nlixinjie\r\n

接受響應的協(xié)議：

單行回復，***個字節(jié)是+

錯誤消息，***個字節(jié)是-

整型數(shù)字，***個字節(jié)是:

批量回復，***個字節(jié)是$

多個批量回復，***個字節(jié)是*

例如，

+OK\r\n

-ERR Operation against\r\n

:1000\r\n

$6\r\nfoobar\r\n

*2\r\n$3\r\nfoo\r\n$3\r\nbar\r\n

可見redis的協(xié)議設計的非常簡單。