• 1 從零開始
• 2 基於本機記憶體的快取
• 3 服務端的Redis
  • 3.1 持久化（Persistence）
  • 3.2 哨兵（Sentinel）和複製（Replication）
  • 3.3 叢集（Cluster）
• 4 客戶端的Redis
  • 4.1 資料型別
  • 4.2 事務
  • 4.3 Lua指令碼
  • 4.4 管道
  • 4.5 分散式鎖
• 總結

---

先看一下Redis是一個什麼東西。官方簡介解釋到：Redis是一個基於BSD開源的專案，是一個把結構化的資料放在記憶體中的一個儲存系統，你可以把它作為資料庫，快取和訊息中介軟體來使用。同時支援strings，lists，hashes，sets，sorted sets，bitmaps，hyperloglogs和geospatial indexes等資料型別。它還內建了複製，lua指令碼，LRU，事務等功能，透過redis sentinel實現高可用，透過redis cluster實現了自動分片。以及事務，釋出/訂閱，自動故障轉移等等。

綜上所述，Redis提供了豐富的功能，初次見到可能會感覺眼花繚亂，這些功能都是幹嘛用的？都解決了什麼問題？什麼情況下才會用到相應的功能？那麼下麵從零開始，一步一步的演進來粗略的解釋下。

1 從零開始

最初的需求非常簡單，我們有一個提供熱點新聞串列的api：http://api.xxx.com/hot-news，api的消費者抱怨說每次請求都要2秒左右才能傳回結果。

隨後我們就著手於如何提升一下api消費者感知的效能，很快最簡單粗暴的第一個方案就出來了：為API的響應加上基於HTTP的快取控制 cache-control:max-age=600 ，即讓消費者可以快取這個響應十分鐘。如果api消費者如果有效的利用了響應中的快取控制資訊，則可以有效的改善其感知的效能（10分鐘以內）。但是還有2個弊端：第一個是在快取生效的10分鐘內，api消費者可能會得到舊的資料；第二個是如果api的客戶端無視快取直接訪問API依然是需要2秒，治標不治本吶。

2 基於本機記憶體的快取

為瞭解決呼叫API依然需要2秒的問題，經過排查，其主要原因在於使用SQL獲取熱點新聞的過程中消耗了將近2秒的時間，於是乎，我們又想到了一個簡單粗暴的解決方案，即把SQL查詢的結果直接快取在當前api伺服器的記憶體中（設定快取有效時間為1分鐘）。後續1分鐘內的請求直接讀快取，不再花費2秒去執行SQL了。假如這個api每秒接收到的請求時100個，那麼一分鐘就是6000個，也就是隻有前2秒擁擠過來的請求會耗時2秒，後續的58秒中的所有請求都可以做到即使響應，而無需再等2秒的時間。

其他API的小夥伴發現這是個好辦法，於是很快我們就發現API伺服器的記憶體要爆滿了。。。

3 服務端的Redis

在API伺服器的記憶體都被快取塞滿的時候，我們發現不得不另想解決方案了。最直接的想法就是我們把這些快取都丟到一個專門的伺服器上吧，把它的記憶體配置的大大的。然後我們就盯上了redis。。。至於如何配置部署redis這裡不解釋了，redis官方有詳細的介紹。隨後我們就用上了一臺單獨的伺服器作為Redis的伺服器，API伺服器的記憶體壓力得以解決。

3.1 持久化（Persistence）

單臺的Redis伺服器一個月總有那麼幾天心情不好，心情不好就罷工了，導致所有的快取都丟失了（redis的資料是儲存在記憶體的嘛）。雖然可以把Redis伺服器重新上線，但是由於記憶體的資料丟失，造成了快取雪崩，API伺服器和資料庫的壓力還是一下子就上來了。所以這個時候Redis的持久化功能就派上用場了，可以緩解一下快取雪崩帶來的影響。redis的持久化指的是redis會把記憶體的中的資料寫入到硬碟中，在redis重新啟動的時候載入這些資料，從而最大限度的降低快取丟失帶來的影響。

3.2 哨兵（Sentinel）和複製（Replication）

Redis伺服器毫無徵兆的罷工是個麻煩事。那麼怎辦辦？答曰：備份一臺，你掛了它上。那麼如何得知某一臺redis伺服器掛了，如何切換，如何保證備份的機器是原始伺服器的完整備份呢？這時候就需要Sentinel和Replication出場了。Sentinel可以管理多個Redis伺服器，它提供了監控，提醒以及自動的故障轉移的功能；Replication則是負責讓一個Redis伺服器可以配備多個備份的伺服器。Redis也是利用這兩個功能來保證Redis的高可用的。此外，Sentinel功能則是對Redis的釋出和訂閱功能的一個利用。

3.3 叢集（Cluster）

單臺伺服器資源的總是有上限的，CPU資源和IO資源我們可以透過主從複製，進行讀寫分離，把一部分CPU和IO的壓力轉移到從伺服器上。但是記憶體資源怎麼辦，主從樣式做到的只是相同資料的備份，並不能橫向擴充記憶體；單臺機器的記憶體也只能進行加大處理，但是總有上限的。所以我們就需要一種解決方案，可以讓我們橫向擴充套件。最終的目的既是把每臺伺服器只負責其中的一部分，讓這些所有的伺服器構成一個整體，對外界的消費者而言，這一組分散式的伺服器就像是一個集中式的伺服器一樣（之前在解讀REST的部落格中解釋過分散式於基於網路的差異：基於網路應用的架構）。

在Redis官方的分散式方案出來之前，有twemproxy和codis兩種方案，這兩個方案總體上來說都是依賴proxy來進行分散式的，也就是說redis本身並不關心分散式的事情，而是交由twemproxy和codis來負責。而redis官方給出的cluster方案則是把分散式的這部分事情做到了每一個redis伺服器中，使其不再需要其他的元件就可以獨立的完成分散式的要求。我們這裡不關心這些方案的優略，我們關註一下這裡的分散式到底是要處理那些事情?也就是twemproxy和codis獨立處理的處理分散式的這部分邏輯和cluster整合到redis服務的這部分邏輯到底在解決什麼問題？

如我們前面所說的，一個分散式的服務在外界看來就像是一個集中式的服務一樣。那麼要做到這一點就面臨著有一個問題需要解決：既是增加或減少分散式服務中的伺服器的數量，對消費這個服務的客戶端而言應該是無感的；那麼也就意味著客戶端不能穿透分散式服務，把自己綁死到某一個臺的伺服器上去，因為一旦如此，你就再也無法新增伺服器，也無法進行故障替換。解決這個問題有兩個路子：第一個路子最直接，那就是我加一個中間層來隔離這種具體的依賴，即twemproxy採用的方式，讓所有的客戶端只能透過它來消費redsi服務，透過它來隔離這種依賴（但是你會發現twermproxy會成為一個單點），這種情況下每臺redis伺服器都是獨立的，它們之間彼此不知對方的存在；第二個路子是讓redis伺服器知道彼此的存在，透過重定向的機制來引導客戶端來完成自己所需要的操作，比如客戶端連結到了某一個redis伺服器，說我要執行這個操作，redis伺服器發現自己無法完成這個操作，那麼就把能完成這個操作的伺服器的資訊給到客戶端，讓客戶端去請求另外的一個伺服器，這時候你就會發現每一個redis伺服器都需要保持一份完整的分散式伺服器資訊的一份資料，不然它怎麼知道讓客戶端去找其他的哪個伺服器來執行客戶端想要的操作呢。

上面這一大段解釋了這麼多，不知有沒有發現不管是第一個路子還是第二個路子，都有一個共同的東西存在，那就是分散式服務中所有伺服器以及其能提供的服務的資訊。這些資訊無論如何也是要存在的，區別在於第一個路子是把這部分資訊單獨來管理，用這些資訊來協調後端的多個獨立的redis伺服器；第二個路子則是讓每一個redis伺服器都持有這份資訊，彼此知道對方的存在，來達成和第一個路子一樣的目的，優點是不再需要一個額外的元件來處理這部分事情。

Redis Cluster的具體實現細節則是採用了Hash槽的概念，即預先分配出來16384個槽：在客戶端透過對Key進行CRC16（key）% 16384運算得到對應的槽是哪一個；在redis服務端則是每個伺服器負責一部分槽，當有新的伺服器加入或者移除的時候，再來遷移這些槽以及其對應的資料，同時每個伺服器都持有完整的槽和其對應的伺服器的資訊，這就使得伺服器端可以進行對客戶端的請求進行重定向處理。

4 客戶端的Redis

上面的第三小節主要介紹的是Redis服務端的演進步驟，解釋了Redis如何從一個單機的服務，進化為一個高可用的、去中心化的、分散式的儲存系統。這一小節則是關註下客戶端可以消費的redis服務。

4.1 資料型別

redis支援豐富的資料型別，從最基礎的string到複雜的常用到的資料結構都有支援：

1. string：最基本的資料型別，二進位制安全的字串，最大512M。
2. list：按照新增順序保持順序的字串串列。
3. set：無序的字串集合，不存在重覆的元素。
4. sorted set：已排序的字串集合。
5. hash：key-value對的一種集合。
6. bitmap：更細化的一種操作，以bit為單位。
7. hyperloglog：基於機率的資料結構。

這些眾多的資料型別，主要是為了支援各種場景的需要，當然每種型別都有不同的時間複雜度。其實這些複雜的資料結構相當於之前我在《解讀REST》這個系列部落格基於網路應用的架構風格中介紹到的遠端資料訪問（Remote Data Access = RDA）的具體實現，即透過在伺服器上執行一組標準的操作命令，在服務端之間得到想要的縮小後的結果集，從而簡化客戶端的使用，也可以提高網路效能。比如如果沒有list這種資料結構，你就只能把list存成一個string，客戶端拿到完整的list，操作後再完整的提交給redis，會產生很大的浪費。

4.2 事務

上述資料型別中，每一個資料型別都有獨立的命令來進行操作，很多情況下我們需要一次執行不止一個命令，而且需要其同時成功或者失敗。redis對事務的支援也是源自於這部分需求，即支援一次性按順序執行多個命令的能力，並保證其原子性。

4.3 Lua指令碼

在事務的基礎上，如果我們需要在服務端一次性的執行更複雜的操作（包含一些邏輯判斷），則lua就可以排上用場了（比如在獲取某一個快取的時候，同時延長其過期時間）。redis保證lua指令碼的原子性，一定的場景下，是可以代替redis提供的事務相關的命令的。相當於基於網路應用的架構風格中介紹到的遠端求值（Remote Evluation = REV）的具體實現。

4.4 管道

因為redis的客戶端和伺服器的連線時基於TCP的， 預設每次連線都時只能執行一個命令。管道則是允許利用一次連線來處理多條命令，從而可以節省一些tcp連線的開銷。管道和事務的差異在於管道是為了節省通訊的開銷，但是並不會保證原子性。

4.5 分散式鎖

官方推薦採用Redlock演演算法，即使用string型別，加鎖的時候給的一個具體的key，然後設定一個隨機的值；取消鎖的時候用使用lua指令碼來先執行獲取比較，然後再刪除key。具體的命令如下：

SET resource_name my_random_value NX PX 30000

if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end

總結

本篇著重從抽象層面來解釋下redis的各項功能以及其存在的目的，而沒有關心其具體的細節是什麼。從而可以聚焦於其解決的問題，依據抽象層面的概念可以使得我們在特定的場景下選擇更合適的方案，而非侷限於其技術細節。

以上均是筆者個人的一些理解，如果不當之處，歡迎指正。