- 應用層用負載均衡伺服器，能夠監測伺服器的可用性，把不可能的踢出集群
- 服務層使用分布式呼叫框架dubbo
- 資料庫使用同步複製，實現資料冗餘。
- 還要考慮公升級發布引起的宕機
整體來說就是冗餘，故障轉移，使用分布式呼叫框架。
- 分級管理 0級，1級。更重要的服務，使用更好的裝置
- 超時設定 不超時會長時間占用伺服器資源。 可以設定超時策略，重試，還是轉移
- 非同步呼叫
- 服務降級 高併發時，可以
拒絕服務。 隨機拒絕部分請求
關閉功能。關閉部分不需要的功能。雙十一就是這樣幹的
- 冪等性設計 針對於重試機制。不會出現下兩個訂單的情況
資料庫高可用使用複製備份和故障轉移解決
快取的高可用作者認為應該使用集群分布式快取，單點失效只是小部分失效不會造成資料庫太大的壓力
拂去耐受性(可以線性伸縮)，可用性(隨時可讀寫)，一致性(所有應用訪問得到相同的資料)。無法同時滿足。
大型**可能放棄一定的一致性。把一致性細分：
- 強一致性 各個副本總是一致的
- 資料使用者一致 保證終端使用者訪問時，通過糾錯和校驗，確定乙個一致且正確的資料返回給使用者。
- 資料最終一致性 同一使用者連續訪問結果不同。 但是系統經過一段時間能夠自我恢復和修正。
應該做到使用者一致性
冷備：無法保證最終一致性和可用性(因為恢復時間太多)
熱備：- 非同步熱備 只寫主儲存區。 非同步執行緒同步寫從儲存區
- 同步熱備 同時寫主備連個儲存區。mysql支援半同步，保證至少有乙個備寫完。
讀寫分離也是基於資料備份
重新路由的過程
- 失效確認 心跳檢測和應用程式訪問失敗報告 一般訪問失敗了還是需要再次發一次心跳，防止誤判。
- 訪問轉移 重新路由，如果是對等的，直接路由就行了。但是如果是不對等的，就要根據路由演算法，重新算資料等等。
- 資料恢復 轉移之後修復宕機的服務，然後重新加入集群
使用者行為日誌
使用者的作業系統，瀏覽器，ip位址，訪問路徑，頁面停留時間等，用於分析使用者行為，優化**設計，個性化營銷與推薦。
伺服器效能監控
系統load,記憶體，磁碟，io。等進行預警。 目前的開源工具是ganglia
報告， 設定閾值，進行告警
採集之後可以對系統效能評估，集群規模伸縮性**，進行風險預警，自動負載調整等。
主要用來做如下的功能： 系統報警，失效轉移，自動優雅降級
架構 筆記二 架構設計的目的
首先要明白的是，架構就是一種設計，一種設計思想。因為框架很重要，所以要做框架設計 正確的廢話 不是每個系統都要做框架設計嗎 知其然不知其所以然 公司流程要求系統開發過程中必須有架構設計 捨本逐末 為了高效能 高可用 可擴充套件，所以要做框架設計 畫蛇添足 架構也是為了應對軟體系統複雜度而提出的乙個解...
Web架構設計的幾個心得
一，不要過度設計 never over design 這是乙個常常被提及的話題，但是只要想想你的架構裡有多少功能是根本沒有用到，或者最後廢棄的，就能明白其重要性了，初涉架構設計，往往傾向於設計大而全的架構，希望設計出具有無比擴充套件性，能適應一 切需求的增長的架構。web開發領域是個非常動態的過程，...
java web系統架構設計需要解決的幾個問題
1.整體架構的選擇，是選擇重量級架構還是pojo輕量級架構。2.系統建模，是選擇過程式設計還是物件導向的設計。過程式設計指的是業務邏輯層只提供乙個service的介面和實現 物件導向設計指的是採用domain model模式，對整個系統進行整體的物件建模和設計。3.怎樣訪問資料庫，是選擇jdbc的方...