mysql大型網站技術架構核心原理是什么

這篇文章主要介紹“mysql大型網站技術架構核心原理是什么”，在日常操作中，相信很多人在mysql大型網站技術架構核心原理是什么問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”mysql大型網站技術架構核心原理是什么”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

一、大型網站架構演化

A.大型網站軟件系統的特點

高并發，大流量；高可用；海量數據；用戶分布廣泛，網絡情況復雜；安全環境惡劣；需求快速變更，發布頻繁；漸進式發展；

B.大型網站架構演化發展歷程

1.初始階段：一臺服務器，LNMP

2.應用服務和數據服務分離：應用服務器（CPU）；數據庫服務器（快速磁盤檢索和數據緩存）；文件服務器（大硬盤）；

3.使用緩存改善網站性能：緩存在應用服務器上的本地緩存（訪問速度快，受應用服務器內存限制，數據量有限）、遠程分布式緩存（使用集群部署大內存的服務器作為專門的緩存服務器）

4.應用服務器集群：通過負載均衡調度

5.數據庫讀寫分離

6.使用反向代理和CDN加速：CDN（部署在最近的網絡機房）、反向代理 （部署在中心機房）

7.使用分布式文件系統和分布式數據庫系統

8.使用NoSQL和搜索引擎

9.業務拆分

10.分布式服務

C.大型網站架構演化的價值觀

1.大型網站架構技術的核心價值是隨網站所需靈活應對

2.驅動大型網站技術發展的主要力量是網站的業務發展

D.網站架構設計誤區

1.一味追隨大公司的解決方案

2.為了技術而技術

3.企圖用技術解決所有問題：技術是用來解決業務問題的，而業務的問題，也可以通過業務的手段去解決

二、大型網站架構模式

模式：每一個模式描述了一個在我們周圍不斷重復發生的問題及該問題解決方案的核心。這樣，你就能一次又一次地使用該方案而不必做重復工作。模式的關鍵在于模式的可重復性。

A.網站架構模式

1.分層

• 分層：是企業應用系統中最常見的一種架構模式，將系統在橫向維度上切分成幾個部分，每個部分負責一部分相對比較單一的職責，然后通過上層對下層的依賴和調用組成一個完整的系統。
  

• 將網站軟件系統分為應用層（視圖層、業務邏輯層）、服務層（數據接口層、邏輯處理層）、數據層
  

• 可以更好地將一個龐大的軟件系統切分成不同的部分，便于分工合作開發和維護；各層之間具有一定的獨立性，只要維持調用接口不變，各層可以根據具體問題獨立深化發展而不需要其他層必須 做出相應調整。
  

2.分割

• 縱向方面進行切分。將不同的功能和服務分割開來，包裝成高內聚低耦合的模塊單元。大型網站分割的粒度可能會很小。
  

3.分布式

• 即將不同的模塊部署在不同的服務器上，通過遠程調用協同工作。意味著可以使用更多的計算機完成同樣的功能。
  

• 問題：通過網絡可能會對性能造成嚴重影響；服務器多宕機的概率大；數據在分布式的環境中保持數據一致性也非常困難；導致網站依賴錯綜復雜開發被處理維護困難；
  

• 常見的分布式方案：分布式應用和服務；分布式靜態資源；分布式數據和存儲；分布式計算（Hadoop及其MapReduce）；分布式配置；分布式鎖；分布式文件等；
  

4.集群

• 多臺服務器部署相同應用構成一個集群，通過負載均衡設備共同對外提供服務。
  

5.緩存

• 緩存就是將數據有些話在距離計算最近的位置以加快處理速度。
  

• CDN、反向代理、本地緩存、分布式緩存。
  

• 使用緩存的兩個前提條件：一是數據訪問熱點不均衡；二是數據在某個時間段內有效；
  

6.異步

• 業務之間的消息傳遞不是同步調用，而是將一個業務操作分成多個階段，每個階段之間通過共享數據的方式異步執行進行協作。
  

• 單一服務器內部可通過多線程共享內存隊列的方式實現異步；分布式系統中，多個服務器集群通過分布式消息隊列實現異步。
  

• 典型的生產者消費者模式，兩者不存在直接調用，特性：提高系統可用性；加快網站響應速度；消除并發訪問高峰。
  

• 使用異步方式處理業務可能會對用戶體驗、業務流程造成影響，需要產品設計方面的支持。
  

7.冗余

• 要想保證在服務器宕機的情況下網站依然可以繼續服務，不丟失數據，就需要一定程度的服務器冗余運行，數據冗余備份。
  

• 小型網站也需要至少兩臺服務器構建集群，數據庫除定期備份保存實現冷備份外，也需要進行主從分享實時同步熱備。
  

• 大型公司可能會對整個數據中心備份并同步到各地災備中心。
  

8.自動化

• 主要集中在發布運維方面。
  

• 發布過程自動化：自動化代碼管理、自動化測試、自動化安全檢測、自動化部署。
  

• 自動化監控：自動化報警、自動化失效轉移、自動化失效恢復、自動化降級、自動化分配資源。
  

9.安全

B.架構模式在新浪微博的應用

三、大型網站核心架構要素

架構：最高層次的規劃，難以改變的決定。

軟件架構：有關軟件整體結構與組件的抽象描述，用于指導大型軟件系統各個方面的設計。

A.性能

• 瀏覽器端：瀏覽器緩存、頁面壓縮、合理布局、減少Cookie傳輸、CDN等
  

• 應用服務器端：服務器本地緩存、分布式緩存、異步操作與消息隊列配合、集群等
  

• 代碼：多線程、改善內存管理等
  

• 數據庫：索引、緩存、SQL優化、NoSQL技術
  

B.可用性

• 服務器、數據庫及文件存儲等運行環境的主要手段是冗余。
  

• 軟件開發時通過預發布驗證、自動化測試、自動化發布、灰度發布等手段
  

C.伸縮性

• 伸縮性是指通過不斷向集群中加入服務器的手段來緩解不斷上升的用戶并發訪問壓力和不斷增長的數據存儲需求。加入新的服務器是否可以提供和原來的服務器無差別的服務。
  

• 應用服務器：通過合適的負載均衡設備可以向集群中不斷加入服務器。
  

• 緩存服務器：加入新的可能會導致緩存路由失效。需要路由算法。
  

• 關系數據庫：通過路由分區等手段。
  

D.擴展性

• 衡量標準：網站增加業務產品時，是否可以實現對現有產品透明無影響；不同產品這間是否很少耦合；
  

• 手段：事件驅動架構（消息隊列）、分布式服務（將業務和可利用服務分享，通過分布式服務框架調用）
  

E.安全性

四、瞬時響應：網站的高性能架構

A.網站性能測試

1.不同視角

• 用戶視角的網站性能：優化頁面HTML樣式、利用瀏覽器端的并發和異步特性、調整瀏覽器緩存策略、使用CDN服務、反射代理等。
  

• 開發人員視角的網站性能：使用緩存加速數據讀取、使用集群提高吞吐能力、使用異步消息加快請求響應及實現削峰、使用代碼優化手段改善程序性能。
  

• 運維人員視角的網站性能：建設優化骨干網、使用高性價比定制服務器、利用虛擬化技術優化資源利用等。
  

2.性能測試指標

• 響應時間：測試辦法是重復請求，測試一萬次總時間之和除以一萬。
  

• 并發數：系統能夠同時處理請求的數目（網站系統用戶數>>網站在線用戶數>>網站并發用戶數），測試程序通過多線程模擬并發用戶的辦法來測試系統的并發處理能力。
  

• 吞吐量：單位時間內系統處理的請求數量（TPS、HPS、QPS等）
  

• 性能計數器：描述服務器或操作系統性能的一些數據操縱桿。包括System Load、對象與線程數、內存使用、CPU使用、磁盤與網絡I/O等。
  

3.性能測試方法：性能測試、負載測試、壓力測試、穩定性測試

4.性能測試是一個不斷對系統增加訪問壓力，以獲得系統性能指標、最大負載能力、最大壓力承受能力的過程。所謂增加訪問壓力，就是不斷增加測試程序的并發請求數。

5.性能優化策略

• 性能分析：檢查請求處理的各個環節的日志，分析哪個環節響應時間不合理、超過預期；然后檢查監控數據 。
  

B.Web前端性能優化

1.瀏覽器訪問優化：減少http請求（合并CSS/JS/圖片）、使用瀏覽器緩存（HTTP頭中Cache-Control和Expires）、啟用壓縮 （Gzip）、CSS放在頁面最上面JS放在頁面最下面、減少Cookie傳輸

2.CND加速

3.反向代理：通過配置緩存功能加速Web請求。（還可以保護真實服務器及實現負載均衡的功能）

C.應用服務器性能優化

1.分布式緩存

• 網站性能優化第一定律：優先考慮使用緩存優化性能
  

• 主要用來存放那些讀寫比很高、很少變化的數據。緩存無法命中時讀取數據庫并將數據再寫入緩存。
  

2.合理使用緩存：不要頻繁修改的數據、沒有熱點的訪問、數據不一致與臟讀、緩存可用性（緩存熱備）、緩存預熱（在程序啟動時預先加載一些緩存）、緩存穿透

3.分布式緩存架構：需要更新同步的分布式緩存（JBoss Cache）、不互相通信的分布式緩存（Memcached）

4.異步操作：使用消息隊列（可改善網站的擴展性和性能），具有很好的削峰作用，將短時間高并發產生的事務消息存儲在消息隊列中。

5.使用集群

6.代碼優化：

• 多線程（IO阻塞與多CPU，啟動線程數=[任務執行時間/(任務執行時間-IO等待時間)]*CPU內核數，需要注意線程安全：將對象設計為無狀態對象、使用局部對象、并發訪問資源時使用鎖）；
  

• 資源復用（單例和對象池）；
  

• 數據結構；
  

• 垃圾回收
  

D.存儲性能優化

1.數據庫多采用兩級索引的B+樹，樹的層次最多三層。可能需要5次磁盤訪問才能更新一條記錄。

2.這么多NoSQL產品使用LSM樹，可以看作一個N階合并樹。

3.RAID（廉價磁盤冗余陣列），RAID0，RAID1，RAID10，RAID5，RAID6，傳統關系數據庫及文件系統中應用廣泛。

4.HDFS（Hadoop分布式文件系統），配合MapReduce進行大數據處理。

五、萬無一失：網站的高可用架構

A.網站可用性的度量與考核

1.網站可用性度量

• 網站不可用時間（故障時間）=故障修復時間點-故障發現（報告）時間點
  

• 網站年度可用性指標=（1-網站不可用時間/年度總時間）*100%
  

• 2個9是基本可用，88小時；3個9是較高可用，9小時；4個9是具有自動恢復能力的高可用，53分鐘；5個9具有極高可用性，小于5分鐘；QQ為99.99，4個9，一年大約53分鐘不可用。
  

2.網站可用性考核

• 故障分：指對網站故障進行分類加權計算故障責任的方法
  

• 故障分=故障時間（分鐘）*故障權重
  

B.高可用的網站架構

主要手段就是數據和服務的冗余備份及失效轉移。對于應用層和服務層，以集群通過負載均衡實現高可用，數據層通過數據同步復制實現冗余備份來實現高可用。

C.高可用應用

1.通過負載均衡進行無狀態服務的失效轉移：即使應用訪問量非常少，也至少部署兩臺服務器使用負載均衡構建一個小型集群。

2.應用服務器集群的Session管理

• Session復制：服務器間同步Session，小型集群
  

• Session綁定：利用源地址Hash將源于同一IP的請求分發到同一臺服務器上，對高可用性有影響。
  

• 利用Cookie記錄Session：大小限制、每次請求響應都需要傳輸、關閉cookie則無法訪問
  

• Session服務器：利用分布式緩存、數據庫等，高可用、高伸縮、性能較好
  

D.高可用服務

1.分級管理：運維上將服務器進行分級，核心應用和服務優先使用更好的硬件，在運維響應速度上也格外迅速。

2.超時設置：在應用程序中設置服務調用的超時時間，一旦超時，通信框架就拋出異常，應用程序根據服務調度策略，可選擇繼續重試或將請求轉移到提供相同服務的其他服務器上。

3.異步調用：應用對服務的調用通過消息隊列等異步方式完成，避免一個服務失敗導致整個應用請求失敗的情況。

4.服務降級：拒絕服務，拒絕低優先級應用的調用或者隨機拒絕部分請求調用；關閉功能，關閉部分不重要的服務或服務內部關閉部分不重要的功能。

5.冪等性設計：在服務層保證服務重復調用和調用一次產生的結果相同，即服務具有冪等性。

E.高可用的數據

1.CAP原理

• 高可用的數據：數據持久性（永久性存儲、備份副本不會丟失）、數據可訪問性（不同設備下快速切換）、數據一致性（多副本的情況下保證副本數據一致）
  

• CAP原理：一個提供數據服務的存儲系統無法同時滿足數據一致性（Consistency）、數據可用性（Availibility）、分區耐受性（Partition Tolerance，系統具有 跨網絡分區的伸縮性）這三個條件。
  

• 大型網站通常會選擇強化分布式系統的可用性（A）和伸縮性（P），而在某種程度上放棄一致性（C）。一般來說，數據不一致通常出現在系統高并發寫操作或者集群狀態不穩的情況下，應用系統需要對分布式數據處理系統的數據不一致性有所了解并進行一定意義上的補償和糾錯，以避免出現應用系統數據不正確。
  

• 數據一致性又可分為：數據強一致（各種操作都是一致的）、數據用戶一致（副本可能不一致但用戶訪問時通過糾錯的校驗確定一個正確的數據返回給用戶）、數據最終一致（副本和用戶訪問可能都不一致，但系統經過一段時間的自我恢復和修正達到一致）
  

2.數據備份

• 異步熱備：多份數據副本的寫入操作異步完成，應用程序收到數據服務系統的寫操作成功響應時，只寫成功一份，存儲系統將會異步地寫其他副本（可能會失敗）
  

• 同步熱備：多份數據副本的寫入操作同步完成，即應用程序收到數據服務系統的寫成功響應時，多份數據都已經寫操作成功。
  

3.失效轉移

• 失效確認：心跳檢測、應用程序訪問失敗
  

• 訪問轉移：確認某臺服務器宕機后，將數據讀寫訪問重新路由到其他服務器上
  

• 數據恢復：從健康的服務器復制數據，將數據副本數目恢復到設定值
  

F.高可用網站的軟件質量保證

1.網站發布

2.自動化測試：工具Selenium

3.預發布驗證：先發布到預發布機器上，開發工程師和測試工程師在預發布服務器上進行預發布驗證。需要和生產環境相同配置、環境、數據中心等

4.代碼控制：svn、git；主干開發、分支發布；分支開發、主干發布（主流）；

5.自動化發布

6.灰度發布：將集群服務器分成若干部分，每天只發布一部分服務器，觀察運行穩定沒有故障，期間如果發現問題，只需要回滾已發布的一部分服務器即可。也常用于用戶測試（AB測試）。

G.網站運行監控

1.監控數據的采集

• 用戶行為日志收集：用戶操作系統與瀏覽器版本、IP地址、頁面訪問路徑、頁面停留時間等。包括服務器端日志收集、客戶端瀏覽器日志收集。
  

• 服務器性能收集：如系統Load、內存占用、磁盤IO、網絡IO等，工具Ganglia等
  

• 運行數據報告：如緩沖命中率、平均響應延遲時間、每分鐘發送郵件數目、待處理的任務總數等。
  

2.監控管理

• 系統報警：設定各項監控指標設定閾值，使用郵件、即時通信工具、短信等報警
  

• 失效轉移：主動通知應用，進行失效轉移
  

• 自動優雅降級：根據監控參數判斷應用負載，適當卸載應用低負載應用部分服務器，重新安裝高負載應用使應用負載總體均衡。
  

六、永無止境：網站的伸縮性架構

所謂網站的伸縮性是指不需要改變網站的軟硬件設計，僅僅通過改變部署的服務器數量就可以擴大或者縮小網站的服務處理能力。

A.網站架構的伸縮性設計

1.不同功能進行物理分離實現伸縮：縱向分離（分層后分離），將業務處理流程上的不同部分分離部署，實現系統伸縮性；橫向分離（業務分割后分離），將不同的業務模塊分離部署，實現系統伸縮性。

2.單一功能通過集群規模實現伸縮

B.應用服務器集群的伸縮性設計

1.應用服務器應該設計成無狀態的，不存儲請求上下文信息。

2.負載均衡：

• HTTP重定向負載均衡：根據用戶的HTTP請求計算一臺真實的Web服務器地址，并將該服務器地址寫入HTTP重定向響應中返回給用戶瀏覽器。優點簡單，缺點：需要兩次請求；重定向服務器自身的處理能力可能成為瓶頸；302跳轉可能影響SEO。
  

• DNS域名解析負載均衡：在DNS服務器配置多個A記錄指向不同IP，優點是將負載均衡的工作轉交給DNS，不少還支持地理位置返回最近的服務器。缺點是可能緩存A記錄，控制權在域名服務商那里。
  

• 反射代理負載均衡：瀏覽器訪問請求的地址是反向代理服務器，反向代理服務器收到請求后，根據負載均衡算法計算得到一臺真實物理服務器的地址，并將請求轉發給真實服務器，處理完成后將響應返回給反向代理服務器，反向代理服務器再將響應返回給用戶。也叫應用層（HTTP層）負載均衡。優點是部署簡單，缺點是反向代理服務器作為中轉站性能可能成為瓶頸。
  

• IP負載均衡：用戶請求數據包到達負載均衡服務器后，負載均衡服務器在操作系統內核進程獲取網絡數據包，根據負載均衡算法計算得到一臺真實web服務器，然后將數據目的IP地址修改為真實服務器，不需要通過用戶進程處理。真實服務器處理完成后，響應數據包回到負載均衡服務器，負載均衡服務器再將數據包源地址修改為自身的IP地址發送給用戶瀏覽器。
  

• 數據鏈路層負載均衡：三角傳輸模式，負載均衡服務器數據分發過程中不修改IP地址，只修改目的mac地址，通過所有服務器的虛擬IP地址與負載均衡服務器的IP地址一致，不修改數據包的源地址和目的地址，由于IP一致，可將響應數據包直接返回給用戶瀏覽器。又稱為直接路由方式（DR）。代表產品LVS（Linux Virtual Server）。
  

3.負載均衡算法：

• 輪詢（Round Robin，RR）：所有請求集資分發到每臺應用服務器上
  

• 加權輪詢（Weighted Round Robin，WRR）：根據服務器硬件性能情況，在輪詢的基礎上按照配置的權重進行分發
  

• 隨機（Random）：請求被隨機分配到各個應用服務器
  

• 最少連接（Least Connections）：記錄服務器正在處理的連接數，將新的請求分發到最少連接的服務器上
  

• 源地址散列（Source Hashing）：根據請求來源的IP地址進行Hash計算
  

C.分布式緩存集群的伸縮性設計

1.Memcached分布式緩存集群的訪問模型

通過KEY輸入路由算法模塊，路由算法計算得到一臺Memcached服務器，進行讀取和寫入。

2.Memcached分布式緩存集群的伸縮性挑戰

簡單的路由算法使用余數Hash：用服務器數目除緩存數據KEY的Hash值，余數為服務器列表下標編號。伸縮性不好。

3.分布式緩存的一致性Hash算法

先構造一個長度為2的32次方的整數環（一致性Hash環），根據節點名稱的Hash值將緩存服務器節點放置在這個Hash環上。然后根據需要緩存的數據的KEY值計算Hash值，然后在Hash環上順時針查找距離這個KEY的Hash值最近的緩存服務器節點，完成KEY到服務器的Hash映射查找 。

D.數據存儲服務器集群的伸縮性設計

1.關系數據庫集群的伸縮性設計

數據復制（主從）、分表分庫、數據分片（ Cobar）

2.NoSQL數據庫的伸縮性設計

NoSQL放棄了以關系代數為基礎的結構化查詢語言（SQL）和事務一致性保證（ACID）。強化了高可用性和伸縮性。（Apache HBase） 

到此，關于“mysql大型網站技術架構核心原理是什么”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！