本篇文章不是一篇具體的教程,筆者打算記錄一下自己對(duì) Redis 的一些思考。說(shuō)來(lái)慚愧,筆者剛接觸 Redis 的時(shí)候只是簡(jiǎn)單地使用了一下,背了一些面試題,就在簡(jiǎn)歷上寫(xiě)下了 Redis 這個(gè)技能點(diǎn)。
我們能在網(wǎng)絡(luò)上輕易地找到關(guān)于 Redis 具體知識(shí)點(diǎn)的講解,但很少有文字說(shuō)明為什么會(huì)有這項(xiàng)技術(shù),筆者希望通過(guò)本文總結(jié)一下個(gè)人目前對(duì) Redis 的理解。
1. 初識(shí) Redis
最開(kāi)始的時(shí)候,筆者是通過(guò)網(wǎng)絡(luò)上面的一些項(xiàng)目教程了解到 Redis 的,當(dāng)時(shí)教程里說(shuō)把首頁(yè)數(shù)據(jù)放到 Redis 里,能夠加快首頁(yè)數(shù)據(jù)的訪問(wèn)速度,于筆者我就照做了。代碼跑起來(lái)后,發(fā)現(xiàn)好像確實(shí)加載得蠻快的,就當(dāng)完成了。
項(xiàng)目做完后,寫(xiě)到了簡(jiǎn)歷里,順便在技能里寫(xiě)上熟練使用 Redis,再背了幾道關(guān)于 Redis 的數(shù)據(jù)類型,持久化機(jī)制的面試題,便去找實(shí)習(xí)了。
當(dāng)時(shí)面試的時(shí)候面試官問(wèn)筆者:你為什么使用 Redis 呀?
筆者按照項(xiàng)目教程里說(shuō)的復(fù)述了一遍:因?yàn)槟茏屖醉?yè)更快地加載數(shù)據(jù),咱們的產(chǎn)品首頁(yè)是很重要,越快加載出數(shù)據(jù),用戶越滿意。
現(xiàn)在回想起來(lái)真是哭笑不得,你也不能說(shuō)這個(gè)回答有問(wèn)題,Redis 用作緩存的一大亮點(diǎn)就是能夠加快數(shù)據(jù)查詢效率,但是如果從技術(shù)面試的角度看,這個(gè)回答其實(shí)更應(yīng)該從技術(shù)的角度去答,這也是促使筆者寫(xiě)這篇文章的沖動(dòng)之一。
2. 為什么要有 Redis 這項(xiàng)技術(shù)?(你為什么用 Redis)
如果現(xiàn)在再被問(wèn)到為什么要用 Redis,筆者打算從計(jì)算機(jī)的存儲(chǔ)結(jié)構(gòu)開(kāi)始聊。
計(jì)算機(jī)界有一本名書(shū)《深入理解計(jì)算機(jī)系統(tǒng)》,里面有一幅關(guān)于計(jì)算機(jī)存儲(chǔ)結(jié)構(gòu)的圖,非常經(jīng)典:
由圖可見(jiàn)計(jì)算機(jī)的存儲(chǔ)器是一個(gè)金字塔結(jié)構(gòu),越上層的存儲(chǔ)器存儲(chǔ)效率越高,越下層的存儲(chǔ)效率越低。而計(jì)算機(jī)中內(nèi)存的層級(jí)位于磁盤(pán)之上,內(nèi)存的存儲(chǔ)效率要比磁盤(pán)快得多。
正常情況下,我們會(huì)把應(yīng)用的數(shù)據(jù)存放在數(shù)據(jù)庫(kù)中,數(shù)據(jù)庫(kù)把數(shù)據(jù)存放在磁盤(pán);而 Redis 是一款基于內(nèi)存的存儲(chǔ)系統(tǒng),數(shù)據(jù)都存在內(nèi)存里,這就是從 Redis 讀取數(shù)據(jù)比從數(shù)據(jù)庫(kù)讀取數(shù)據(jù)要快的根本原因了。
看到這里你可能會(huì)說(shuō),把數(shù)據(jù)存在內(nèi)存有啥了不起的,我可以用谷歌的 guava 呀!再不濟(jì),我可以直接 new 一個(gè) HashMap 存數(shù)據(jù)呀,這不都是基于內(nèi)存的嗎?
這個(gè)問(wèn)題讓我聯(lián)想起了我在網(wǎng)上看面經(jīng)的時(shí)候看到的一道題:如果讓你設(shè)計(jì)一個(gè)緩存,你會(huì)怎么設(shè)計(jì)?
大家可以想一下 guava 和 Map 集合使用時(shí)的缺點(diǎn)是什么?
很明顯一點(diǎn)就是這兩者雖然基于內(nèi)存,但他們使用的是 jvm 的內(nèi)存,如果 jvm 掛掉或者重啟了,數(shù)據(jù)也就丟失了。這就能方便我們聯(lián)想到 Redis 的持久化機(jī)制,Redis 的持久化機(jī)制使得內(nèi)存中的數(shù)據(jù)能夠持久化到磁盤(pán)上,解決內(nèi)存數(shù)據(jù)掉電易失的問(wèn)題,而且 Redis 是一款中間件,無(wú)需依賴于 jvm。
(當(dāng)初我只是死背 Redis 的持久化機(jī)制,并沒(méi)有想過(guò)為什么。我想搞清楚了這背后的關(guān)系后再去學(xué)習(xí),能夠?qū)W得更扎實(shí)一些吧)
再換一個(gè)角度:既然數(shù)據(jù)庫(kù)是因?yàn)榇疟P(pán)才慢,那為啥不再內(nèi)存里實(shí)現(xiàn)數(shù)據(jù)庫(kù)呢?
還別說(shuō),SAP 公司還真有基于內(nèi)存的數(shù)據(jù)庫(kù)系統(tǒng),但是使用內(nèi)存有一個(gè)致命的缺點(diǎn):那就是貴!能買(mǎi)得起那套軟件和巨大內(nèi)存機(jī)器的公司畢竟是少數(shù),所以說(shuō)為什么要使用 Redis,就是因?yàn)樗诘托У拇疟P(pán)和昂貴的內(nèi)存中取了一個(gè)折中。
補(bǔ)充:面試的時(shí)候還被問(wèn)到一個(gè)問(wèn)題:Redis 的內(nèi)存淘汰機(jī)制
當(dāng)時(shí)直接懵圈了,后來(lái)想了一下其實(shí)這是一個(gè)再正常不過(guò)的考點(diǎn)了:Redis 把數(shù)據(jù)存放在內(nèi)存,內(nèi)存的空間有限,總會(huì)有用完的一天。當(dāng)內(nèi)存使用完之后肯定需要有相應(yīng)的內(nèi)存淘汰策略來(lái)釋放內(nèi)存。
不過(guò)說(shuō)到內(nèi)存淘汰,我還想起一個(gè)高級(jí)點(diǎn)的知識(shí)點(diǎn),由于 Redis 的內(nèi)存是有限的,我們使用內(nèi)存的時(shí)候應(yīng)該更加小心。Redis 內(nèi)部是有許多高效使用內(nèi)存的招數(shù)的,比如說(shuō)我們存放用戶信息的時(shí)候,把用戶信息存成一個(gè) hash,要比把用戶信息逐條用 key-value 存儲(chǔ)占的空間小得多,這些知識(shí)你可以在 Redid 的官網(wǎng)上找到。
3. 關(guān)于 Redis 的主從復(fù)制,哨兵,集群
在學(xué)習(xí) Redis 之前,我對(duì)分布式的知識(shí)了解得非常少。當(dāng)時(shí)為了面試背 Redis 的面試題,背到有關(guān)主從復(fù)制,哨兵,集群等知識(shí)點(diǎn)的時(shí)候,我既興奮又茫然。感覺(jué)自己背完后掌握了許多分布式的知識(shí),但是把這些知識(shí)點(diǎn)都揉在一起了,根本不知道這背后的邏輯是什么。現(xiàn)在想通了一些,應(yīng)該好好記下來(lái):
在擴(kuò)展到多機(jī)之前,我們先想一下單機(jī)的 Redis 有什么缺點(diǎn):
有可能出現(xiàn)單點(diǎn)故障,這樣 Redis 服務(wù)就不可用了
單一臺(tái)機(jī)器的內(nèi)存有限,存儲(chǔ)不了太多的數(shù)據(jù)
如果訪問(wèn)量很大的話,單臺(tái)機(jī)器壓力會(huì)很大
通過(guò)第一個(gè)缺點(diǎn),我們可以引出為什么需要主從復(fù)制和哨兵。大家想一想,如果我們只有一個(gè) Redis 服務(wù),要是服務(wù)掛了就沒(méi)法用了,但如果我們安排多一臺(tái) Redis 服務(wù)器,它的數(shù)據(jù)時(shí)刻與第一臺(tái) Redis 的數(shù)據(jù)保持一致,這樣當(dāng)?shù)谝慌_(tái) Redis 掛掉后,我們就可以把請(qǐng)求遷移到第二臺(tái) Redis 上,這樣 Redis 服務(wù)的可用性就提高了。為了讓第二臺(tái) Redis 的數(shù)據(jù)與第一臺(tái) Redis 保持一致,我們就需要用到主從復(fù)制。
有時(shí)候,可能一主一從的配置還是不夠保險(xiǎn),這個(gè)時(shí)候我們就要為主節(jié)點(diǎn)配置兩個(gè)或以上的從節(jié)點(diǎn),那么問(wèn)題來(lái)了,要是主節(jié)點(diǎn)掛了,該通過(guò)什么方案在從節(jié)點(diǎn)中選出新的主節(jié)點(diǎn)呢?這就用到了哨兵機(jī)制。
而且在一主多從的情況下,我們使用主從復(fù)制讓多臺(tái) Redis 的數(shù)據(jù)保持一致,這個(gè)時(shí)候我們就可以把讀請(qǐng)求分?jǐn)偟綇墓?jié)點(diǎn)上,這樣能有效緩解主節(jié)點(diǎn)的讀壓力。
但如果 Redis 的寫(xiě)請(qǐng)求壓力也很大,而且數(shù)據(jù)量很大,這個(gè)時(shí)候?yàn)?Redis 增加備份機(jī)的橫向擴(kuò)展已經(jīng)幫不上什么忙了,這個(gè)時(shí)候我們就要考慮縱向擴(kuò)展,增加多臺(tái) Redis 分?jǐn)倢?xiě)請(qǐng)求,讓不同的 key 落到不同的機(jī)器上。這個(gè)時(shí)候我們就要考慮使用一致性哈希等算法把不同的 key 分給不同的機(jī)器。
Redis 自身也提供了集群機(jī)制,但內(nèi)部使用的不是一致性哈希,而是哈希槽。簡(jiǎn)單來(lái)說(shuō)就是在哈希槽中劃分不同的區(qū)間,不同的區(qū)間對(duì)應(yīng)不同的機(jī)制;當(dāng)擴(kuò)容或縮減的時(shí)候有相應(yīng)的哈希槽調(diào)整策略。
我最初學(xué)習(xí) Redis 的多機(jī)策略的時(shí)候就是搞不清楚集群,主從復(fù)制,哨兵機(jī)制之間的關(guān)系。其實(shí)集群就是一套完整的 Redis 多機(jī)解決方案,他有效解決了單機(jī) Redis 的所有問(wèn)題。當(dāng)你在集群中為某個(gè)節(jié)點(diǎn)配置從機(jī)的時(shí)候,主從節(jié)點(diǎn)間同步用的就是主從復(fù)制。主節(jié)點(diǎn)掛掉之后,從節(jié)點(diǎn)的選取,內(nèi)部的邏輯就和哨兵機(jī)制相似。當(dāng)我們使用集群機(jī)制的時(shí)候,就可以省去自己寫(xiě)類似一致性哈希這樣的分?jǐn)傔壿嫞簷C(jī)制會(huì)給節(jié)點(diǎn)加上相應(yīng)的數(shù)據(jù)結(jié)構(gòu)來(lái)完成這些功能。
如果想深入了解集群背后的實(shí)現(xiàn)原理,我推薦這樣一個(gè)學(xué)習(xí)路線:
首先登錄官網(wǎng),按照官網(wǎng)的步驟學(xué)習(xí)配置主從復(fù)制,配置哨兵,搭建集群
然后看《Redis 的設(shè)計(jì)與實(shí)現(xiàn)》這本書(shū),閱讀主從復(fù)制,哨兵和集群這三個(gè)章節(jié)
4. 后話
筆者覺(jué)得,如果把文章中提到的 Redis 的點(diǎn)都深入了解一下,Redis 基本能算入門(mén)了。
寫(xiě)下這篇感想主要也是想提醒自己,學(xué)一項(xiàng)技術(shù)的時(shí)候多問(wèn)為什么,這樣知識(shí)學(xué)到手后不容易忘掉。
至于為什么說(shuō)只能說(shuō)是入門(mén) Redis,因?yàn)?Redis 的用法實(shí)在太多了,你可以把它當(dāng)作緩存,也可以把它當(dāng)成數(shù)據(jù)庫(kù),甚至能把它當(dāng)作消息隊(duì)列。緩存可能大家都很熟悉了,在當(dāng)數(shù)據(jù)庫(kù)的方面 Redis 簡(jiǎn)直是潛力無(wú)限,大家一定要善用它的 bitmap 位圖功能,簡(jiǎn)直能在面對(duì)復(fù)雜需求的時(shí)候玩出花來(lái)。比如說(shuō)老板要統(tǒng)計(jì)所有用戶一年中的登錄天數(shù),一個(gè)用戶只需要 365bit(46B)的空間,相比于用傳統(tǒng)的 mysql 不知道也節(jié)省多少倍的空間。
審核編輯 黃昊宇
-
Redis
+關(guān)注
關(guān)注
0文章
371瀏覽量
10844
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
評(píng)論