架構師之路-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個，我就寫這個。
推薦閱讀
