架構師之路-redis叢集解析

引子

 上篇​​《架構師之路-https底層原理》​​裡我提到了上面的整體視圖，文章也介紹了想要真正能在工作中及時正确解決問題的基本功：原理了解透徹。今天以redis叢集解析為例介紹一個及時敏銳的發現問題的基本功：深入分析。

我認為達到深入分析有三個步驟：

第一步，深入了解

第二步，學以緻用

第三步，千人千問

第一步redis叢集各種原理介紹的人也很多；第二步很多人實際項目中大概也對redis叢集不陌生；是以本文主要講第三步：千人千問。

提出問題

"redis叢集使用時有什麼注意事項？"這是之前有段時間我面試喜歡問的一個問題。我的一個觀點是作為redis叢集的使用方而不是開發者首先要做的是用好。通過這個問題确定候選人用好了，再去挖掘他是通過了解了怎麼用好的。是以我通常不會一開始就問一些中間件的原理，而是先從使用者的角度提出問題。

下面列舉了6條代表性的回答：

1>防止集中失效

2>單線程執行，注意不要卡住

3>注意用戶端和服務端的版本比對

4>分片要保持流量均勻

5>注意逾時時間配置

6>當記憶體緩存用，推薦删除代替更新

每條問題前面加上個為什麼，就引出了6條新的問題。

解決問題

Q1：為什麼要防止緩存集中失效？

A：緩存穿透、緩存集中失效和緩存雪崩并稱為緩存世界的三大問題。先來總結了解一下這三個概念。這三個概念都是建立在緩存的一大作用就是對後端存儲，比如mysql的保護。緩存沒有保護住mysql，一個或一些到mysql了，那就是穿透；一個時間點緩存資料沒有了，打到mysql了就是集中失效；緩存完全喪失了保護mysql的能力，請求全打到mysql了，就是雪崩。

是以防止緩存集中失效是對後端存儲的保護。

Q2：為什麼單線程執行，注意不要卡住？

A：卡住換個專業點的詞就是阻塞嘛。什麼叫阻塞呢，一輛小轎車A在單行道跑，遇到前面一輛車B停了，那A就被阻塞了。如果A和B都在高速單行道上跑，A開了160邁、B開了140邁。就算高速的允許最高速度是120邁(咱就當路過的是沒有攝像頭的路段，這倆車肆無忌憚)，那A是不是還是被B給阻塞了呢？是以卡住造成的最直接影響就是快的快不起來，因為單線程不能繞行嘛。

有人說不是可以多開幾個redis嘛。是滴，但是用戶端分請求使用的是crc16，根本不會先探測哪個服務端比較空閑呀。是以後面來的總會被阻塞。

注意不要卡住還有個大家更常聽到的名字：“避免大key問題”。其實我剛聽到這個名字的時候是覺得很奇怪的。因為避免大key實際上是要避免key所對應的value不要太大。我之前一直覺得這個名字取的不對。那應該叫“避免大value問題”。後來想想這确實是正宗的中國話。比如張三的媳婦，人家都怎樣叫呢？一般都是張三媳婦、張三家的。因為他家主要是張三出來抛頭露面。那redis取值也一樣，一般是先知道key，從key取value。用這個key取出來的資料大，就是大key問題啦。

Q3：如果不注意用戶端和服務端版本比對會引發什麼問題？

A：先來思考用戶端做了什麼事情。我了解它就做了兩件事：第一是使用RESP（Redis自定義的序列化協定）傳輸用戶端指令并傳回結果。第二是為了做第一件事，因為Redis叢集是直連服務端模式，是以計算指令要落在哪個節點、哪個哈希槽上也是用戶端來做的，我就稱為選節點吧。

其實要回答用戶端和服務端不比對會引發什麼問題，正規的方法應該是檢視用戶端版本更新都做過什麼更新。

一般更新會做的是用戶端依賴的jar包變了。這個可能會引起程式啟動錯誤，但是這個往往啟動成功了就不會再有問題，和服務端版本沒有直接關系。

十年前還在用memcache的時候，發生過一次更新用戶端版本，因為算法發生了變化，是以導緻緩存全部不命中的問題。Redis最近的算法一直是crc16。如果不存在分布式算法不相容問題的話，下一個要考慮的是大疊代是Redis3.0版本，支援了叢集，叢集模式是必須要比對的。

Q4：為什麼分片要保持流量均勻？

A：要提分片先來回憶一下redis叢集的發展史，從單機版到主從版，後來有了大家可能很耳熟的哨兵模式。哨兵模式就是給主從增加一個監控，發現主節點挂了自動把從節點更新為主節點，有了故障自動遷移的功能。但是直到哨兵時代都隻有一個主節點，也就是處理寫請求的節點，不能稱之為真正的叢集。這也是很無奈的事情，一旦多個節點寫一份資料，就涉及到資料一緻性的問題。

一個蜂巢隻能有一個蜂後，多出來一個，蜜蜂們就不會正常提供采蜜服務了，都打架去了。但是分成兩個蜂巢呢？秩序就會恢複。是以現在的叢集基本都是分片的原理。之前主從和哨兵的經驗不能廢棄，加上分片。redis叢集就是将一個完整服務資料分成幾份，每份都帶着從節點，故障時可自動轉移的一個整體。之前在《​​Redis叢集搭建采坑總結​​》裡講過，1個節點的叢集會有問題，最少需要3主3從也就是6個redis程序。3個主友善在1個挂掉之後重新選主。

梳理了這個之後，分片保持流量均勻這件事也很容易了。就是Q2的問題，均勻更不容易阻塞嘛。

Q5：為什麼要注意逾時時間配置？

A：提到redis的key的過期時間，首先想到的是redis的術語中，帶過期時間的key又叫volatile key，就是不穩定key。怎麼不穩定呢？就相當key這個對象有value和過期時間2個屬性。過期時間這個屬性1s改變一次(redis領域内時間都是以秒為機關)，一直在變，當然不穩定。

如果把過期時間了解為key的一個屬性，那也很好了解：對其進行del、set指令時過期時間也會删除；rename會把過期時間傳給新的key；incr、lpush、hset等指令改變的是key的存儲容器，沒有改變key這個對象本身是以不會影響過期時間。

值得注意的是persist指令就是持久化儲存的意思，将不穩定變成穩定，過期時間也自動删除了。

Redis在服務端有過期政策，但是對用戶端是不感覺的。用戶端通路過期的就是一個表現，通路不到了。實際上服務端是有兩種政策配合使用，一個是惰性删除，就是通路的時候發現過期了，就直接删除了；另一個政策會定期去删除，這個是為了防止一個過期的key總是不被通路到，還占着資源不釋放。

Q6：為什麼當記憶體緩存用，推薦删除代替更新？

A：一般大家出于資料一緻性的考慮，會選擇删除代替更新。這都是基于更新一定要更新資料庫的固有思路。并發場景下，A的值1先被更新到資料庫再更新緩存時，又來了一個更新請求把A的值更新為2。如果這時候執行更新為1的伺服器性能不好或者網絡傳輸速度比更新為2的慢，導緻2在資料庫是最新值，而設定為1的後更新了緩存。緩存就和資料庫不一緻了。

但隻是記住删除代替更新不太夠。如果先删除緩存再更新資料庫，其他請求可能會把資料庫老的值再加載到緩存中。記得之前有人介紹緩存還有三大種模式：Cache-Aside、Read-Through/Write-Through、Write-Behind。

Cache-Aside就是先更新資料庫再删除緩存資料，可以避免上面提到的持續髒讀的問題，頂多就是更新資料庫的那一小段時間有更新延遲可見。我們給Cache-Aside起個中文名，叫經典模式。

Read-Through/Write-Through就是資料以緩存為準，資料庫的操作是緩存發起的。Read-Through是在讀資料時發現緩存過期了，那緩存自己去資料庫加載新的資料，讀資料還是讀取緩存值。Write-Through寫資料時調用方隻負責寫緩存，緩存自己去同步更新資料庫。Read-Through/Write-Through一般配合使用。

Write-Behind和Write-Through的差別是雖然都是是寫資料時調用方隻負責寫緩存，但是Write-Behind緩存自己去異步更新資料庫。

因為Read-Through/Write-Through、Write-Behind都是以緩存為準，緩存不可靠，是以還是推薦經典模式。

後記

一些朋友問我一邊上班一邊寫文章哪有那麼多時間呀。細心的朋友可能會發現我的文章一般是周末或者周一，再不就是節假日或者哪天失眠了發出來。因為内容都是非上班時間寫的，但是每次下筆腹稿都是提前打好的。個人意見哈，作為架構師，很多人都會形成随時随地為工作思考和總結的習慣。是以很多人看着下班很早，人家回家路上，曬太陽的時候……未必沒在想工作的事情。

架構師三件占時間的事：會議、評審和演講。對應有三大難：提出有水準的問題、做出有水準的總結和建議、做出有水準的回答。是以每天有很多的腹稿要打。腹稿按照一定的架構結構整理就是文章。

如果大家都架構師的三大難有興趣，我可以舉一些具體的示例和解決方法。大家投票吧，如果在看超過10個，我就寫這個。