mysql大型網站技術架構核心原則是什麼-mysql教程-PHP中文網

首頁

資料庫

mysql教程

mysql大型網站技術架構核心原則是什麼

PHPz

May 27, 2023 pm 01:54 PM

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.企圖用技術解決所有問題：技術是用來解決業務問題的，而業務的問題，也可以透過業務的手段去解決

二、大型網站架構模式
每種模式都描繪了一個不斷重複發生的問題和該問題的解決方案核心。這樣，你就能一次又一次地使用該方案而不必做重複工作。模式的關鍵在於模式的可重複性。

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等）
效能計數器：描述伺服器或作業系統效能的一些資料操縱桿。這句話的重寫版本為：此處涉及系統負載、物件和執行緒的數量、記憶體使用情況、CPU使用率以及磁碟和網路I/O等方面。

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

進行效能測試是為了持續為系統添加負載，以獲取系統效能指標、最大負載能力和最大壓力承受能力。所謂增加訪問壓力，就是不斷增加測試程序的並發請求數。

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，傳統關聯式資料庫及檔案系統中應用廣泛。
五、萬無一失：網站的高可用架構
A.網站可用性的度量與考核

2.網站可用性考核

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

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

#B.高可用的網站架構
主要手段是資料和服務的冗餘備份及失效轉移。應用層和服務層實現高可用採用叢集負載平衡，資料層實現冗餘備份採用資料同步複製。
1.透過負載平衡進行無狀態服務的失效轉移：即使應用存取量非常少，也至少部署兩台伺服器使用負載平衡建構一個小型叢集。
Session複製：伺服器間同步Session，小型叢集

Session綁定：利用來源位址Hash將源自同一IP的請求分送到同一台伺服器上，對高可用性有影響。

######利用Cookie記錄Session：大小限制、每次請求回應都需要傳輸、關閉cookie則無法存取############# #Session伺服器：利用分散式快取、資料庫等，高可用、高擴充、效能較好##################D.高可用服務###### ###1.分級管理：維運上將伺服器進行分級，核心應用和服務優先使用更好的硬件，在運維響應速度上也格外迅速。 ###

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

應用程式透過訊息佇列等非同步方式完成對服務的調用，以避免當一個服務失敗時整個應用程式請求也會失敗的情況。

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

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

E.高可用的資料

1.CAP原理

#高可用的資料：資料持久性（永久性儲存、備份副本不會遺失）、資料可存取性（不同裝置下快速切換）、資料一致性（多副本的情況下保證副本資料一致）
#CAP原理：一個提供資料服務的儲存系統無法同時滿足資料一致性（Consistency）、資料可用性（Availibility）、分區耐受性（Partition Tolerance，系統具有跨網路分區的伸縮性）這三個條件。
通常大型網站會強化分散式系統的可用性（A）和擴充性（P），在一定程度上犧牲一致性（C）。一般來說，資料不一致通常出現在系統高並發寫操作或叢集狀態不穩的情況下，應用系統需要對分散式資料處理系統的資料不一致性有所了解並進行一定意義上的補償和糾錯，以避免出現應用系統資料不正確。
資料一致性又可分為：資料強一致（各種操作都是一致的）、資料使用者一致（副本可能不一致但使用者存取時透過糾錯的校驗確定一個正確的資料回傳給使用者）、資料最終一致（副本和使用者存取可能都不一致，但係統經過一段時間的自我恢復和修正達到一致）

2.資料備份

非同步熱備：多份資料副本的寫入作業非同步完成，應用程式收到資料服務系統的寫入作業成功回應時，只寫成功一份，儲存系統將會異步地寫其他副本（可能會失敗）
#同步熱備：多份資料副本的寫入作業同步完成，即應用當程式收到資料服務系統的寫入成功回應時，多份資料都已經寫入操作成功。

3.失效轉移

#失效確認：心跳偵測、應用程式存取失敗
存取轉移：確認某台伺服器宕機後，將資料讀寫存取重新路由到其他伺服器上
資料復原：從健康的伺服器複製數據，將資料副本數目恢復到設定值

#F.高可用網站的軟體品質保證

#1.網站發布

2.自動化測試：工具Selenium

在預發布伺服器上進行預發布驗證，我們會先將其發佈到預發布機器上，供開發工程師和測試工程師使用。需要和生產環境相同配置、環境、資料中心等

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跳轉也可能會影響搜尋引擎優化。
DNS網域解析負載平衡：在DNS伺服器設定多個A記錄指向不同IP，優點是將負載平衡的工作轉交給DNS，不少也支援地理位置傳回最近的伺服器。缺點是可能快取A記錄，控制權在網域服務商那裡。
反射代理負載平衡：瀏覽器存取請求的位址是反向代理伺服器，反向代理伺服器收到請求後，根據負載平衡演算法計算得到一台真實實體伺服器的位址，並將請求轉發給真實伺服器，處理完成後將回應傳回給反向代理伺服器，反向代理伺服器再將回應傳回給使用者。也叫應用層（HTTP層）負載平衡。它的部署很簡單，但反向代理的效能可能成為瓶頸。
IP負載平衡：用戶請求資料包到達負載平衡伺服器後，負載平衡伺服器在作業系統核心程序取得網路封包，根據負載平衡演算法計算得到一台真實web伺服器，然後將資料目的IP位址修改為真實伺服器，不需要透過使用者進程處理。真實伺服器處理完成後，回應資料包回到負載平衡伺服器，負載平衡伺服器再將資料包來源位址修改為自身的IP位址傳送給使用者瀏覽器。
資料鏈結層負載平衡：三角傳輸模式，負載平衡伺服器資料分發過程中不修改IP位址，只修改目的mac位址，透過所有伺服器的虛擬IP位址與負載平衡伺服器的IP位址一致，不修改封包的來源位址與目的位址，由於IP一致，可將回應封包直接傳回給使用者瀏覽器。又稱為直接路由方式（DR）。代表產品LVS（Linux Virtual Server）。

3.負載平衡演算法：