在數(shù)學中,單元素集合是只有一個元素的集合,如{A}。在程序設計中,單例模式指的是一種設計模式,它模仿了數(shù)學概念,限制了一個類只能實例化一個對象。這種設計模式對協(xié)調資源非常有用,但程序員常為了省事而過度使用它,這個話題我們之后再討論。在系統(tǒng)架構中,單例模式,或者更恰當?shù)卣f是單例反模式,被稱為單點故障(SPOF)也就是說,當系統(tǒng)中的某個組件只有一個實例時,一旦該實例出故障,就會造成系統(tǒng)范圍的影響。
SPOF在系統(tǒng)中隨處可見,從單個的Web服務器到單個的網絡設備,但系統(tǒng)中最常見的SPOF是數(shù)據(jù)庫。其原因在于數(shù)據(jù)庫是最難擴展到多個節(jié)點上的,因此它只有一個實例。在圖9-1中,即使登錄、搜索和結賬服務器都有冗余,數(shù)據(jù)庫仍是SPOF。更精的是,所有服務池都依賴于這一個數(shù)據(jù)庫。雖然任何SPOF都不好,但數(shù)據(jù)庫SPOF的問題更大,如果數(shù)據(jù)庫速度下降或者期讀了,那么對數(shù)據(jù)庫進行同步調用的所有服務池都將受到這一事件影響。
我們常說給客戶的一句口頭禪是“一切都會出故障”。這句話適用于服務器、存儲系統(tǒng)、網絡設備和數(shù)據(jù)中心。只要你知道的,都會出故障。
雖然很多人認為數(shù)據(jù)中心是不會出故障的,但多年來,我們自己經歷了十幾次數(shù)據(jù)中心運行中斷。高可用的存儲區(qū)域網絡也是如此,雖然它們比舊的SCSI硬盤陣列可靠得多,但仍舊會出故障。
大多數(shù)解決SPOF的方法是申請另一臺硬件,如X軸擴展所示的通過克隆服務,讓每種服務都有兩個或更多個實例在運行。遺憾的是,事實并非總是如此簡單。讓我們回頭再看看編寫單例模式的步驟。雖然不是所有的單例類都不允許在多臺服務器上運行一個服務,但有些實現(xiàn)絕對會讓你免于遭受可怕的后果。較簡單的情況是,如果代碼中有一個類,用于從用戶賬戶中減去基金,用單例模式實現(xiàn)它就會讓用戶的余額免于不測,如成為負數(shù)。如果把這段代碼放在兩臺獨立的服務器上,沒有額外的控制措施或聯(lián)絡信號,則很可能會造成兩個事務同時在用戶賬戶中記人借額,從而導致錯誤或不想發(fā)生的狀況。對于這種情況,我們需要修復代碼,或者依賴外部控制來預防。但最令人滿滿意的解決方案是修復代碼,在多個主機上實現(xiàn)服務,通常我們需要快速修復SPOF。作為本原則的最后一個要點,我們接下來將討論幾個快速修復方法。
第一個方法最簡單,是使用主動/被動配置。一個服務在一臺服務器上主動運行,在另外一臺服務器上被動運行(不接收流量)。這種熱/冷配置,常被用作刪除數(shù)據(jù)庫SPOF的第一步。接下來的方法是用系統(tǒng)中的另一個組件控制數(shù)據(jù)訪問。如果SPOF是服務,那么用數(shù)據(jù)庫鎖可以控制數(shù)據(jù)的訪問。如果SPOF是數(shù)據(jù)庫,那么可以設置主一從配置,由應用控制數(shù)據(jù)訪問,寫更新操作由主數(shù)據(jù)庫完成,讀選擇操作由從數(shù)據(jù)庫完成。最后一個用于修復SPOF的配置是負載均衡器。如果Web服務器或應用服務器的一個服務是SPOF,且在代碼中不能消除,那么可以利用負載均衡器把一個用戶的請求只發(fā)送給池中的一臺服務器。這是通過會話 cookie實現(xiàn)的,即設置用戶的瀏覽器,且允許負載均衡器每次都把該用戶的請求重定向到同一個Web或應用服務器,從而形成一種一致狀態(tài)。
我們介紹了幾種消除SPOF的方法,在不能及時修改代碼的情況下可以輕松地實現(xiàn)它們。但是最后的方法最好,即修復代碼,允許網站設計服務的多個實例在不同的物理服務器上運行,從而盡可能消除SPOF。記住,“一切都會出故障”,所以當SPOF出故障時,請不要吃驚。
本文地址:http://m.murenxiang.com.cn//article/3500.html