高併發服務端分佈式系統設計概要（中）

======張峻崇 原創。轉載請註明出處。======

 

上篇（連接）咱們完成了在此分佈式系統中，一個group的設計。那麼接下來，咱們設計系統的其餘部分。如前文所述，咱們的業務及其數據以group爲單位，顯然在此係統中將存在many many的groups（別告訴我你的網站總共有一個業務，像咱們的「山推」，那業務是一堆一堆地），那麼由誰來管理這些groups呢？由Web過來的請求，又將如何到達指定的group，並由該group處理它的請求呢？這就是咱們要討論的問題。

        咱們引入了一個新的角色——Global Master，顧名思義，它是管理全局的一個節點，它主要完成以下工做：（1）管理系統全局配置，發送全局控制信息；（2）監控各個group的工做狀態，提供心跳服務，若發現宕機，通知該group發起分佈式選舉產生新的Group Master；（3）處理Client端首次到達的請求，找出負責處理該請求的group並將此group的信息（location）返回，則來自同一個前端請求源的該類業務請求自第二次起不須要再向Global Master查詢group信息（緩存機制）；（4）保持和Global Slave的強一致性同步，保持自身健康狀態並向全局的「心跳」服務驗證自身的狀態。

        如今咱們結合圖來逐條解釋上述工做，顯然，這個系統的完整輪廓已經初現。

 

 

        首先要明確，無論咱們的系統如何「分佈式」，總之會有至少一個最主要的節點，術語可稱爲primary node，如圖所示，咱們的系統中，這個節點叫Global Master，也許讀過GFS + Bigtable論文的同窗知道，在GFS + Bigtable裏，這樣的節點叫Config Master，雖然名稱不同，但所作的事情卻差很少。這個主要的Global Master可認爲是系統狀態健康的標誌之一，只要它在正常工做，那麼基本能夠保證整個系統的狀態是基本正常的（什麼？group或其餘結點會不正常不工做？前面已經說過，group內會經過「分佈式選舉」來保證本身組內的正常工做狀態，不要告訴我group內全部機器都掛掉了，那個機率我想要忽略它），假如Global Master不正常了，掛掉了，怎麼辦？顯然，圖中的Global Slave就派上用場了，在咱們設計的這個「山推」系統中，至少有一個Global Slave，和Global Master保持「強一致性」的徹底同步，固然，若是有不止一個Global Slave，它們也都和Global Master保持強一致性徹底同步，這樣有個好處，假如Global Master掛掉，不用停寫服務，不用進行分佈式選舉，更不會讀服務，隨便找一個Global Slave頂替Global Master工做便可。這就是強一致性最大的好處。那麼有的同窗就會問，爲何咱們以前的group，不能這麼搞，非要搞什麼最終一致性，搞什麼分佈式選舉（Paxos協議屬於既難理解又難實現的坑爹一族）呢？我告訴你，仍是壓力，壓力。咱們的系統是面向日均千萬級PV以上的網站（「山推」嘛，推特是億級PV，咱們千萬級也不過度吧），但系統的壓力主要在哪呢？細心的同窗就會發現，系統的壓力並不在Global Master，更不會在Global Slave，由於他們根本不提供數據的讀寫服務！是的，系統的壓力正是在各個group，因此group的設計纔是最關鍵的。同時，細心的同窗也發現了，因爲Global Master存放的是各個group的信息和狀態，而不是用戶存取的數據，因此它更新較少，也不能認爲讀>>寫，這是不成立的，因此，Global Slave和Global Master保持強一致性徹底同步，正是最好的選擇。因此咱們的系統，一臺Global Master和一臺Global Slave，暫時能夠知足需求了。

        好，咱們繼續。如今已經瞭解Global Master的大概用途，那麼，一個來自Client端的請求，如何到達真正的業務group去呢？在這裏，Global Master將提供「首次查詢」服務，即，新請求首次請求指定的group時，經過Global Master得到相應的group的信息，之後，Client將使用該信息直接嘗試訪問對應的group並提交請求，若是group信息已過時或是不正確，group將拒絕處理該請求並讓Client從新向Global Master請求新的group信息。顯然，咱們的系統要求Client端緩存group的信息，避免屢次重複地向Global Master查詢group信息。這裏其實又挖了許多爛坑等着咱們去跳，首先，這樣的工做模式知足基本的Ddos攻擊條件，這得經過其餘安全性措施來解決，避免group老是收到不正確的Client請求而拒絕爲其服務；其次，當出現大量「首次」訪問時，Global Master儘管只提供查詢group信息的讀服務，仍有可能不堪重負而掛掉，因此，這裏仍有很大的優化空間，比較容易想到的就是採用DNS負載均衡，由於Global Master和其Global Slave保持徹底同步，因此DNS負載均衡能夠有效地解決「首次」查詢時Global Master的壓力問題；再者，這個工做模式要求Client端緩存由Global Master查詢獲得的group的信息，萬一Client不緩存怎麼辦？呵呵，不用擔憂，Client端的API也是由咱們設計的，以後才面向Web前端。

         以後要說的，就是圖中的「Global Heartbeat」，這又是個什麼東西呢？可認爲這是一個管理Global Master和Global Slave的節點，Global Master和各個Global Slave都不停向Global Heartbeat競爭成爲Global Master，若是Global Master正常工做，按期更新其狀態並延期其得到的鎖，不然由Global Slave替換之，原理和group內的「心跳」同樣，但不一樣的是，此處Global Master和Global Slave是強一致性的徹底同步，不須要分佈式選舉。有同窗可能又要問了，假如Global Heartbeat掛掉了呢？我只能告訴你，這個很不常見，由於它沒有任何壓力，並且掛掉了必須人工干預才能修復。在GFS + Bigtable裏，這個Global Heartbeat叫作Lock Service。

 

中篇就寫到這裏吧。下篇（連接）將給出完整的系統設計並完結。

iCC Develop Center