大型網站如何防止崩潰,解決高併發帶來的問題
大型網站,比如入口網站,在面對大量使用者訪問、高併發請求方面帶來的問題
1大併發:在同一個時間點,有大量的客戶來訪問我們的網站,如果訪問量過大,就可能造成網站癱瘓。
2大流量:當網站大後,有大量的圖片,視訊, 這樣就會對流量要求高,需要更多更大的頻寬。
3大儲存:你的資料量會成海量的資料,如果我們的資料放入一張表,是無法應對的。可能對資料儲存和查詢出現問題。
基本的解決方案集中在這樣幾個環節:使用高效能的伺服器、高效能的資料庫、高效率的程式語言、還有高效能的Web容器,(對架構分層+負載均衡+叢集)這幾個解決思路在一定程度上意味著更大的投入。
解決方案:
一、提高硬體能力、增加系統伺服器。(當伺服器增加到某個程度的時候系統所能提供的併發訪問量幾乎不變,所以不能根本解決問題)
二、使用快取(本地快取:本地可以使用JDK自帶的 Map、Guava Cache.分散式快取:Redis、Memcache.本地快取不適用於提高系統併發量,一般是用處用在程式中。比如Spring是如何實現單例的呢?大家如果看過原始碼的話,應該知道,Spiring把已經初始過的變數放在一個Map中,下次再要使用這個變數的時候,先判斷Map中有沒有,這也就是系統中常見的單例模式的實現。)
分散式快取利器Redis叢集,Redis叢集的搭建至少需要三主三從。 1. 所有的redis節點彼此互聯(PING-PONG機制),內部使用二進位制協議優化傳輸速度和頻寬。 2. 節點的fail是通過叢集中超過半數的節點檢測失效時才生效(所以一個叢集中至少要有三個節點)。 3. 客戶端與redis節點直連,不需要中間proxy層.客戶端不需要連線叢集所有節點,連線叢集中任何一個可用節點即可。 4. 叢集中每一個節點都存放不同的內容,每一個節點都應有備份機。 5. redis-cluster把所有的物理節點對映到[0-16383]slot上,cluster 負責維護node<->slot<->value
Redis 叢集中內建了16384 個雜湊槽,當需要在Redis 叢集中放置一個key-value 時,redis先對 key 使用 crc16 演算法算出一個結果,然後把結果對16384 求餘數,這樣每個key 都會對應一個編號在0-16383 之間的雜湊槽,redis會根據節點數量大致均等的將雜湊槽對映到不同的節點。
三 、訊息佇列 (解耦+削峰+非同步)通過非同步處理提高系統性能,降低系統耦合性
在不使用訊息佇列伺服器的時候,使用者的請求資料直接寫入資料庫,在高併發的情況下資料庫壓力劇增,使得響應速度變慢。但是在使用訊息佇列之後,使用者的請求資料傳送給訊息佇列之後立即 返回,再由訊息佇列的消費者程序從訊息佇列中獲取資料,非同步寫入資料庫。由於訊息佇列伺服器處理速度快於資料庫(訊息佇列也比資料庫有更好的伸縮性),因此響應速度得到大幅改善。
通過使用訊息中介軟體對Dubbo服務間的呼叫進行解耦, 訊息中介軟體可利用高效可靠的訊息傳遞機制進行平臺無關的資料交流,並基於資料通訊來進行分散式系統的整合。通過提供訊息傳遞和訊息排隊模型,可以在分散式環境下擴充套件程序間的通訊。通過訊息中介軟體,應用程式或元件之間可以進行可靠的非同步通訊,從而降低系統之間的耦合度,提高系統的可擴充套件性和可用性。
四 、採用分散式開發 (不同的服務部署在不同的機器節點上,並且一個服務也可以部署在多臺機器上,然後利用 Nginx 負載均衡訪問。這樣就解決了單點部署(All In)的缺點,大大提高的系統併發量)
五 、資料庫分庫(讀寫分離)、分表(水平分表、垂直分表)
PXC高可用叢集與Replication叢集結合方案
這種的叢集在遇到單表資料量超過2000萬的時候,mysql效能會受損,所以一個叢集還不夠,我們需要把資料分到另一個叢集,這個稱為“切片”,就是把大量的資料拆分到不同的叢集中,每個叢集的資料都是不一樣的,通過MyCat這個阿里巴巴的開源中介軟體,可以把sql分到不同的叢集裡面去。
PXC叢集方案與Replication區別 PXC叢集方案所有節點都是可讀可寫的,Replication從節點不能寫入,因為主從同步是單向的,無法從slave節點向master點同步。 PXC同步機制是同步進行的,這也是它能保證資料強一致性的根本原因,Replication同步機制是非同步進行的,它如果從節點停止同步,依然可以向主節點插入資料,正確返回,造成資料主從資料的不一致性。 PXC是用犧牲效能保證資料的一致性,Replication在效能上是高於PXC的。所以兩者用途也不一致。PXC是用於重要資訊的儲存,例如:訂單、使用者資訊等。Replication用於一般資訊的儲存,能夠容忍資料丟失,例如:購物車,使用者行為日誌等
六、 採用叢集 (多臺機器提供相同的服務)系統架構方案
七、CDN 加速 (將一些靜態資源比如圖片、視訊等等快取到離使用者最近的網路節點)
八、瀏覽器快取 頁面靜態化(使用php自己的ob快取技術實現, 主流的mvc框架(tp,yii,laravel)模板引擎一般都自帶頁面靜態化 )
九、使用合適的連線池(資料庫連線池、執行緒池等等)
十、適當使用多執行緒進行開發。
十一、使用映象
映象是大型網站常採用的提高效能和資料安全性的方式,映象的技術可以解決不同網路接入商和地域帶來的使用者訪問速度差異,比如ChinaNet和EduNet之間的差異就促使了很多網站在教育網內搭建映象站點,資料進行定時更新或者實時更新。有很多專業的現成的解決架構和產品可選。也有廉價的通過軟體實現的思路,比如Linux上的rsync等工具。
十二、圖片伺服器分離
大家知道,對於Web伺服器來說,不管是Apache、IIS還是其他容器,圖片是最消耗資源的,於是我們有必要將圖片與頁面進行分離,這是基本上大型網站都會採用的策略,他們都有獨立的、甚至很多臺的圖片伺服器。這樣的架構可以降低提供頁面訪問請求的伺服器系統壓力,並且可以保證系統不會因為圖片問題而崩潰。
在應用伺服器和圖片伺服器上,可以進行不同的配置優化,比如apache在配置ContentType的時候可以儘量少支援、儘可能少的LoadModule,保證更高的系統消耗和執行效率。