第二章：大型網站架構模式
2.1網站架構模式
爲了解決大型網站的高併發，海量數據處理，高可靠運行等一系列問題與挑戰，大型互聯網公司在實踐中提出許多解決方案，以實現網站的高性能，高可用，易伸縮，可擴展安全等各種技術架構目標，這些解決方案又被更多網站重複利用，從而逐漸形成網站技術架構模式。
2.1.1分層
網站分層結構：
應用層：負責具體業務和視圖展示，如網站首頁及搜索輸入和結果展示
服務層：爲應用層提供服務支持，如用戶管理服務，購物車服務等
數據層：提供數據訪問存儲服務，如數據庫，緩存，文件，搜索引擎等
2.1.2分割
分層結構是軟件橫向切分，那麼分割就是對軟件的縱向劃分。
就是隨着網站越來越大，功能越來越複雜，服務和數據處理的種類也越多，將這些不同的功能和服務分割開來，包裝成高內聚低耦合的模塊單元，一方面有助於軟件的開發和維護，另一方面。便於不同模塊的分佈式部署，提高網站的併發處理能力和功能擴展能力。
2.1.3分佈式
常見:分佈式應用和服務；分佈式靜態資源；分佈式數據和存儲；分佈式計算
此外，分佈式配置；分佈式鎖；分佈式文件系統
2.1.4集羣
多臺服務器部署相同應用，構成一個集羣，通過負載均衡設備共同對外提供服務
2.1.5緩存
CDN；反向代理；本地緩存；分佈式緩存
2.1.6異步
提高系統可用性；加快網站相應速度；消除併發訪問高峯
2.1.7冗餘
必要的數據備份，熱備份，冷備份，容災數據中心
2.1.8自動化
發佈過程自動化；自動化代碼管理；自動化測試；自動化安全檢測；自動化部署；自動化監控；自動化報警；自動化失效轉移；自動化失效恢復；自動化降級；自動化分配資源
2.1.9安全
身份驗證；通信加密；防止XSS攻擊，SQL注入進行編碼轉換。
2.2架構模式在新浪微博應用
3.1性能
性能是網站架構設計的一個重要方面。任何軟件架構設計方案都必須考慮可能會帶來的性能問題。
衡量網站性能有一系列指標，重要的有響應時間，TPS,系統性能計數器等
3.2可用性
通過冗餘手段，應用部署在多態服務器上同時訪問，數據存儲在多態服務器上面，任何一臺服務器宕機，只需把請求切換到其他服務器上即可，但有一個前提是應用服務器上不能保存請求的會話信息，否則服務器宕機，會話信息丟失，即使請求切換到其他服務器，也同樣不能完成任務。
3.3伸縮性
伸縮性是指通過不斷想集羣添加數據庫的手段來緩解不斷上升的用戶併發訪問壓力和不斷增長的數據存儲需求
3.4擴展性
添加新業務時，不需要任何改動或者很少改動既有的服務，就可以上新服務。
網站可伸縮性架構的主要手段
事件驅動架構：生產消息和消費消息通過消息隊列分開處理。
分佈式服務：將業務和可複用服務分開
3.5安全性
第四章瞬時響應:網站的高性能架構
4.1網站性能測試
4.1.1不同人員網站不同性能
4.1.2性能測試指標
1.響應時間：指應用執行一個操作需要的時間，包括請求開始到收到數據返回所需要的時間
2.併發數：指系統能夠同時處理的請求數目，也反應了系統的負載特性。
3.吞吐量：單位時間內系統處理請求的數目，體現系統的整體處理能力。TPS（每秒事務數）是吞吐量的一個常用量化標準，此外HSP（每秒http請求數）QPS（每秒查詢數）
4.性能計數器：描述服務器或操作系統性能的一些數據指標，包括System Load（系統負載），對象與線程數，內存使用CPU使用，磁盤與網絡IO等指標。
4.1.3性能測試方法
性能測試，負載測試，壓力測試，穩定性測試
4.1.5性能優化策略
1.性能分析：請求發生到處理完成之間的各個環節，檢查日誌，分析哪個環節響應時間不合理。
2.性能優化：Web前端性能優化，應用服務器性能優化，存儲服務器性能優化。
4.2Web前端性能優化
4.2.1瀏覽器訪問優化
1.減少http請求：合併CSS，合併JavaScript，合併圖片。
2.使用瀏覽器緩存
3.啓動壓縮：在服務端對文件壓縮，在瀏覽器端對文件解壓。
4.CSS放在頁面最上面，JavaScript放在頁面最下面
5.減少Cookie傳輸
4.2.2CDN加速
CDN（Content Distribute Network，內容分發網絡）的本質仍然是一個緩存，將數據緩存在離用戶最近的地方。
4.2.3反向代理
靜態內容可以被緩存在反向代理服務器上，當其他用戶啊訪問同樣的靜態資源可以直接從反向代理服務器返回給用戶。有些網站還會把動態內容頁緩存在代理 服務器上，比如熱點詞條，帖子，博客緩存，當這些動態內容失效以後，通過內部通知機制通知反向代理緩存失效反向代理會重新加載最新的動態內容再次緩 存起來。
4.3應用服務器性能優化
4.3.1分佈式緩存
網站性能優化第一定律：優先考慮使用緩存優化性能
1.緩存的基本原理：緩存是指將數據存儲在相對較高訪問速度的存儲介質上，以供系統處理。緩存既可以減少數據訪問時間，在需要計算的數據時還可以減少重複計算。
2.合理使用緩存
頻繁修改的數據：數據寫入緩存，應用還沒來得及讀取緩存數據就已經失效，數據讀寫比2：1，就是數據存入緩存在修改數據前至少可以被讀取2次纔有意義存入緩存，但是實踐中其實更高，比如微博緩存一次可能會獲得 成千上萬的讀取。
沒有熱點的訪問：不能將所有數據都存入緩存。
數據不一致與髒讀：緩存有失效時間，需要從數據庫讀取新數據。
緩存可用性：數據庫可能已經習慣有緩存的存在 ，緩存崩潰導致數據庫不能承受壓力而宕機，導致網站不可用，這就叫雪崩， 分佈式緩存可以一定程度改善緩存可用性
緩存預熱
緩存穿透：因爲不恰當的業務或者惡意攻擊持續高併發請求某個不存在的數據，由於緩存沒有存儲所以請求都會壓在數據上，會對數據庫造成很大壓力甚至崩潰，一個簡單的措施就是將不存在的數據也緩存起來（value值爲null）
3.分佈式緩存架構
JBoss Cache的需要同步的分佈式緩存，即所有緩存服務器都存相同的數據，當某臺服務器有緩存數據更新時候，會通知其他緩存進行更新或清除數據。適合企業應用不適合大型網站應用。
Memcached採用一種集中式的緩存集羣管理，也被稱作互不通信的分佈式架構
Memcached採用TCP(UDP也支持)通信
簡單的通信協議
豐富的客戶端程序
高性能網絡通信
高效內存管理（解決內存碎片）--固定空間分配，chunk大小相同的在一個slab中，存儲時根據數據size找到大於size的最小chunk進行存儲，一個chunk只能存一個數據，依然會有內存浪費。
4.3.2異步處理
使用消息隊列改善網站的擴展性。消息隊列起到很好的削峯作用。
同時由於異步處理，數據寫入消息隊列數據立馬返回給用戶，數據在後續業務校驗和寫數據庫的過程中可能會出現錯 誤，因此使用消息隊列對業務進行異步處理以後，需要適當修改業務流程進行配合，如提交訂單，訂單數據寫入消息 隊列進行異步處理，不能立即返回下單成功，需等消息隊列的消費者處理完此條消息才能返回處理結果。
【任何可以做晚點的事都可以晚點再做】
4.3.3使用集羣
4.3.4代碼優化
1.多線程
啓動線程數可參考【啓動線程數=[任務執行時間/（任務執行時間-IO等待時間）]*CPU內核數】
解決線程安全主要手段:
將對象設置成無狀態對象：對象不存在狀態，不會造成狀態不一致問題
使用局部對象：方法內創建對象
併發訪問資源時候使用鎖:通過對資源上鎖達到併發操作在此資源變爲順序操作
2.資源複用
主要形式：單例和對象池
3.數據結構
4.垃圾回收
【下一篇續：第5-8章筆記】
關注公衆號【Java成長錄】下方資源獲取即可集合獲取帶標籤的《大型網站技術架構》pdf版本
長按關注，一起進步！