一、需求緣起

明明架構要求高可用，為何系統中還會存在單點？

回答：單點master的設計，會大大簡化系統設計，何況有時候避免不了單點

在哪些場景中會存在單點？先來看一下一個典型網際網路高可用架構。

典型網際網路高可用架構：

（1）客戶端層，這一層是瀏覽器或者APP，第一步先訪問DNS-server，由域名拿到nginx的外網IP

（2）負載均衡層，nginx是整個服務端的入口，負責反向代理與負載均衡工作

（3）站點層，web-server層，典型的是tomcat或者apache

（4）服務層，service層，典型的是dubbo或者thrift等提供RPC呼叫的後端服務

（5）資料層

在這個網際網路架構中，站點層、服務層、資料庫的從庫都可以通過冗餘的方式來保證高可用，但至少

（1）nginx層是一個潛在的單點

（2）資料庫寫庫master也是一個潛在的單點

再舉一個GFS（Google File System）架構的例子。

GFS的系統架構裡主要有這麼幾種角色：

（1）client，就是發起檔案讀寫的呼叫端

（2）master，這是一個單點服務，它有全域性事業，掌握檔案元資訊

（3）chunk-server，實際儲存檔案額伺服器

這個系統裡，master也是一個單點的服務，Map-reduce系統裡也有類似的全域性協調的master單點角色。

系統架構設計中，像nginx，db-master，gfs-master這樣的單點服務，會存在什麼問題，有什麼方案來優化呢，這是本文要討論的問題。

二、單點架構存在的問題

單點系統一般來說存在兩個很大的問題：

（1）非高可用：既然是單點，master一旦發生故障，服務就會受到影響

（2）效能瓶頸：既然是單點，不具備良好的擴充套件性，服務效能總有一個上限，這個單點的效能上限往往就是整個系統的效能上限

接下來，就看看有什麼優化手段可以優化上面提到的兩個問題

三、shadow-master解決單點高可用問題

shadow-master是一種很常見的解決單點高可用問題的技術方案。

“影子master”，顧名思義，服務正常時，它只是單點master的一個影子，在master出現故障時，shadow-master會自動變成master，繼續提供服務。

shadow-master它能夠解決高可用的問題，並且故障的轉移是自動的，不需要人工介入，但不足是它使服務資源的利用率降為了50%，業內經常使用keepalived+vip的方式實現這類單點的高可用。

以GFS的master為例，master正常時：

（1）client會連線正常的master，shadow-master不對外提供服務

（2）master與shadow-master之間有一種存活探測機制

（3）master與shadow-master有相同的虛IP（virtual-IP）

當發現master異常時：

shadow-master會自動頂上成為master，虛IP機制可以保證這個過程對呼叫方是透明的

除了GFS與MapReduce系統中的主控master，nginx亦可用類似的方式保證高可用，資料庫的主庫master（主庫）亦可用類似的方式來保證高可用，只是細節上有些地方要注意：

傳統的一主多從，讀寫分離的db架構，只能保證讀庫的高可用，是無法保證寫庫的高可用的，要想保證寫庫的高可用，也可以使用上述的shadow-master機制：

（1）兩個主庫設定相互同步的雙主模式

（2）平時只有一個主庫提供服務，言下之意，shadow-master不會往master同步資料

（3）異常時，虛IP漂移到另一個主庫，shadow-master變成主庫繼續提供服務

需要說明的是，由於資料庫的特殊性，資料同步需要時延，如果資料還沒有同步完成，流量就切到了shadow-master，可能引起小部分資料的不一致。

四、減少與單點的互動，是存在單點的系統優化的核心方向

既然知道單點存在效能上限，單點的效能（例如GFS中的master）有可能成為系統的瓶頸，那麼，減少與單點的互動，便成了存在單點的系統優化的核心方向。

怎麼來減少與單點的互動，這裡提兩種常見的方法。

批量寫

批量寫是一種常見的提升單點效能的方式。

例如一個利用資料庫寫單點生成做“ID生成器”的例子：

（1）業務方需要ID

（2）利用資料庫寫單點的auto increament id來生成和返回ID

這是一個很常見的例子，很多公司也就是這麼生成ID的，它利用了資料庫寫單點的特性，方便快捷，無額外開發成本，是一個非常帥氣的方案。

潛在的問題是：生成ID的併發上限，取決於單點資料庫的寫效能上限。

如何提升效能呢？批量寫

（1）中間加一個服務，每次從資料庫拿出100個id

（2）業務方需要ID

（3）服務直接返回100個id中的1個，100個分配完，再訪問資料庫

這樣一來，每分配100個才會寫資料庫一次，分配id的效能可以認為提升了100倍。

客戶端快取

客戶端快取也是一種降低與單點互動次數，提升系統整體效能的方法。

還是以GFS檔案系統為例：

（1）GFS的呼叫客戶端client要訪問shenjian.txt，先查詢本地快取，miss了

（2）client訪問master問說檔案在哪裡，master告訴client在chunk3上

（3）client把shenjian.txt存放在chunk3上記錄到本地的快取，然後進行檔案的讀寫操作

（4）未來client要訪問檔案，從本地快取中查詢到對應的記錄，就不用再請求master了，可以直接訪問chunk-server。如果檔案發生了轉移，chunk3返回client說“檔案不在我這兒了”，client再訪問master，詢問檔案所在的伺服器。

根據經驗，這類快取的命中非常非常高，可能在99.9%以上（因為檔案的自動遷移是小概率事件），這樣與master的互動次數就降低了1000倍。

五、水平擴充套件是提升單點系統性能的好方案

無論怎麼批量寫，客戶端快取，單點畢竟是單機，還是有效能上限的。

想方設法水平擴充套件，消除系統單點，理論上才能夠無限的提升系統系統。

以nginx為例，如何來進行水平擴充套件呢？

第一步的DNS解析，只能返回一個nginx外網IP麼？答案顯然是否定的，“DNS輪詢”技術支援DNS-server返回不同的nginx外網IP，這樣就能實現nginx負載均衡層的水平擴充套件。

DNS-server部分，一個域名可以配置多個IP，每次DNS解析請求，輪詢返回不同的IP，就能實現nginx的水平擴充套件，擴充負載均衡層的整體效能。

資料庫單點寫庫也是同樣的道理，在資料量很大的情況下，可以通過水平拆分，來提升寫入效能。

遺憾的是，並不是所有的業務場景都可以水平拆分，例如秒殺業務，商品的條數可能不多，資料庫的資料量不大，就不能通過水平拆分來提升秒殺系統的整體寫效能（總不能一個庫100條記錄吧？）。

六、總結

今天的話題就討論到這裡，內容很多，佔用大家寶貴的時間深表內疚，估計大部分都記不住，至少記住這幾個點吧：

（1）單點系統存在的問題：可用性問題，效能瓶頸問題

（2）shadow-master是一種常見的解決單點系統可用性問題的方案

（3）減少與單點的互動，是存在單點的系統優化的核心方向，常見方法有批量寫，客戶端快取

原文連結:

（4）水平擴充套件也是提升單點系統性能的好方案