是數(shù)據(jù)結(jié)構(gòu)而非類型
很多文章都會(huì)說贪磺，redis支持5種常用的 數(shù)據(jù)類型 ，這其實(shí)是存在很大的歧義诅愚。redis里存的都是二進(jìn)制數(shù)據(jù)缘挽，其實(shí)就是字節(jié)數(shù)組（byte[]），這些字節(jié)數(shù)據(jù)是沒有數(shù)據(jù)類型的呻粹，只有把它們按照合理的格式解碼后壕曼，可以變成一個(gè)字符串，整數(shù)或?qū)ο蟮茸牵藭r(shí)才具有數(shù)據(jù)類型腮郊。
這一點(diǎn)必須要記住。所以任何東西只要能轉(zhuǎn)化成字節(jié)數(shù)組（byte[]）的筹燕，都可以存到redis里轧飞。管你是字符串衅鹿、數(shù)字、對(duì)象过咬、圖片大渤、聲音、視頻掸绞、還是文件泵三，只要變成byte數(shù)組。
因此redis里的String指的并不是字符串衔掸，它其實(shí)表示的是一種最簡單的數(shù)據(jù)結(jié)構(gòu)烫幕，即一個(gè)key只能對(duì)應(yīng)一個(gè)value。這里的key和value都是byte數(shù)組敞映，只不過key一般是由一個(gè)字符串轉(zhuǎn)換成的byte數(shù)組较曼，value則根據(jù)實(shí)際需要而定。
進(jìn)群：697699179可以獲取Java各類入門學(xué)習(xí)資料振愿！
這是我的微信公眾號(hào)【編程study】各位大佬有空可以關(guān)注下捷犹，每天更新Java學(xué)習(xí)方法，感謝冕末！
學(xué)習(xí)中遇到問題有不明白的地方伏恐，推薦加小編Java學(xué)習(xí)群：697699179內(nèi)有視頻教程 ，直播課程 栓霜，等學(xué)習(xí)資料翠桦，期待你的加入
在特定情況下，對(duì)value也會(huì)有一些要求胳蛮，比如要進(jìn)行自增或自減操作销凑，那value對(duì)應(yīng)的byte數(shù)組必須要能被解碼成一個(gè)數(shù)字才行，否則會(huì)報(bào)錯(cuò)仅炊。
那么List這種數(shù)據(jù)結(jié)構(gòu)斗幼，其實(shí)表示一個(gè)key可以對(duì)應(yīng)多個(gè)value，且value之間是有先后順序的抚垄，value值可以重復(fù)蜕窿。
Set這種數(shù)據(jù)結(jié)構(gòu)，表示一個(gè)key可以對(duì)應(yīng)多個(gè)value呆馁，且value之間是沒有先后順序的桐经，value值也不可以重復(fù)。
Hash這種數(shù)據(jù)結(jié)構(gòu)浙滤，表示一個(gè)key可以對(duì)應(yīng)多個(gè)key-value對(duì)阴挣，此時(shí)這些key-value對(duì)之間的先后順序一般意義不大，這是一個(gè)按照名稱語義來訪問的數(shù)據(jù)結(jié)構(gòu)纺腊，而非位置語義畔咧。
Sorted Set這種數(shù)據(jù)結(jié)構(gòu)茎芭，表示一個(gè)key可以對(duì)應(yīng)多個(gè)value，value之間是有大小排序的誓沸，value值不可以重復(fù)梅桩。每個(gè)value都和一個(gè)浮點(diǎn)數(shù)相關(guān)聯(lián)，該浮點(diǎn)數(shù)叫score拜隧。元素排序規(guī)則是：先按score排序宿百，再按value排序。
相信現(xiàn)在你對(duì)這5種數(shù)據(jù)結(jié)構(gòu)有了更清晰的認(rèn)識(shí)虹蓄，那它們的對(duì)應(yīng)命令對(duì)你來說就是小case了。
集群帶來的問題與解決思路
集群帶來的好處是顯而易見的幸撕，比如容量增加薇组、處理能力增強(qiáng)，還可以按需要進(jìn)行動(dòng)態(tài)的擴(kuò)容坐儿、縮容律胀。但同時(shí)也會(huì)引入一些新的問題，至少會(huì)有下面這兩個(gè)貌矿。
一是數(shù)據(jù)分配：存數(shù)據(jù)時(shí)應(yīng)該放到哪個(gè)節(jié)點(diǎn)上炭菌，取數(shù)據(jù)時(shí)應(yīng)該去哪個(gè)節(jié)點(diǎn)上找。二是數(shù)據(jù)移動(dòng)：集群擴(kuò)容逛漫，新增加節(jié)點(diǎn)時(shí)黑低，該節(jié)點(diǎn)上的數(shù)據(jù)從何處來；集群縮容酌毡，要剔除節(jié)點(diǎn)時(shí)克握，該節(jié)點(diǎn)上的數(shù)據(jù)往何處去。
上面這兩個(gè)問題有一個(gè)共同點(diǎn)就是枷踏，如何去描述和存儲(chǔ)數(shù)據(jù)與節(jié)點(diǎn)的映射關(guān)系菩暗。又因?yàn)閿?shù)據(jù)的位置是由key決定的，所以問題就演變?yōu)槿绾谓⑵鸶鱾€(gè)key和集群所有節(jié)點(diǎn)的關(guān)聯(lián)關(guān)系旭蠕。
集群的節(jié)點(diǎn)是相對(duì)固定和少數(shù)的停团，雖然有增加節(jié)點(diǎn)和剔除節(jié)點(diǎn)。但集群里存儲(chǔ)的key掏熬，則是完全隨機(jī)佑稠、沒有規(guī)律、不可預(yù)測(cè)旗芬、數(shù)量龐多讶坯，還非常瑣碎岗屏。
這就好比一所大學(xué)和它的所有學(xué)生之間的關(guān)系辆琅。如果大學(xué)和學(xué)生直接掛鉤的話漱办，一定會(huì)比較混亂。現(xiàn)實(shí)是它們之間又加入了好幾層婉烟，首先有院系娩井，其次有專業(yè)，再者有年級(jí)似袁，最后還有班級(jí)洞辣。經(jīng)過這四層映射之后，關(guān)系就清爽很多了昙衅。
這其實(shí)是一個(gè)非常重要的結(jié)論扬霜，這個(gè)世界上沒有什么問題是不能通過加入一層來解決的。如果有而涉，那就再加入一層著瓶。計(jì)算機(jī)里也是這樣的。
redis在數(shù)據(jù)和節(jié)點(diǎn)之間又加入了一層啼县，把這層稱為槽（slot）材原，因該槽主要和哈希有關(guān)，又叫哈希槽季眷。
最后變成了余蟹，節(jié)點(diǎn)上放的是槽，槽里放的是數(shù)據(jù)子刮。槽解決的是粒度問題威酒，相當(dāng)于把粒度變大了，這樣便于數(shù)據(jù)移動(dòng)挺峡。哈希解決的是映射問題兼搏，使用key的哈希值來計(jì)算所在的槽，便于數(shù)據(jù)分配沙郭。
可以這樣來理解佛呻，你的學(xué)習(xí)桌子上堆滿了書，亂的很病线，想找到某本書非常困難吓著。于是你買了幾個(gè)大的收納箱，把這些書按照書名的長度放入不同的收納箱送挑，然后把這些收納箱放到桌子上绑莺。
這樣就變成了，桌子上是收納箱惕耕，收納箱里是書籍纺裁。這樣書籍移動(dòng)很方便，搬起一個(gè)箱子就走了。尋找書籍也很方便欺缘，只要數(shù)一數(shù)書名的長度栋豫，去對(duì)應(yīng)的箱子里找就行了。
其實(shí)我們也沒做什么谚殊，只是買了幾個(gè)箱子丧鸯，按照某種規(guī)則把書裝入箱子。就這么簡單的舉動(dòng)嫩絮，就徹底改變了原來一盤散沙的狀況丛肢。是不是有點(diǎn)小小的神奇呢。
一個(gè)集群只能有16384個(gè)槽剿干，編號(hào)0-16383蜂怎。這些槽會(huì)分配給集群中的所有主節(jié)點(diǎn)，分配策略沒有要求置尔「懿剑可以指定哪些編號(hào)的槽分配給哪個(gè)主節(jié)點(diǎn)。集群會(huì)記錄節(jié)點(diǎn)和槽的對(duì)應(yīng)關(guān)系撰洗。
接下來就需要對(duì)key求哈希值篮愉，然后對(duì)16384取余腐芍，余數(shù)是幾key就落入對(duì)應(yīng)的槽里差导。 slot = CRC16(key) % 16384 。
以槽為單位移動(dòng)數(shù)據(jù)猪勇，因?yàn)椴鄣臄?shù)目是固定的设褐，處理起來比較容易，這樣數(shù)據(jù)移動(dòng)問題就解決了泣刹。
使用哈希函數(shù)計(jì)算出key的哈希值助析，這樣就可以算出它對(duì)應(yīng)的槽，然后利用集群存儲(chǔ)的槽和節(jié)點(diǎn)的映射關(guān)系查詢出槽所在的節(jié)點(diǎn)椅您，于是數(shù)據(jù)和節(jié)點(diǎn)就映射起來了外冀，這樣數(shù)據(jù)分配問題就解決了。
我想說的是掀泳，一般的人只會(huì)去學(xué)習(xí)各種技術(shù)雪隧，高手更在乎如何跳出技術(shù)射亏，尋求一種解決方案或思路方向淘钟，順著這個(gè)方向走下去掀潮，八九不離十能找到你想要的答案赞草。
集群對(duì)命令操作的取舍
客戶端只要和集群中的一個(gè)節(jié)點(diǎn)建立鏈接后攘残，就可以獲取到整個(gè)集群的所有節(jié)點(diǎn)信息肢娘。此外還會(huì)獲取所有哈希槽和節(jié)點(diǎn)的對(duì)應(yīng)關(guān)系信息癞尚，這些信息數(shù)據(jù)都會(huì)在客戶端緩存起來禾乘，因?yàn)檫@些信息相當(dāng)有用韭邓。
客戶端可以向任何節(jié)點(diǎn)發(fā)送請(qǐng)求措近，那么拿到一個(gè)key后到底該向哪個(gè)節(jié)點(diǎn)發(fā)請(qǐng)求呢溶弟？其實(shí)就是把集群里的那套key和節(jié)點(diǎn)的映射關(guān)系理論搬到客戶端來就行了。
所以客戶端需要實(shí)現(xiàn)一個(gè)和集群端一樣的哈希函數(shù)熄诡，先計(jì)算出key的哈希值可很，然后再對(duì)16384取余，這樣就找到了該key對(duì)應(yīng)的哈希槽凰浮，利用客戶端緩存的槽和節(jié)點(diǎn)的對(duì)應(yīng)關(guān)系信息我抠，就可以找到該key對(duì)應(yīng)的節(jié)點(diǎn)了。
接下來發(fā)送請(qǐng)求就可以了袜茧。還可以把key和節(jié)點(diǎn)的映射關(guān)系緩存起來菜拓，下次再請(qǐng)求該key時(shí)，直接就拿到了它對(duì)應(yīng)的節(jié)點(diǎn)笛厦，不用再計(jì)算一遍了纳鼎。
理論和現(xiàn)實(shí)總是有差距的，集群已經(jīng)發(fā)生了變化裳凸，客戶端的緩存還沒來得及更新贱鄙。肯定會(huì)出現(xiàn)拿到一個(gè)key向?qū)?yīng)的節(jié)點(diǎn)發(fā)請(qǐng)求姨谷，其實(shí)這個(gè)key已經(jīng)不在那個(gè)節(jié)點(diǎn)上了逗宁。此時(shí)這個(gè)節(jié)點(diǎn)應(yīng)該怎么辦？
這個(gè)節(jié)點(diǎn)可以去key實(shí)際所在的節(jié)點(diǎn)上拿到數(shù)據(jù)再返回給客戶端梦湘，也可以直接告訴客戶端key已經(jīng)不在我這里了瞎颗，同時(shí)附上key現(xiàn)在所在的節(jié)點(diǎn)信息，讓客戶端再去請(qǐng)求一次捌议，類似于HTTP的302重定向哼拔。
這其實(shí)是個(gè)選擇問題，也是個(gè)哲學(xué)問題瓣颅。結(jié)果就是redis集群選擇了后者倦逐。因此，節(jié)點(diǎn)只處理自己擁有的key宫补，對(duì)于不擁有的key將返回重定向錯(cuò)誤檬姥，即 -MOVED key 127.0.0.1:6381 ，客戶端重新向這個(gè)新節(jié)點(diǎn)發(fā)送請(qǐng)求守谓。
所以說選擇是一種哲學(xué)穿铆，也是個(gè)智慧。稍后再談這個(gè)問題斋荞。先來看看另一個(gè)情況荞雏，和這個(gè)問題有些相同點(diǎn)。
redis有一種命令可以一次帶多個(gè)key，如MGET凤优，我把這些稱為多key命令悦陋。這個(gè)多key命令的請(qǐng)求被發(fā)送到一個(gè)節(jié)點(diǎn)上，這里有一個(gè)潛在的問題筑辨，不知道大家有沒有想到俺驶，就是這個(gè)命令里的多個(gè)key一定都位于那同一個(gè)節(jié)點(diǎn)上嗎？
就分為兩種情況了棍辕，如果多個(gè)key不在同一個(gè)節(jié)點(diǎn)上暮现，此時(shí)節(jié)點(diǎn)只能返回重定向錯(cuò)誤了，但是多個(gè)key完全可能位于多個(gè)不同的節(jié)點(diǎn)上楚昭，此時(shí)返回的重定向錯(cuò)誤就會(huì)非常亂栖袋，所以redis集群選擇不支持此種情況。
如果多個(gè)key位于同一個(gè)節(jié)點(diǎn)上呢抚太，理論上是沒有問題的塘幅，redis集群是否支持就和redis的版本有關(guān)系了，具體使用時(shí)自己測(cè)試一下就行了尿贫。
在這個(gè)過程中我們發(fā)現(xiàn)了一件頗有意義的事情电媳，就是讓一組相關(guān)的key映射到同一個(gè)節(jié)點(diǎn)上是非常有必要的，這樣可以提高效率庆亡，通過多key命令一次獲取多個(gè)值匾乓。
那么問題來了，如何給這些key起名字才能讓他們落到同一個(gè)節(jié)點(diǎn)上身冀，難不成都要先計(jì)算個(gè)哈希值钝尸，再取個(gè)余數(shù)括享，太麻煩了吧搂根。當(dāng)然不是這樣了，redis已經(jīng)幫我們想好了铃辖。
可以來簡單推理下剩愧，要想讓兩個(gè)key位于同一個(gè)節(jié)點(diǎn)上，它們的哈希值必須要一樣娇斩。要想哈希值一樣仁卷，傳入哈希函數(shù)的字符串必須一樣。那我們只能傳進(jìn)去兩個(gè)一模一樣的字符串了犬第，那不就變成同一個(gè)key了锦积，后面的會(huì)覆蓋前面的數(shù)據(jù)。
這里的問題是我們都是拿整個(gè)key去計(jì)算哈希值歉嗓，這就導(dǎo)致key和參與計(jì)算哈希值的字符串耦合了丰介，需要將它們解耦才行，就是key和參與計(jì)算哈希值的字符串有關(guān)但是又不一樣。
redis基于這個(gè)原理為我們提供了方案哮幢，叫做key哈希標(biāo)簽带膀。先看例子，{ user1000 }.following橙垢，{user1000 }.followers垛叨，相信你已經(jīng)看出了門道，就是僅使用Key中的位于 { 和 } 間的字符串參與計(jì)算哈希值柜某。
這樣可以保證哈希值相同嗽元，落到相同的節(jié)點(diǎn)上。但是key又是不同的喂击，不會(huì)互相覆蓋还棱。使用哈希標(biāo)簽把一組相關(guān)的key關(guān)聯(lián)了起來，問題就這樣被輕松愉快地解決了惭等。
相信你已經(jīng)發(fā)現(xiàn)了珍手，要解決問題靠的是巧妙的奇思妙想，而不是非要用牛逼的技術(shù)牛逼的算法辞做。這就是小強(qiáng)琳要，小而強(qiáng)大。
最后再來談選擇的哲學(xué)秤茅。redis的核心就是以最快的速度進(jìn)行常用數(shù)據(jù)結(jié)構(gòu)的key/value存取稚补，以及圍繞這些數(shù)據(jù)結(jié)構(gòu)的運(yùn)算。對(duì)于與核心無關(guān)的或會(huì)拖累核心的都選擇弱化處理或不處理框喳，這樣做是為了保證核心的簡單课幕、快速和穩(wěn)定。
其實(shí)就是在廣度和深度面前五垮，redis選擇了深度乍惊。所以節(jié)點(diǎn)不去處理自己不擁有的key，集群不去支持多key命令放仗。這樣一方面可以快速地響應(yīng)客戶端润绎，另一方面可以避免在集群內(nèi)部有大量的數(shù)據(jù)傳輸與合并。
單線程模型
redis集群的每個(gè)節(jié)點(diǎn)里只有一個(gè)線程負(fù)責(zé)接受和執(zhí)行所有客戶端發(fā)送的請(qǐng)求诞挨。技術(shù)上使用多路復(fù)用I/O莉撇，使用Linux的epoll函數(shù)，這樣一個(gè)線程就可以管理很多socket連接惶傻。
除此之外棍郎，選擇單線程還有以下這些原因：
1、redis都是對(duì)內(nèi)存的操作银室，速度極快（10W+QPS）
2涂佃、整體的時(shí)間主要都是消耗在了網(wǎng)絡(luò)的傳輸上
3静秆、如果使用了多線程，則需要多線程同步巡李，這樣實(shí)現(xiàn)起來會(huì)變的復(fù)雜
4抚笔、線程的加鎖時(shí)間甚至都超過了對(duì)內(nèi)存操作的時(shí)間
5、多線程上下文頻繁的切換需要消耗更多的CPU時(shí)間
6侨拦、還有就是單線程天然支持原子操作殊橙，而且單線程的代碼寫起來更簡單
事務(wù)
事務(wù)大家都知道，就是把多個(gè)操作捆綁在一起狱从，要么都執(zhí)行（成功了）膨蛮，要么一個(gè)也不執(zhí)行（回滾了）。redis也是支持事務(wù)的季研，但可能和你想要的不太一樣敞葛，一起來看看吧。
redis的事務(wù)可以分為兩步与涡，定義事務(wù)和執(zhí)行事務(wù)惹谐。使用multi命令開啟一個(gè)事務(wù)，然后把要執(zhí)行的所有命令都依次排上去驼卖。這就定義好了一個(gè)事務(wù)氨肌。此時(shí)使用exec命令來執(zhí)行這個(gè)事務(wù)，或使用discard命令來放棄這個(gè)事務(wù)酌畜。
你可能希望在你的事務(wù)開始前怎囚，你關(guān)心的key不想被別人操作，那么可以使用watch命令來監(jiān)視這些key桥胞，如果開始執(zhí)行前這些key被其它命令操作了則會(huì)取消事務(wù)的恳守。也可以使用unwatch命令來取消對(duì)這些key的監(jiān)視。
redis事務(wù)具有以下特點(diǎn)：
1贩虾、如果開始執(zhí)行事務(wù)前出錯(cuò)催烘，則所有命令都不執(zhí)行
2、一旦開始整胃，則保證所有命令一次性按順序執(zhí)行完而不被打斷
3颗圣、如果執(zhí)行過程中遇到錯(cuò)誤喳钟，會(huì)繼續(xù)執(zhí)行下去屁使，不會(huì)停止的
4、對(duì)于執(zhí)行過程中遇到錯(cuò)誤奔则，是不會(huì)進(jìn)行回滾的
看完這些蛮寂，真想問一句話，你這能叫事務(wù)嗎易茬？很顯然酬蹋，這并不是我們通常認(rèn)為的事務(wù)及老，因?yàn)樗B原子性都保證不了。保證不了原子性是因?yàn)閞edis不支持回滾范抓，不過它也給出了不支持的理由骄恶。
不支持回滾的理由：
1、redis認(rèn)為匕垫，失敗都是由命令使用不當(dāng)造成
2僧鲁、redis這樣做，是為了保持內(nèi)部實(shí)現(xiàn)簡單快速
3象泵、redis還認(rèn)為寞秃，回滾并不能解決所有問題
哈哈，這就是霸王條款偶惠，因此春寿，好像使用redis事務(wù)的不太多
管道
客戶端和集群的交互過程是串行化阻塞式的，即客戶端發(fā)送了一個(gè)命令后必須等到響應(yīng)回來后才能發(fā)第二個(gè)命令忽孽，這一來一回就是一個(gè)往返時(shí)間绑改。 如果你有很多的命令，都這樣一個(gè)一個(gè)的來進(jìn)行兄一，會(huì)變得很慢绢淀。
redis提供了一種管道技術(shù)，可以讓客戶端一次發(fā)送多個(gè)命令瘾腰，期間不需要等待服務(wù)器端的響應(yīng)皆的，等所有的命令都發(fā)完了，再依次接收這些命令的全部響應(yīng)蹋盆。 這就極大地節(jié)省了許多時(shí)間费薄，提升了效率。
聰明的你是不是意識(shí)到了另外一個(gè)問題栖雾，多個(gè)命令就是多個(gè)key啊楞抡，這不就是上面提到的多key操作嘛，那么問題來了析藕，你如何保證這多個(gè)key都是同一個(gè)節(jié)點(diǎn)上的啊召廷，哈哈，redis集群又放棄了對(duì)管道的支持账胧。
不過可以在客戶端模擬實(shí)現(xiàn)竞慢，就是使用多個(gè)連接往多個(gè)節(jié)點(diǎn)同時(shí)發(fā)送命令，然后等待所有的節(jié)點(diǎn)都返回了響應(yīng)治泥，再把它們按照發(fā)送命令的順序整理好筹煮，返回給用戶代碼。 哎呀居夹，好麻煩呀败潦。
協(xié)議
簡單了解下redis的協(xié)議本冲，知道redis的數(shù)據(jù)傳輸格式。
發(fā)送請(qǐng)求的協(xié)議：
* 參數(shù)個(gè)數(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檬洞，實(shí)際發(fā)送的數(shù)據(jù)是：
* 3 \r\n $ 3 \r\n SET \r\n $ 4 \r\n name \r\n $ 8 \r\n lixinjie \r\n
接受響應(yīng)的協(xié)議：
單行回復(fù)，第一個(gè)字節(jié)是
+
錯(cuò)誤消息沟饥，第一個(gè)字節(jié)是 -
整型數(shù)字疮胖，第一個(gè)字節(jié)是 :
批量回復(fù)，第一個(gè)字節(jié)是 $
多個(gè)批量回復(fù)闷板，第一個(gè)字節(jié)是 *
例如澎灸，
+ OK \r\n
- ERR Operation against \r\n
: 1000 \r\n
$ 6 \r\n foobar \r\n
* 2 \r\n $ 3 \r\n foo \r\n $ 3 \r\n bar \r\n
可見redis的協(xié)議設(shè)計(jì)的非常簡單。
