一般採用的方法是在負載均衡機器上直接配置業務處理機器的ip地址算法
隨機選擇數據庫
hash選擇緩存
round-robin選擇:根據地址列表順序選擇服務器
權重選擇
配置高的機器分配更高的權重,權重相同的多臺機器一般按隨機或者順序的方式選擇網絡
按負載選擇併發
按鏈接選擇負載均衡
爲了保證訪問時跳出問題的機器:一般採用的方法是負載均衡機器定時和實際的業務處理機器進行心跳(ping、端口檢測或者url偵測),發現心跳失敗的機器即將其從可用地址列表中拿掉,在心跳成功後再從新加入到可用地址列表,響應返回方式:異步
響應經過負載均衡機器返回jvm
響應直接返回至請求發起方分佈式
熱備的狀況下正在對外服務的機器只有一臺,其餘機器處於standby狀態。standby機器經過心跳機制檢查對外服務機器的健康情況。當出現問題時,其中一臺standby機器即進行接管,機器間的狀態同步至其餘standby機器或者寫入一個集中存儲設備(LVS+Keepalived)
Fail Fast原則:
當主流程的任何一步出現問題時,都應快速地結束整個流程,而不是等到後續纔來處理
接口保證和對象設計嚴謹
設計具有自我保護能裏的系統
限制使用資源
限制內存的使用
集合容量過大
未釋放已經不用的對象引用
限制文件的使用
控制單個日誌文件的大小
控制寫日誌的頻率
限制網絡的使用
限制線程的使用
使用線程池
從其餘角度避免故障
設計、代碼編寫、代碼review、風險推測、測試、部署
單機報警:cpu使用率太高、某功能點失敗率太高、依賴的第三方系統連續出問題
集羣報警:集羣訪問的情況、響應情況等指標和同期或基線指標對比出現過大誤差
報警系統
日誌記錄和分析系統
Facebook的Scribe:將須要分析的數據以特殊的格式寫入日誌文件,而後經過SNMP採集方式或者同機器上agent推送方式彙報到數據蒐集服務器上,並對數據進行分析生成報表(即時報表、日報表、同期對比報表)
eBay:將要記錄和分析的數據經過消息中間件異步發送出去,而後由相應的數
據分析程序訂閱此類消息進行分析
自我修復
執行風險點應對措施
全局資源調整
功能降級
下降對資源的使用量
訪問量上漲:拆分系統及水平伸縮,一般拆分按照功能進行,例如eBay將系統拆分爲交易、商品、評價等
數據量上漲:一般採起的方法是拆分數據庫、拆分表及讀寫分離
拆分數據庫:將數據庫拆分爲用戶、交易、商品、評價
缺點:跨庫操做比較麻煩
拆分表:按時間、hash算法、取模等
缺點:跨表操做比較麻煩
讀寫分離:提供一個寫庫、多個讀庫
挑戰:如何快速地完成數據從寫庫複製到其餘讀庫
水平伸縮則是用增長機器的方法來支撐更高的訪問量
經過升級或增長單臺機器硬件來支撐訪問量及數據增加的方式,很容易達到瓶頸
一般平靜或出如今cpu或者內存上,網絡io或磁盤io出現的瓶頸記錄較低
增長cpu
但如下狀況不能解決:
鎖競爭激烈
用於支撐併發請求的線程數是固定的
單線程任務
增長內存 但如下狀況不能解決:
cache的集合大小是固定的
jvm堆內存是固定的
分表
增長cpu
經過增長機器來支撐訪問量及數據增加的方式,最佳的狀況是應用是無狀態的
廣播同步
分佈式緩存
-用戶登陸時訪問的是NodeA機器,NodeA機器在驗證經過了用戶的信息後,將用戶的信息放入分佈式緩存集羣中的某一臺機器上,當用戶登陸後訪問其餘功能進入NodeB機器時,NodeB便可從分佈式緩存集羣的某臺機器上尋找用戶的登陸信息
最簡單的方法是對用戶ID進行hash,並用此hash值與緩存集羣中的可用機器的總數進行取模
一致性hash是解決這種問題的經常使用方法
直連式存儲
網絡存儲
分佈式文件存儲
GFS中,解決方法是增長一個稱爲主服務器的單點機器,當NodeA要上傳文件時,NodeA上的GFS Client會將文件按固定大小劃分,並向主服務器提交文件名和索引信息,從而獲得要存儲的目標機器及位置,以後NodeA將數據存儲到目標及其的相應位置上。主服務器負責記錄文件和塊的命名空間、文件到塊的映射及每一個塊副本的位置。
一般採用拆分應用的方式來解決,拆分應用一般按照業務領域來劃分(商品、用戶、評價、交易等),水平伸縮後帶來的數據庫問題:數據庫鏈接池的增長,解決方案:
緩存
頁面靜態化:變得不大,且無需根據訪問用戶來展現的頁面
頁面片斷緩存:頁面中部分變化不大,且無需根據訪問用戶來展現的片斷
數據緩存:用戶信息
分庫
一般按照業務領域拆分
異步數據庫訪問
採用非阻塞異步IO方式訪問
DAL(中間件)
目前DAL開源的有Amoeba,DAL方式的另外一個好處是可透明化分庫、分表對於業務服務器帶來的影響
讀寫分離:用於寫入的庫稱爲master庫,用於讀取的庫稱爲slave庫
對稱複製:從master庫複製數據庫到全部salve庫,slave庫的數據和master庫的數據保持一致
非對稱複製:從master複製部分數據到salve,各salve庫的數據可能不一樣
多master
數據一致性的問題一般採用複製、兩階段提交、三階段提交或者google paxos來解決