引子

 上篇《架構師之路-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個，我就寫這個，

推薦閱讀

• 到底多大才算高并發？

• Elasticsearch實戰-磁盤IO被打滿

• 四種快取的避坑總結

• 架構-穩定性建設邏輯問題實戰總結

• 代碼榮辱觀-以運用風格為榮，以隨意編碼為恥

   

標籤：架構設計

上一篇：Spring---IoC（控制反轉）原理學習筆記【全】

下一篇：架構師之路-redis集群決議