本篇文章不是一篇具體的教程，筆者打算記錄一下自己對 Redis 的一些思考。說來慚愧，筆者剛接觸 Redis 的時候只是簡單地使用了一下，背了一些面試題，就在簡歷上寫下了 Redis 這個技能點。

我們能在網絡上輕易地找到關于 Redis 具體知識點的講解，但很少有文字說明為什么會有這項技術，筆者希望通過本文總結一下個人目前對 Redis 的理解。

1. 初識 Redis

最開始的時候，筆者是通過網絡上面的一些項目教程了解到 Redis 的，當時教程里說把首頁數據放到 Redis 里，能夠加快首頁數據的訪問速度，于筆者我就照做了。代碼跑起來后，發現好像確實加載得蠻快的，就當完成了。

項目做完后，寫到了簡歷里，順便在技能里寫上熟練使用 Redis，再背了幾道關于 Redis 的數據類型，持久化機制的面試題，便去找實習了。

當時面試的時候面試官問筆者：你為什么使用 Redis 呀？

筆者按照項目教程里說的復述了一遍：因為能讓首頁更快地加載數據，咱們的產品首頁是很重要，越快加載出數據，用戶越滿意。

現在回想起來真是哭笑不得，你也不能說這個回答有問題，Redis 用作緩存的一大亮點就是能夠加快數據查詢效率，但是如果從技術面試的角度看，這個回答其實更應該從技術的角度去答，這也是促使筆者寫這篇文章的沖動之一。

2. 為什么要有 Redis 這項技術？（你為什么用 Redis）

如果現在再被問到為什么要用 Redis，筆者打算從計算機的存儲結構開始聊。

計算機界有一本名書《深入理解計算機系統》，里面有一幅關于計算機存儲結構的圖，非常經典：

由圖可見計算機的存儲器是一個金字塔結構，越上層的存儲器存儲效率越高，越下層的存儲效率越低。而計算機中內存的層級位于磁盤之上，內存的存儲效率要比磁盤快得多。

正常情況下，我們會把應用的數據存放在數據庫中，數據庫把數據存放在磁盤;而 Redis 是一款基于內存的存儲系統，數據都存在內存里，這就是從 Redis 讀取數據比從數據庫讀取數據要快的根本原因了。

看到這里你可能會說，把數據存在內存有啥了不起的，我可以用谷歌的 guava 呀！再不濟，我可以直接 new 一個 HashMap 存數據呀，這不都是基于內存的嗎？

這個問題讓我聯想起了我在網上看面經的時候看到的一道題：如果讓你設計一個緩存，你會怎么設計？

大家可以想一下 guava 和 Map 集合使用時的缺點是什么？

很明顯一點就是這兩者雖然基于內存，但他們使用的是 jvm 的內存，如果 jvm 掛掉或者重啟了，數據也就丟失了。這就能方便我們聯想到 Redis 的持久化機制，Redis 的持久化機制使得內存中的數據能夠持久化到磁盤上，解決內存數據掉電易失的問題，而且 Redis 是一款中間件，無需依賴于 jvm。

（當初我只是死背 Redis 的持久化機制，并沒有想過為什么。我想搞清楚了這背后的關系后再去學習，能夠學得更扎實一些吧）

再換一個角度：既然數據庫是因為磁盤才慢，那為啥不再內存里實現數據庫呢？

還別說，SAP 公司還真有基于內存的數據庫系統，但是使用內存有一個致命的缺點：那就是貴！能買得起那套軟件和巨大內存機器的公司畢竟是少數，所以說為什么要使用 Redis，就是因為他在低效的磁盤和昂貴的內存中取了一個折中。

補充：面試的時候還被問到一個問題：Redis 的內存淘汰機制

當時直接懵圈了，后來想了一下其實這是一個再正常不過的考點了：Redis 把數據存放在內存，內存的空間有限，總會有用完的一天。當內存使用完之后肯定需要有相應的內存淘汰策略來釋放內存。

不過說到內存淘汰，我還想起一個高級點的知識點，由于 Redis 的內存是有限的，我們使用內存的時候應該更加小心。Redis 內部是有許多高效使用內存的招數的，比如說我們存放用戶信息的時候，把用戶信息存成一個 hash，要比把用戶信息逐條用 key-value 存儲占的空間小得多，這些知識你可以在 Redid 的官網上找到。

3. 關于 Redis 的主從復制，哨兵，集群

在學習 Redis 之前，我對分布式的知識了解得非常少。當時為了面試背 Redis 的面試題，背到有關主從復制，哨兵，集群等知識點的時候，我既興奮又茫然。感覺自己背完后掌握了許多分布式的知識，但是把這些知識點都揉在一起了，根本不知道這背后的邏輯是什么。現在想通了一些，應該好好記下來：

在擴展到多機之前，我們先想一下單機的 Redis 有什么缺點：

有可能出現單點故障，這樣 Redis 服務就不可用了

單一臺機器的內存有限，存儲不了太多的數據

如果訪問量很大的話，單臺機器壓力會很大

通過第一個缺點，我們可以引出為什么需要主從復制和哨兵。大家想一想，如果我們只有一個 Redis 服務，要是服務掛了就沒法用了，但如果我們安排多一臺 Redis 服務器，它的數據時刻與第一臺 Redis 的數據保持一致，這樣當第一臺 Redis 掛掉后，我們就可以把請求遷移到第二臺 Redis 上，這樣 Redis 服務的可用性就提高了。為了讓第二臺 Redis 的數據與第一臺 Redis 保持一致，我們就需要用到主從復制。

有時候，可能一主一從的配置還是不夠保險，這個時候我們就要為主節點配置兩個或以上的從節點，那么問題來了，要是主節點掛了，該通過什么方案在從節點中選出新的主節點呢？這就用到了哨兵機制。

而且在一主多從的情況下，我們使用主從復制讓多臺 Redis 的數據保持一致，這個時候我們就可以把讀請求分攤到從節點上，這樣能有效緩解主節點的讀壓力。

但如果 Redis 的寫請求壓力也很大，而且數據量很大，這個時候為 Redis 增加備份機的橫向擴展已經幫不上什么忙了，這個時候我們就要考慮縱向擴展，增加多臺 Redis 分攤寫請求，讓不同的 key 落到不同的機器上。這個時候我們就要考慮使用一致性哈希等算法把不同的 key 分給不同的機器。

Redis 自身也提供了集群機制，但內部使用的不是一致性哈希，而是哈希槽。簡單來說就是在哈希槽中劃分不同的區間，不同的區間對應不同的機制;當擴容或縮減的時候有相應的哈希槽調整策略。

我最初學習 Redis 的多機策略的時候就是搞不清楚集群，主從復制，哨兵機制之間的關系。其實集群就是一套完整的 Redis 多機解決方案，他有效解決了單機 Redis 的所有問題。當你在集群中為某個節點配置從機的時候，主從節點間同步用的就是主從復制。主節點掛掉之后，從節點的選取，內部的邏輯就和哨兵機制相似。當我們使用集群機制的時候，就可以省去自己寫類似一致性哈希這樣的分攤邏輯，集群機制會給節點加上相應的數據結構來完成這些功能。

如果想深入了解集群背后的實現原理，我推薦這樣一個學習路線：

首先登錄官網，按照官網的步驟學習配置主從復制，配置哨兵，搭建集群

然后看《Redis 的設計與實現》這本書，閱讀主從復制，哨兵和集群這三個章節

4. 后話

筆者覺得，如果把文章中提到的 Redis 的點都深入了解一下，Redis 基本能算入門了。

寫下這篇感想主要也是想提醒自己，學一項技術的時候多問為什么，這樣知識學到手后不容易忘掉。

至于為什么說只能說是入門 Redis，因為 Redis 的用法實在太多了，你可以把它當作緩存，也可以把它當成數據庫，甚至能把它當作消息隊列。緩存可能大家都很熟悉了，在當數據庫的方面 Redis 簡直是潛力無限，大家一定要善用它的 bitmap 位圖功能，簡直能在面對復雜需求的時候玩出花來。比如說老板要統計所有用戶一年中的登錄天數，一個用戶只需要 365bit（46B）的空間，相比于用傳統的 mysql 不知道也節省多少倍的空間。

審核編輯 黃昊宇