單點系統架構的優化

2021-08-09 06:07:36 字數 3176 閱讀 9365

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

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

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

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

(2)負載均衡層,nginx是整個服務端的入口,負責反向**與負載均衡工作

(3)站點層,web-server層,典型的是tomcat或者apache

(4)服務層,service層,典型的是dubbo或者thrift等提供rpc呼叫的後端服務

(5)資料層,包含cache和db,典型的是主從複製讀寫分離的db架構

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

(1)nginx層是乙個潛在的單點

(2)資料庫寫庫master也是乙個潛在的單點 

二、單點架構存在的問題

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

(1)非高可用:既然是單點,master一旦發生故障,服務就會受到影響

(2)效能瓶頸:既然是單點,不具備良好的擴充套件性,服務效能總有乙個上限,這個單點的效能上限往往就是整個系統的效能上限

三、shadow-master解決單點高可用缺陷

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

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

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

master正常時:

(1)client會連線正常的master,shadow-master不對外提供服務

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

(3)master與shadow-master有相同的虛ip(virtual-ip)

當發現master異常時:

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

舉例:資料庫的主庫master(主庫)亦可用類似的方式來保證高可用,只是細節上有些地方要注意:

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

(1)兩個主庫設定相互同步的雙主模式

(2)平時只有乙個主庫提供服務,言下之意,shadow-master不會往master同步資料

(3)異常時,虛ip漂移到另乙個主庫,shadow-master變成主庫繼續提供服務

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

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

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

批量寫

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

例如乙個利用資料庫寫單點生成做「id生成器」的例子:

(1)業務方需要id

(2)利用資料庫寫單點的auto increament id來生成和返回id

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

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

如何提公升效能呢?批量寫

(1)中間加乙個服務,每次從資料庫拿出100個id

(2)業務方需要id

(3)服務直接返回100個id中的1個,100個分配完,再訪問資料庫

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

客戶端快取

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

還是以檔案系統為例:

(1)呼叫客戶端client要訪問shenjian.txt,先查詢本地快取,miss了

(2)client訪問master問說檔案在**,master告訴client在chunk3上

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

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

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

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

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

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

第一步的dns解析,只能返回乙個nginx外網ip麼?答案顯然是否定的,「dns輪詢」技術支援dns-server返回不同的nginx外網ip,這樣就能實現nginx負載均衡層的水平擴充套件。

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

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

(1)單點系統存在的問題:可用性問題,效能瓶頸問題

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

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

(4)水平擴充套件也是提公升單點系統效能的好方案

單點系統架構的優化

明明架構要求高可用,為何系統中還會存在單點?回答 單點master的設計,會大大簡化系統設計,何況有時候避免不了單點 在哪些場景中會存在單點?先來看一下乙個典型網際網路高可用架構。典型網際網路高可用架構 2 負載均衡層,nginx是整個服務端的入口,負責反向 與負載均衡工作 3 站點層,web se...

單點系統架構可用性與效能優化

單點master的設計會大大簡化系統設計,何況有時候避免不了單點。先看乙個典型網際網路高可用架構 2 負載均衡層 nginx是整個服務端的入口,負責反向 與負責均衡工作 3 站點層 web server層,典型的是tomcat或apache 4 服務層 service層,典型的是dubbo或thri...

12306系統架構優化

coolshell陳皓優化方案 原文 一 業務複雜度比對 二 瓶頸 庫存業務的操作模式基本是這樣的 1 佔住庫存 2 付款 3 扣除庫存 這個過程中,是要對資料進行加鎖的,高併發下資料的一致性保證非常之難。併發究竟有多大呢?12306的業務特點是,突然放票,大家去搶。幾十分鐘內,馬上幾千萬的訪問量,...