大型網(wǎng)站如何解決高并發(fā)帶來的問題

大型網(wǎng)站，比如門戶網(wǎng)站，在面對大量用戶訪問、高并發(fā)請求方面帶來的問題

1.大并發(fā)：在同一個時間點，有大量的客戶來訪問我們的網(wǎng)站，如果訪問量過大，就可能造成網(wǎng)站癱瘓。

2.大流量：當(dāng)網(wǎng)站大后，有大量的圖片，視頻, 這樣就會對流量要求高，需要更多更大的帶寬。

3.大存儲：你的數(shù)據(jù)量會成海量的數(shù)據(jù)，如果我們的數(shù)據(jù)放入一張表，是無法應(yīng)對的?？赡軐?shù)據(jù)保存和查詢出現(xiàn)問題。

基本的解決方案集中在這樣幾個環(huán)節(jié)：使用高性能的服務(wù)器、高性能的數(shù)據(jù)庫、高效率的編程語言、還有高性能的Web容器，(對架構(gòu)分層+負(fù)載均衡+集群)這幾個解決思路在一定程度上意味著更大的投入。

解決方案：

一、提高硬件能力、增加系統(tǒng)服務(wù)器。（當(dāng)服務(wù)器增加到某個程度的時候系統(tǒng)所能提供的并發(fā)訪問量幾乎不變，所以不能根本解決問題）

二、使用緩存（本地緩存：本地可以使用JDK自帶的 Map、Guava Cache.分布式緩存：Redis、Memcache.本地緩存不適用于提高系統(tǒng)并發(fā)量，一般是用處用在程序中。比如Spring是如何實現(xiàn)單例的呢？大家如果看過源碼的話，應(yīng)該知道，Spiring把已經(jīng)初始過的變量放在一個Map中，下次再要使用這個變量的時候，先判斷Map中有沒有，這也就是系統(tǒng)中常見的單例模式的實現(xiàn)。）

分布式緩存利器Redis集群，Redis集群的搭建至少需要三主三從。

1. 所有的redis節(jié)點彼此互聯(lián)(PING-PONG機(jī)制),內(nèi)部使用二進(jìn)制協(xié)議優(yōu)化傳輸速度和帶寬。

2. 節(jié)點的fail是通過集群中超過半數(shù)的節(jié)點檢測失效時才生效(所以一個集群中至少要有三個節(jié)點)。

3. 客戶端與redis節(jié)點直連,不需要中間proxy層.客戶端不需要連接集群所有節(jié)點,連接集群中任何一個可用節(jié)點即可。

4. 集群中每一個節(jié)點都存放不同的內(nèi)容，每一個節(jié)點都應(yīng)有備份機(jī)。

5. redis-cluster把所有的物理節(jié)點映射到[0-16383]slot上,cluster 負(fù)責(zé)維護(hù)node<->slot<->value

Redis 集群中內(nèi)置了16384 個哈希槽，當(dāng)需要在Redis 集群中放置一個key-value 時，redis先對 key 使用 crc16 算法算出一個結(jié)果，然后把結(jié)果對16384 求余數(shù)，這樣每個key 都會對應(yīng)一個編號在0-16383 之間的哈希槽，redis會根據(jù)節(jié)點數(shù)量大致均等的將哈希槽映射到不同的節(jié)點。

三 、消息隊列 （解耦+削峰+異步）通過異步處理提高系統(tǒng)性能，降低系統(tǒng)耦合性

在不使用消息隊列服務(wù)器的時候，用戶的請求數(shù)據(jù)直接寫入數(shù)據(jù)庫，在高并發(fā)的情況下數(shù)據(jù)庫壓力劇增，使得響應(yīng)速度變慢。但是在使用消息隊列之后，用戶的請求數(shù)據(jù)發(fā)送給消息隊列之后立即 返回，再由消息隊列的消費者進(jìn)程從消息隊列中獲取數(shù)據(jù)，異步寫入數(shù)據(jù)庫。由于消息隊列服務(wù)器處理速度快于數(shù)據(jù)庫（消息隊列也比數(shù)據(jù)庫有更好的伸縮性），因此響應(yīng)速度得到大幅改善。

通過使用消息中間件對Dubbo服務(wù)間的調(diào)用進(jìn)行解耦, 消息中間件可利用高效可靠的消息傳遞機(jī)制進(jìn)行平臺無關(guān)的數(shù)據(jù)交流，并基于數(shù)據(jù)通信來進(jìn)行分布式系統(tǒng)的集成。通過提供消息傳遞和消息排隊模型，可以在分布式環(huán)境下擴(kuò)展進(jìn)程間的通信。通過消息中間件，應(yīng)用程序或組件之間可以進(jìn)行可靠的異步通訊，從而降低系統(tǒng)之間的耦合度，提高系統(tǒng)的可擴(kuò)展性和可用性。

四 、采用分布式開發(fā) （不同的服務(wù)部署在不同的機(jī)器節(jié)點上，并且一個服務(wù)也可以部署在多臺機(jī)器上，然后利用 Nginx 負(fù)載均衡訪問。這樣就解決了單點部署(All In)的缺點，大大提高的系統(tǒng)并發(fā)量）

五 、數(shù)據(jù)庫分庫（讀寫分離）、分表（水平分表、垂直分表）

這種的集群在遇到單表數(shù)據(jù)量超過2000萬的時候，mysql性能會受損，所以一個集群還不夠，我們需要把數(shù)據(jù)分到另一個集群，這個稱為“切片”，就是把大量的數(shù)據(jù)拆分到不同的集群中，每個集群的數(shù)據(jù)都是不一樣的，通過MyCat這個阿里巴巴的開源中間件，可以把sql分到不同的集群里面去。

PXC集群方案所有節(jié)點都是可讀可寫的，Replication從節(jié)點不能寫入，因為主從同步是單向的，無法從slave節(jié)點向master點同步。PXC同步機(jī)制是同步進(jìn)行的，這也是它能保證數(shù)據(jù)強(qiáng)一致性的根本原因，Replication同步機(jī)制是異步進(jìn)行的，它如果從節(jié)點停止同步，依然可以向主節(jié)點插入數(shù)據(jù)，正確返回，造成數(shù)據(jù)主從數(shù)據(jù)的不一致性。

PXC是用犧牲性能保證數(shù)據(jù)的一致性，Replication在性能上是高于PXC的。所以兩者用途也不一致。PXC是用于重要信息的存儲，例如：訂單、用戶信息等。Replication用于一般信息的存儲，能夠容忍數(shù)據(jù)丟失，例如：購物車，用戶行為日志等。

六、 采用集群 （多臺機(jī)器提供相同的服務(wù)）系統(tǒng)架構(gòu)方案

七、CDN 加速 (將一些靜態(tài)資源比如圖片、視頻等等緩存到離用戶最近的網(wǎng)絡(luò)節(jié)點)

八、瀏覽器緩存 頁面靜態(tài)化（使用php自己的ob緩存技術(shù)實現(xiàn)， 主流的mvc框架(tp,yii,laravel)模板引擎一般都自帶頁面靜態(tài)化 ）

九、使用合適的連接池（數(shù)據(jù)庫連接池、線程池等等）

十、適當(dāng)使用多線程進(jìn)行開發(fā)。

十一、使用鏡像

鏡像是大型網(wǎng)站常采用的提高性能和數(shù)據(jù)安全性的方式，鏡像的技術(shù)可以解決不同網(wǎng)絡(luò)接入商和地域帶來的用戶訪問速度差異，比如ChinaNet和EduNet之間的差異就促使了很多網(wǎng)站在教育網(wǎng)內(nèi)搭建鏡像站點，數(shù)據(jù)進(jìn)行定時更新或者實時更新。有很多專業(yè)的現(xiàn)成的解決架構(gòu)和產(chǎn)品可選。也有廉價的通過軟件實現(xiàn)的思路，比如Linux上的rsync等工具。

十二、圖片服務(wù)器分離

大家知道，對于Web服務(wù)器來說，不管是Apache、IIS還是其他容器，圖片是最消耗資源的，于是我們有必要將圖片與頁面進(jìn)行分離，這是基本上大型網(wǎng)站都會采用的策略，他們都有獨立的、甚至很多臺的圖片服務(wù)器。這樣的架構(gòu)可以降低提供頁面訪問請求的服務(wù)器系統(tǒng)壓力，并且可以保證系統(tǒng)不會因為圖片問題而崩潰。在應(yīng)用服務(wù)器和圖片服務(wù)器上，可以進(jìn)行不同的配置優(yōu)化，比如apache在配置ContentType的時候可以盡量少支持、盡可能少的LoadModule，保證更高的系統(tǒng)消耗和執(zhí)行效率。