你好呀，我是歪歪。

這期我想給大家分享一個很多人都不知道的學習網站。

就是阿里雲。

我估計有很多人看到「阿里雲」這幾個字出來的時候，就浮現出不好的感覺，心中暗喊：不好，感覺這是一個廣告。趕緊跑。

確實，從本質上來講，這是一個賣服務的網站。但是壯士請留步啊，我又不叫你去這上面買服務，我真的在這上面學到了很多有用的知識。

放心，學這些知識不要錢的。

當然了，阿里雲要是能看到我的文章，想要給我打一筆錢我也是很樂意的。

好了，話不多說，發車。

幫助中心

如果你覺得阿里雲是一個賣服務的網站，是一個讓你花錢的地方，說明你的打開方式是官方期望的打開方式。

但是如果你用我的打開方式，它就會搖身一變，變成一個免費的學習網站。

我的打開方式，就是從它的「幫助中心」進去：

//help.aliyun.com/

然後，關注它右邊導航欄的這一溜欄目。

比如，資料庫這裡，我隨便圈幾個：

再比如，中間件這裡，我也圈幾個：

當然，還有很多其他的可以看的東西，我就不一一展示了，大家感興趣自己去翻就行了。

在幫助中心裏面展示的東西，就是阿里雲能賣的服務。

而他們要賣服務，一定要有對應的文檔說明。

就是「吹牛逼」嘛，說我的服務多麼多麼好，多麼多麼穩定，多麼多少省心，有那些應用場景，巴拉巴拉巴拉…

所以去翻閱對應技術點他們提供的文檔，就是正確的打開方式。

下面我用 Redis 來舉個例子。

阿里雲 Redis 文檔

我覺得阿里雲裡面 Redis 的技術文檔是做的最好的，所以帶你看看。

//help.aliyun.com/product/26340.html

這個學習路徑裡面，就有很多值得我們關注的地方。

比如我們先看這個幾個地方的內容：

應用場景

第一個Redis 有哪些應用場景？

這個問題是不是面試的時候面試官也經常問你：Redis 在你的應用裡面是幹啥用的？

你怎麼回答？

保守一點的說，95% 的人都會說：拿來當做快取用。

確實，基本上都是拿來當個快取用用而已。但是你是不是可以補充一句：除了可以當快取用，我還知道它有其他的一下應用場景，比如：

//help.aliyun.com/document_detail/43829.html

咔咔咔，就直接把文檔上舉的例子再羅列一下，有行業，有場景，這樣的回答肯定比你乾癟癟的回答一個「快取」好吧。

災備方案

然後我們看「災備方案」這一部分：

//help.aliyun.com/document_detail/100734.html

也許你聽過「災備」這個概念，但是大多是運維人員關係的，我們作為開發其實了解的不多。

但是如果你會，那就是加分項。

阿里雲介紹了三種災備方案。

• 單可用區高可用方案，災備級別最低，主備節點部署在同一可用區中的不同機器上，當任一節點發生故障時，由高可用HA（High Availability）系統自動執行故障切換，避免單點故障引起的服務中斷。
• 同城容災方案，災備級別中等，主備節點分別部署在同一地域下兩個不同的可用區，當任一可用區因電力、網路等不可抗因素失去通訊時，高可用HA系統將執行故障切換，確保整個實例的持續可用。
• 跨地域容災方案，災備級別最高，由多個子實例構成全球分散式實例，所有子實例通過同步通道保持實時數據同步，由通道管理器負責子實例的健康狀態監測、主備切換等等異常事件的處理，適用於異地災備、異地多活、應用就近訪問、分攤負載等場景。

而單單一個災備級別最低的「單可用區高可用方案」也有多種不同的部署架構：

比如下面這個標準版-雙副本高可用架構：

它採用了雙機主從（Master-Replica）架構，高可用 HA 模組偵測到主節點故障時，會自動進行主從切換，將 Replica 提升為 Master，而原來的 Master 恢復連接後會成為新的 Replica。

這就是一個要實現高可用的最基本最簡單的架構圖。

但是這個架構的問題在於只有一個集群，要是這整個集群都掛了怎麼辦呢？

沒辦法，只有演進架構。

所以，還有集群版的雙副本高可用架構：

集群架構（雙副本）實例中的數據分片用於承載數據，每個數據分片均為雙副本（分別部署在不同機器上）高可用架構，主節點發生故障後，系統會自動進行主備切換保證服務高可用。

然後還有經常提到的讀寫分離架構：

另外的同城容災方案、跨地域容災方案我就不一一介紹了，大家自己去翻一下就行。

命令支援

在命令支援這塊，我也有新的發現：

有一些企業版才支援的命令，也就是說這是阿里對於 Redis 進行了二次開發，對某些命令進行了加強。

比如這兩個命令：

它們是幹啥的呢？

來，我問你一個問題：用 Redis 做分散式鎖的時候，解鎖用的命令是什麼？

是 DEL 命令，是的，回答的很好。

那麼解鎖的時候需要注意什麼呢？

是不是需要檢查解鎖的執行緒和加鎖的執行緒得是同一個。

你要是不明白為什麼也沒關係，官網上舉個了這麼一個例子：

• t1時刻，App1設置了分散式鎖resource_1，過期時間為3秒。
• App1由於程式慢等原因等待超過了3秒，而resource_1已經在t2時刻被釋放。
• t3時刻，App2獲得這個分散式鎖。
• App1從等待中恢復，在t4時刻運行DEL resource_1將App2持有的分散式鎖釋放了。

哦豁，不是自己加的鎖，卻把鎖給釋放了？

所以，從上述過程可以看出，一個客戶端設置的鎖，必須由自己解開。

因此客戶端需要先使用 GET 命令確認鎖是不是自己設置的，然後再使用 DEL 解鎖。

先獲取、再判斷、接著刪除，很明顯，這不是一個原子性的操作，怎麼辦？

是的，lua 腳本。

在 Redis 中通常需要用 lua 腳本來實現自鎖自解的功能，比如這樣：

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

是不是感覺有點麻煩呀？

所以，阿里自己搞了一個 CAD 命令。

加鎖邏輯還是一樣：

SET resource_1 random_value NX EX 5

解鎖就變成了這樣：

/* if (GET(resource_1) == my_random_value) DEL(resource_1) */
CAD resource_1 my_random_value

是不是簡潔了很多？

而它的底層我沒去看，但是猜也知道，就是對 lua 腳本的一個封裝。

CAS 命令是拿來續租的，可以自己去看看。

//help.aliyun.com/document_detail/146758.html

同時文中還提到了如何保障一致性的問題：

如果你理解不了「如果丟失的數據跟分散式鎖有關，則會導致鎖的機制出現問題，從而引起業務異常」這句話，也就理解不了後面說的「紅鎖」的解決方案。

那麼這裡是不是又是一個引子，讓你找到在這個體系裡面新的要學習的東西？

而關於這個點，其實我之前也寫文章解釋過《【求錘得錘的故事】Redis鎖從面試連環炮聊到神仙打架。》，你要不清楚，也可以去看看。

除此之外，你可以看到它左邊的導航欄裡面舉了好幾個例子：

這些都是自研的，但是其實一部分命令其實都是開源的，包括前面提到的 CAD 和 CAS 命令：

//github.com/alibaba/TairString/blob/main/README-CN.md

是不是又找到一個可以學習的方向？

比如有個 TairZset 命令。

我們知道，Redis 原生的 zset 主要可以用來做排行榜，但是只支援單維度的排序。

阿里搞了個 TairZset 命令，擴展了一下，就支援多維度了：

這個命令也是開源的。

性能排查與調優

//help.aliyun.com/document_detail/265988.html

這一部分的內容，簡直就是絕了。

光看標題就知道是乾貨了。

比如我舉其中的一個例子來說：

請問，Redis 的 CPU 使用率高了，你有哪些解決方案或者說是排查思路？

不知道沒有關係，這裡寫了三種。

第一種是查找並禁用高消耗命令。

高消耗命令：即時間複雜度為O(N)或更高的命令。通常情況下，命令的時間複雜度越高，在執行時會消耗較多的資源，從而導致CPU使用率上升。

由於 Redis 的特性，在執行高消耗命令時會引發排隊導致應用響應變慢。

極端情況下，甚至可能導致實例被整體阻塞，引發應用超時中斷或流量跳過快取層直接到達後端的資料庫側，引發雪崩效應。

那麼我們怎麼找到高消耗的命令呢？

這個就是它們產品提供的一個功能了：

這裡面連數據都給你截上了，基本上看的是一清二楚。

那如果我們不用它的可視化頁面，用原生的功能，怎麼做呢？

slowlog-log-slower-than 和 slowlog-max-len 這個兩個參數配置了解一下，前者是設置慢查詢的閾值，後者是存放慢查詢的記錄。

而且，就算你面試的時候說，我們是通過可視化頁面找到的高消耗命令，我也覺得沒啥問題，畢竟主要是看你有那些思路。

有思路了，找到對應的解決方案還不是手到擒來的事情。

除此之外，還有這幾個方案：

如果經過這些操作之後， CPU 的使用率還是很高怎麼辦？

在評估業務正常的情況下，加錢，加機器，升級配置。

最佳實踐

//help.aliyun.com/document_detail/163162.html

一定一定一定要去看每個技術點對應的最佳實踐這一部分。

比如在遊戲玩家積分排行榜的這個實踐中，還給你提供了一套環境以及直接可以運行的程式碼：

你只管按照步驟操作就行了。

又比如在JedisPool資源池優化的這裡面。

針對 Redis 的配置給出了說明和建議值。合理的配置能夠提升 Redis 的服務性能，降低資源開銷。

這些都是很重要的關於參數的配置。

也許你自己配置的時候，從其他項目中隨便就拷貝一個過來了，項目也跑的好好的，你甚至不知道每個參數是幹啥的。

但是在這裡，你能找到答案。

還有包括秒殺和雙十一，這些看起來很厲害的東西，這裡都有：

其他

比如在 RabbitMQ 裡面，有關於消息冪等的最佳實踐：

也有關於消息重試、延時隊列等的高級特性的描述：

比如在數字金融裡面有個這東西：

是一套在金融領域可復用的技術解決方案，而相關的技術棧的絕大部分都是開源的。

如果你之前不了解 SOFAStack 這個玩意，那麼這個地方就是你了解它的入口。

上次有個讀者問我關於 RocketMQ 的事務消息的問題，我雖然沒有用過，但是我給他發過去一個連接：

//help.aliyun.com/document_detail/43348.html

這裡面，就有他想要找的東西：

當時他問我：怎麼隨便一搜就能搜到一篇高品質的文章？

我說恰好之前看過而已。其實，我之前沒有看過。

但是我知道阿里雲上面肯定有賣 RocketMQ 服務的，那麼它這裡面大概率有這方面的資料。

所以我就上去那麼隨便一翻，就找到了。

這也是我想要把這個「學習網站」分享給你的原因，以後多一個找資料的地方，多一個學習新東西的地方，挺好的。