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