絮叨

上一期因為是在雙十一一直在熬夜的大環境下完成的，所以我自己覺得質量明顯沒之前的好，我這不一睡好就加班加點準備補償大家，來點乾貨。（熬夜太容易感冒了，這次點個贊別白嫖了！）

順帶提一嘴，我把我準備寫啥畫了一個思維導圖，以後總不能每篇都放個賊大的圖吧，就開源到了我的GitHub，大家有興趣可以去完善和Star。

這篇我就先放出來大家看看，感覺還是差點意思，等大家完善了。

回望過去

上一期吊打系列我們提到了Redis相關的一些知識，還沒看的小夥伴可以回顧一下

• 《吊打面試官》系列-Redis基礎
• 《吊打面試官》系列-快取雪崩、擊穿、穿透
• 《吊打面試官》系列-Redis哨兵、持久化、主從、手撕LRU
• 《吊打面試官》系列-Redis終章-凜冬將至、FPX-新王登基

這期我就從快取到一些常見的問題講一下，有一些我是之前提到過的，不過可能大部分仔是第一次看，我就重複發一下。

快取知識點

快取有哪些型別？

快取是高併發場景下提高熱點資料訪問效能的一個有效手段，在開發專案時會經常使用到。

快取的型別分為：本地快取、分散式快取和多級快取。

本地快取：

本地快取就是在程式的記憶體中進行快取，比如我們的 JVM 堆中，可以用 LRUMap 來實現，也可以使用 Ehcache 這樣的工具來實現。

本地快取是記憶體訪問，沒有遠端互動開銷，效能最好，但是受限於單機容量，一般快取較小且無法擴充套件。

分散式快取：

分散式快取可以很好得解決這個問題。

分散式快取一般都具有良好的水平擴充套件能力，對較大資料量的場景也能應付自如。缺點就是需要進行遠端請求，效能不如本地快取。

多級快取：

為了平衡這種情況，實際業務中一般採用多級快取，本地快取只儲存訪問頻率最高的部分熱點資料，其他的熱點資料放在分散式快取中。

在目前的一線大廠中，這也是最常用的快取方案，單考單一的快取方案往往難以撐住很多高併發的場景。

淘汰策略

不管是本地快取還是分散式快取，為了保證較高效能，都是使用記憶體來儲存資料，由於成本和記憶體限制，當儲存的資料超過快取容量時，需要對快取的資料進行剔除。

一般的剔除策略有 FIFO 淘汰最早資料、LRU 剔除最近最少使用、和 LFU 剔除最近使用頻率最低的資料幾種策略。

• noeviction:返回錯誤當記憶體限制達到並且客戶端嘗試執行會讓更多記憶體被使用的命令（大部分的寫入指令，但DEL和幾個例外）

• allkeys-lru: 嘗試回收最少使用的鍵（LRU），使得新新增的資料有空間存放。

• volatile-lru: 嘗試回收最少使用的鍵（LRU），但僅限於在過期集合的鍵,使得新新增的資料有空間存放。

• allkeys-random: 回收隨機的鍵使得新新增的資料有空間存放。

• volatile-random: 回收隨機的鍵使得新新增的資料有空間存放，但僅限於在過期集合的鍵。

• volatile-ttl: 回收在過期集合的鍵，並且優先回收存活時間（TTL）較短的鍵,使得新新增的資料有空間存放。

  如果沒有鍵滿足回收的前提條件的話，策略volatile-lru, volatile-random以及volatile-ttl就和noeviction 差不多了。

其實在大家熟悉的LinkedHashMap中也實現了Lru演算法的，實現如下：

當容量超過100時，開始執行LRU策略：將最近最少未使用的 TimeoutInfoHolder 物件 evict 掉。

真實面試中會讓你寫LUR演算法，你可別搞原始的那個，那真TM多，寫不完的，你要麼懟上面這個，要麼懟下面這個，找一個資料結構實現下Java版本的LRU還是比較容易的，知道啥原理就好了。

Memcache

注意後面會把 Memcache 簡稱為 MC。

先來看看 MC 的特點：

• MC 處理請求時使用多執行緒非同步 IO 的方式，可以合理利用 CPU 多核的優勢，效能非常優秀；
• MC 功能簡單，使用記憶體儲存資料；
• MC 的記憶體結構以及鈣化問題我就不細說了，大家可以檢視官網瞭解下；
• MC 對快取的資料可以設定失效期，過期後的資料會被清除；
• 失效的策略採用延遲失效，就是當再次使用資料時檢查是否失效；
• 當容量存滿時，會對快取中的資料進行剔除，剔除時除了會對過期 key 進行清理，還會按 LRU 策略對資料進行剔除。

另外，使用 MC 有一些限制，這些限制在現在的網際網路場景下很致命，成為大家選擇Redis、MongoDB的重要原因：

• key 不能超過 250 個位元組；
• value 不能超過 1M 位元組；
• key 的最大失效時間是 30 天；
• 只支援 K-V 結構，不提供持久化和主從同步功能。

Redis

先簡單說一下 Redis 的特點，方便和 MC 比較。

• 與 MC 不同的是，Redis 採用單執行緒模式處理請求。這樣做的原因有 2 個：一個是因為採用了非阻塞的非同步事件處理機制；另一個是快取資料都是記憶體操作 IO 時間不會太長，單執行緒可以避免執行緒上下文切換產生的代價。
• Redis 支援持久化，所以 Redis 不僅僅可以用作快取，也可以用作 NoSQL 資料庫。
• 相比 MC，Redis 還有一個非常大的優勢，就是除了 K-V 之外，還支援多種資料格式，例如 list、set、sorted set、hash 等。
• Redis 提供主從同步機制，以及 Cluster 叢集部署能力，能夠提供高可用服務。

詳解 Redis

Redis 的知識點結構如下圖所示。

功能

來看 Redis 提供的功能有哪些吧！

我們先看基礎型別：

String：

String 型別是 Redis 中最常使用的型別，內部的實現是通過 SDS（Simple Dynamic String ）來儲存的。SDS 類似於 Java 中的 ArrayList，可以通過預分配冗餘空間的方式來減少記憶體的頻繁分配。

這是最簡單的型別，就是普通的 set 和 get，做簡單的 KV 快取。

但是真實的開發環境中，很多仔可能會把很多比較複雜的結構也統一轉成String去儲存使用，比如有的仔他就喜歡把物件或者List轉換為JSONString進行儲存，拿出來再反序列話啥的。

我在這裡就不討論這樣做的對錯了，但是我還是希望大家能在最合適的場景使用最合適的資料結構，物件找不到最合適的但是型別可以選最合適的嘛，之後別人接手你的程式碼一看這麼規範，誒這小夥子有點東西呀，看到你啥都是用的String，垃圾！

好了這些都是題外話了，道理還是希望大家記在心裡，習慣成自然嘛，小習慣成就你。

String的實際應用場景比較廣泛的有：

• 快取功能：String字串是最常用的資料型別，不僅僅是Redis，各個語言都是最基本型別，因此，利用Redis作為快取，配合其它資料庫作為儲存層，利用Redis支援高併發的特點，可以大大加快系統的讀寫速度、以及降低後端資料庫的壓力。

• 計數器：許多系統都會使用Redis作為系統的實時計數器，可以快速實現計數和查詢的功能。而且最終的資料結果可以按照特定的時間落地到資料庫或者其它儲存介質當中進行永久儲存。

• 共享使用者Session：使用者重新重新整理一次介面，可能需要訪問一下資料進行重新登入，或者訪問頁面快取Cookie，但是可以利用Redis將使用者的Session集中管理，在這種模式只需要保證Redis的高可用，每次使用者Session的更新和獲取都可以快速完成。大大提高效率。

Hash：

這個是類似 Map 的一種結構，這個一般就是可以將結構化的資料，比如一個物件（前提是這個物件沒巢狀其他的物件）給快取在 Redis 裡，然後每次讀寫快取的時候，可以就操作 Hash 裡的某個欄位。

但是這個的場景其實還是多少單一了一些，因為現在很多物件都是比較複雜的，比如你的商品物件可能裡面就包含了很多屬性，其中也有物件。我自己使用的場景用得不是那麼多。

List：

List 是有序列表，這個還是可以玩兒出很多花樣的。

比如可以通過 List 儲存一些列表型的資料結構，類似粉絲列表、文章的評論列表之類的東西。

比如可以通過 lrange 命令，讀取某個閉區間內的元素，可以基於 List 實現分頁查詢，這個是很棒的一個功能，基於 Redis 實現簡單的高效能分頁，可以做類似微博那種下拉不斷分頁的東西，效能高，就一頁一頁走。

比如可以搞個簡單的訊息佇列，從 List 頭懟進去，從 List 屁股那裡弄出來。

List本身就是我們在開發過程中比較常用的資料結構了，熱點資料更不用說了。

• 訊息佇列：Redis的連結串列結構，可以輕鬆實現阻塞佇列，可以使用左進右出的命令組成來完成佇列的設計。比如：資料的生產者可以通過Lpush命令從左邊插入資料，多個資料消費者，可以使用BRpop命令阻塞的“搶”列表尾部的資料。

• 文章列表或者資料分頁展示的應用。

  比如，我們常用的部落格網站的文章列表，當使用者量越來越多時，而且每一個使用者都有自己的文章列表，而且當文章多時，都需要分頁展示，這時可以考慮使用Redis的列表，列表不但有序同時還支援按照範圍內獲取元素，可以完美解決分頁查詢功能。大大提高查詢效率。

Set：

Set 是無序集合，會自動去重的那種。

直接基於 Set 將系統裡需要去重的資料扔進去，自動就給去重了，如果你需要對一些資料進行快速的全域性去重，你當然也可以基於 JVM 記憶體裡的 HashSet 進行去重，但是如果你的某個系統部署在多臺機器上呢？得基於Redis進行全域性的 Set 去重。

可以基於 Set 玩兒交集、並集、差集的操作，比如交集吧，我們可以把兩個人的好友列表整一個交集，看看倆人的共同好友是誰？對吧。

反正這些場景比較多，因為對比很快，操作也簡單，兩個查詢一個Set搞定。

Sorted Set：

Sorted set 是排序的 Set，去重但可以排序，寫進去的時候給一個分數，自動根據分數排序。

有序集合的使用場景與集合類似，但是set集合不是自動有序的，而Sorted set可以利用分數進行成員間的排序，而且是插入時就排序好。所以當你需要一個有序且不重複的集合列表時，就可以選擇Sorted set資料結構作為選擇方案。

• 排行榜：有序集合經典使用場景。例如視訊網站需要對使用者上傳的視訊做排行榜，榜單維護可能是多方面：按照時間、按照播放量、按照獲得的贊數等。

• 用Sorted Sets來做帶權重的佇列，比如普通訊息的score為1，重要訊息的score為2，然後工作執行緒可以選擇按score的倒序來獲取工作任務。讓重要的任務優先執行。

  微博熱搜榜，就是有個後面的熱度值，前面就是名稱

高階用法：

Bitmap :

點陣圖是支援按 bit 位來儲存資訊，可以用來實現 布隆過濾器（BloomFilter）；

HyperLogLog:

供不精確的去重計數功能，比較適合用來做大規模資料的去重統計，例如統計 UV；

Geospatial:

可以用來儲存地理位置，並作位置距離計算或者根據半徑計算位置等。有沒有想過用Redis來實現附近的人？或者計算最優地圖路徑？

這三個其實也可以算作一種資料結構，不知道還有多少朋友記得，我在夢開始的地方，Redis基礎中提到過，你如果只知道五種基礎型別那隻能拿60分，如果你能講出高階用法，那就覺得你有點東西。

pub/sub：

功能是訂閱釋出功能，可以用作簡單的訊息佇列。

Pipeline：

可以批量執行一組指令，一次性返回全部結果，可以減少頻繁的請求應答。

Lua：

Redis 支援提交 Lua 指令碼來執行一系列的功能。

我在前電商老東家的時候，秒殺場景經常使用這個東西，講道理有點香，利用他的原子性。

話說你們想看秒殺的設計麼？我記得我面試好像每次都問啊，想看的直接點贊後評論秒殺吧。

事務：

最後一個功能是事務，但 Redis 提供的不是嚴格的事務，Redis 只保證序列執行命令，並且能保證全部執行，但是執行命令失敗時並不會回滾，而是會繼續執行下去。

持久化

Redis 提供了 RDB 和 AOF 兩種持久化方式，RDB 是把記憶體中的資料集以快照形式寫入磁碟，實際操作是通過 fork 子程式執行，採用二進位制壓縮儲存；AOF 是以文字日誌的形式記錄 Redis 處理的每一個寫入或刪除操作。

RDB 把整個 Redis 的資料儲存在單一檔案中，比較適合用來做災備，但缺點是快照儲存完成之前如果當機，這段時間的資料將會丟失，另外儲存快照時可能導致服務短時間不可用。

AOF 對日誌檔案的寫入操作使用的追加模式，有靈活的同步策略，支援每秒同步、每次修改同步和不同步，缺點就是相同規模的資料集，AOF 要大於 RDB，AOF 在執行效率上往往會慢於 RDB。

細節的點大家去高可用這章看，特別是兩者的優缺點，以及怎麼抉擇。

《吊打面試官》系列-Redis哨兵、持久化、主從、手撕LRU

高可用

來看 Redis 的高可用。Redis 支援主從同步，提供 Cluster 叢集部署模式，通過 Sentine l哨兵來監控 Redis 主伺服器的狀態。當主掛掉時，在從節點中根據一定策略選出新主，並調整其他從 slaveof 到新主。

選主的策略簡單來說有三個：

• slave 的 priority 設定的越低，優先順序越高；
• 同等情況下，slave 複製的資料越多優先順序越高；
• 相同的條件下 runid 越小越容易被選中。

在 Redis 叢集中，sentinel 也會進行多例項部署，sentinel 之間通過 Raft 協議來保證自身的高可用。

Redis Cluster 使用分片機制，在內部分為 16384 個 slot 插槽，分佈在所有 master 節點上，每個 master 節點負責一部分 slot。資料操作時按 key 做 CRC16 來計算在哪個 slot，由哪個 master 進行處理。資料的冗餘是通過 slave 節點來保障。

哨兵

哨兵必須用三個例項去保證自己的健壯性的，哨兵+主從並不能保證資料不丟失，但是可以保證叢集的高可用。

為啥必須要三個例項呢？我們先看看兩個哨兵會咋樣。

master當機了 s1和s2兩個哨兵只要有一個認為你當機了就切換了，並且會選舉出一個哨兵去執行故障，但是這個時候也需要大多數哨兵都是執行的。

那這樣有啥問題呢？M1當機了，S1沒掛那其實是OK的，但是整個機器都掛了呢？哨兵就只剩下S2個裸屌了，沒有哨兵去允許故障轉移了，雖然另外一個機器上還有R1，但是故障轉移就是不執行。

經典的哨兵叢集是這樣的：

M1所在的機器掛了，哨兵還有兩個，兩個人一看他不是掛了嘛，那我們就選舉一個出來執行故障轉移不就好了。

暖男我，小的總結下哨兵元件的主要功能：

• 叢集監控：負責監控 Redis master 和 slave 程式是否正常工作。
• 訊息通知：如果某個 Redis 例項有故障，那麼哨兵負責傳送訊息作為報警通知給管理員。
• 故障轉移：如果 master node 掛掉了，會自動轉移到 slave node 上。
• 配置中心：如果故障轉移發生了，通知 client 客戶端新的 master 地址。

主從

提到這個，就跟我前面提到的資料持久化的RDB和AOF有著比密切的關係了。

我先說下為啥要用主從這樣的架構模式，前面提到了單機QPS是有上限的，而且Redis的特性就是必須支撐讀高併發的，那你一臺機器又讀又寫，這誰頂得住啊，不當人啊！但是你讓這個master機器去寫，資料同步給別的slave機器，他們都拿去讀，分發掉大量的請求那是不是好很多，而且擴容的時候還可以輕鬆實現水平擴容。

你啟動一臺slave 的時候，他會傳送一個psync命令給master ，如果是這個slave第一次連線到master，他會觸發一個全量複製。master就會啟動一個執行緒，生成RDB快照，還會把新的寫請求都快取在記憶體中，RDB檔案生成後，master會將這個RDB傳送給slave的，slave拿到之後做的第一件事情就是寫進本地的磁碟，然後載入進記憶體，然後master會把記憶體裡面快取的那些新命名都發給slave。

我發出來之後來自CSDN的網友：Jian_Shen_Zer 問了個問題：

主從同步的時候，新的slaver進來的時候用RDB，那之後的資料呢？有新的資料進入master怎麼同步到slaver啊

敖丙答：笨，AOF嘛，增量的就像MySQL的Binlog一樣，把日誌增量同步給從服務就好了

key 失效機制

Redis 的 key 可以設定過期時間，過期後 Redis 採用主動和被動結合的失效機制，一個是和 MC 一樣在訪問時觸發被動刪除，另一種是定期的主動刪除。

定期+惰性+記憶體淘汰

快取常見問題

快取更新方式

這是決定在使用快取時就該考慮的問題。

快取的資料在資料來源發生變更時需要對快取進行更新，資料來源可能是 DB，也可能是遠端服務。更新的方式可以是主動更新。資料來源是 DB 時，可以在更新完 DB 後就直接更新快取。

當資料來源不是 DB 而是其他遠端服務，可能無法及時主動感知資料變更，這種情況下一般會選擇對快取資料設定失效期，也就是資料不一致的最大容忍時間。

這種場景下，可以選擇失效更新，key 不存在或失效時先請求資料來源獲取最新資料，然後再次快取，並更新失效期。

但這樣做有個問題，如果依賴的遠端服務在更新時出現異常，則會導致資料不可用。改進的辦法是非同步更新，就是當失效時先不清除資料，繼續使用舊的資料，然後由非同步執行緒去執行更新任務。這樣就避免了失效瞬間的空窗期。另外還有一種純非同步更新方式，定時對資料進行分批更新。實際使用時可以根據業務場景選擇更新方式。

資料不一致

第二個問題是資料不一致的問題，可以說只要使用快取，就要考慮如何面對這個問題。快取不一致產生的原因一般是主動更新失敗，例如更新 DB 後，更新 Redis 因為網路原因請求超時；或者是非同步更新失敗導致。

解決的辦法是，如果服務對耗時不是特別敏感可以增加重試；如果服務對耗時敏感可以通過非同步補償任務來處理失敗的更新，或者短期的資料不一致不會影響業務，那麼只要下次更新時可以成功，能保證最終一致性就可以。

快取穿透

快取穿透。產生這個問題的原因可能是外部的惡意攻擊，例如，對使用者資訊進行了快取，但惡意攻擊者使用不存在的使用者id頻繁請求介面，導致查詢快取不命中，然後穿透 DB 查詢依然不命中。這時會有大量請求穿透快取訪問到 DB。

解決的辦法如下。

1. 對不存在的使用者，在快取中儲存一個空物件進行標記，防止相同 ID 再次訪問 DB。不過有時這個方法並不能很好解決問題，可能導致快取中儲存大量無用資料。
2. 使用 BloomFilter 過濾器，BloomFilter 的特點是存在性檢測，如果 BloomFilter 中不存在，那麼資料一定不存在；如果 BloomFilter 中存在，實際資料也有可能會不存在。非常適合解決這類的問題。

快取擊穿

快取擊穿，就是某個熱點資料失效時，大量針對這個資料的請求會穿透到資料來源。

解決這個問題有如下辦法。

1. 可以使用互斥鎖更新，保證同一個程式中針對同一個資料不會併發請求到 DB，減小 DB 壓力。
2. 使用隨機退避方式，失效時隨機 sleep 一個很短的時間，再次查詢，如果失敗再執行更新。
3. 針對多個熱點 key 同時失效的問題，可以在快取時使用固定時間加上一個小的隨機數，避免大量熱點 key 同一時刻失效。

快取雪崩

快取雪崩，產生的原因是快取掛掉，這時所有的請求都會穿透到 DB。

解決方法：

1. 使用快速失敗的熔斷策略，減少 DB 瞬間壓力；
2. 使用主從模式和叢集模式來儘量保證快取服務的高可用。

實際場景中，這兩種方法會結合使用。

老朋友都知道為啥我沒有大篇幅介紹這個幾個點了吧，我在之前的文章實在是寫得太詳細了，忍不住點贊那種，我這裡就不做重複拷貝了。

• 《吊打面試官》系列-Redis基礎
• 《吊打面試官》系列-快取雪崩、擊穿、穿透
• 《吊打面試官》系列-Redis哨兵、持久化、主從、手撕LRU
• 《吊打面試官》系列-Redis終章凜冬將至、FPX新王登基

考點與加分項

拿筆記一下！

考點

面試的時候問你快取，主要是考察快取特性的理解，對 MC、Redis 的特點和使用方式的掌握。

• 要知道快取的使用場景，不同型別快取的使用方式，例如：

1. - 對 DB 熱點資料進行快取減少 DB 壓力；對依賴的服務進行快取，提高併發效能；

2. - 單純 K-V 快取的場景可以使用 MC，而需要快取 list、set 等特殊資料格式，可以使用 Redis；

3. - 需要快取一個使用者最近播放視訊的列表可以使用 Redis 的 list 來儲存、需要計算排行榜資料時，可以使用 Redis 的 zset 結構來儲存。

• 要了解 MC 和 Redis 的常用命令，例如原子增減、對不同資料結構進行操作的命令等。

• 瞭解 MC 和 Redis 在記憶體中的儲存結構，這對評估使用容量會很有幫助。

• 瞭解 MC 和 Redis 的資料失效方式和剔除策略，比如主動觸發的定期剔除和被動觸發延期剔除

• 要理解 Redis 的持久化、主從同步與 Cluster 部署的原理，比如 RDB 和 AOF 的實現方式與區別。

• 要知道快取穿透、擊穿、雪崩分別的異同點以及解決方案。

• 不管你有沒有電商經驗我覺得你都應該知道秒殺的具體實現，以及細節點。

• ……..

  歡迎去GitHub補充

加分項

如果想要在面試中獲得更好的表現，還應瞭解下面這些加分項。

• 是要結合實際應用場景來介紹快取的使用。例如呼叫後端服務介面獲取資訊時，可以使用本地+遠端的多級快取；對於動態排行榜類的場景可以考慮通過 Redis 的 Sorted set 來實現等等。

• 最好你有過分散式快取設計和使用經驗，例如專案中在什麼場景使用過 Redis，使用了什麼資料結構，解決哪類的問題；使用 MC 時根據預估值大小調整 McSlab 分配引數等等。

• 最好可以瞭解快取使用中可能產生的問題。比如 Redis 是單執行緒處理請求，應儘量避免耗時較高的單個請求任務，防止相互影響；Redis 服務應避免和其他 CPU 密集型的程式部署在同一機器；或者禁用 Swap 記憶體交換，防止 Redis 的快取資料交換到硬碟上，影響效能。再比如前面提到的 MC 鈣化問題等等。

• 要了解 Redis 的典型應用場景，例如，使用 Redis 來實現分散式鎖；使用 Bitmap 來實現 BloomFilter，使用 HyperLogLog 來進行 UV 統計等等。

• 知道 Redis4.0、5.0 中的新特性，例如支援多播的可持久化訊息佇列 Stream；通過 Module 系統來進行定製功能擴充套件等等。

• ……..

還是那句話歡迎去GitHub補充。

總結

這次是對我Redis系列的總結，這應該是Redis相關的最後一篇文章了，其實四篇看下來的小夥伴很多都從一知半解到了一臉懵逼，哈哈開個玩笑。

我覺得我的方式應該還好，大部分小夥伴還是比較能理解的，這篇之後我就不會寫Redis相關的文章了(秒殺看大家想看的熱度吧)，有啥問題可以微信找我，下個系列寫啥？

大家不用急，下個系列前我會發個有意思的文章，是我在公司程式碼創意大賽拿獎的文章，我覺得還是有點東西，我忍不住分享一下，順便就在那期發起投票吧哈哈。

我看到很多小夥伴都有評論說想看別的，大概蒐集了一下，還沒留言的這期趕緊喲：

掘金

愚辛 ：想看計算機基礎，網路和作業系統那些（FPX牛脾）

cherish君：講講dubbo經常遇到的面試題目，太多人喜歡問dubbo?

Java架構養成記：真的很香啊，下一期講Dubbbo（重點SPI）然後講MQ好嗎

CSDN

小殿下：看完了所有的redis篇 希望可以出ssm

部落格園

程然：Dubbo Dubbo

開源中國

linshi2019：這期明顯是趕工之作啊

敖丙：這條我回一下，鞭策我，我很喜歡，不過說實話還是希望大家理解下，我雙十一熬夜三天了，現在給你們寫的時候也是值班回家2點左右了，我一天吃飯工作時間肯定是固定的，想寫點東西就只有擠出睡覺時間了，這種產出肯定沒週末全情投入寫的來的質量高。

其實第一期看過來的小夥伴應該也知道，我在排版，還有很多文案，配圖其實我一直都有在改進的，光是名詞高亮我都要弄很久，因為怕大家看單一的黑白色調枯燥。

我是真的用心在搞，還是希望大家支援下理解下。

知乎、簡書、思否、慕課手記沒人看不知道為啥，懂行的老鐵可以跟我說一下。

我只想說你們想看的肯定都在我開頭和GITHub那個圖裡吧，問題不大，後面都會寫的。

鳴謝

最後感謝下，新浪微博的技術專家張雷。

他於2013年加入新浪微博，作為核心技術人員參與了微博服務化、混合雲等多個重點專案，是微博開源的RPC框架Motan的技術負責人，同時也負責微博的Service Mesh方案的研發與推廣，專注於高可用架構及服務中介軟體開發方向。

他負責的Motan框架每天承載著萬億級別的請求呼叫，是微博平臺服務化的基石，每次的突發熱點事件、每次的春晚流量高峰，都離不開Motan框架的支撐與保障。此外，他也多次應邀在ArchSummit、WOT、GIAC技術峰會做技術分享。

感謝他對文章部分文案提供的支援和思路。