大型網站如何防止崩潰，解決高併發帶來的問題

大型網站，好比門戶網站，在面對大量用戶訪問、高併發請求方面帶來的問題
1大併發：在同一個時間點，有大量的客戶來訪問咱們的網站，若是訪問量過大，就可能形成網站癱瘓。
2大流量：當網站大後，有大量的圖片，視頻, 這樣就會對流量要求高，須要更多更大的帶寬。
3大存儲：你的數據量會成海量的數據，若是咱們的數據放入一張表，是沒法應對的。可能對數據保存和查詢出現問題。

基本的解決方案集中在這樣幾個環節：使用高性能的服務器、高性能的數據庫、高效率的編程語言、還有高性能的Web容器，(對架構分層+負載均衡+集羣)這幾個解決思路在必定程度上意味着更大的投入。

解決方案：

   1、提升硬件能力、增長系統服務器。（當服務器增長到某個程度的時候系統所能提供的併發訪問量幾乎不變，因此不能根本解決問題）

   2、使用緩存（本地緩存：本地可使用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用於通常信息的存儲，可以容忍數據丟失，例如：購物車，用戶行爲日誌等

   6、 採用集羣 （多臺機器提供相同的服務）系統架構方案

   7、CDN 加速 (將一些靜態資源好比圖片、視頻等等緩存到離用戶最近的網絡節點)

   8、瀏覽器緩存 頁面靜態化（使用php本身的ob緩存技術實現， 主流的mvc框架(tp,yii,laravel)模板引擎通常都自帶頁面靜態化 ）      

   9、使用合適的鏈接池（數據庫鏈接池、線程池等等）

   10、適當使用多線程進行開發。

   11、使用鏡像

鏡像是大型網站常採用的提升性能和數據安全性的方式，鏡像的技術能夠解決不一樣網絡接入商和地域帶來的用戶訪問速度差別，好比ChinaNet和EduNet之間的差別就促使了不少網站在教育網內搭建鏡像站點，數據進行定時更新或者實時更新。有不少專業的現成的解決架構和產品可選。也有廉價的經過軟件實現的思路，好比Linux上的rsync等工具。

   12、圖片服務器分離

你們知道，對於Web服務器來講，不論是Apache、IIS仍是其餘容器，圖片是最消耗資源的，因而咱們有必要將圖片與頁面進行分離，這是基本上大型網站都會採用的策略，他們都有獨立的、甚至不少臺的圖片服務器。這樣的架構能夠下降提供頁面訪問請求的服務器系統壓力，而且能夠保證系統不會由於圖片問題而崩潰。

在應用服務器和圖片服務器上，能夠進行不一樣的配置優化，好比apache在配置ContentType的時候能夠儘可能少支持、儘量少的LoadModule，保證更高的系統消耗和執行效率。