（1）單塊架構
（2）初步的高可用架構
（3）千萬級使用者量的壓力預估
（4）伺服器壓力預估
（5）業務垂直拆分
（6）用分布式緩存抗下讀請求
（7）基于資料庫主從架構做讀寫分離
（8）總結
本文将會從一個大型的網站發展曆程出發，一步一步的探索這個網站的架構是如何從單體架構，演化到分布式架構，然後演化到高并發架構的。
一、單塊架構
一般一個網站剛開始建立的時候，使用者量是很少的，大概可能就幾萬或者幾十萬的使用者量，每天活躍的使用者可能就幾百或者幾千個。
這個時候一般網站架構都是采用單體架構來設計的，總共就部署3台伺服器，1台應用伺服器，1台資料庫伺服器，1台圖檔伺服器。
研發團隊通常都在10人以内，就是在一個單塊應用裡寫代碼，然後寫好之後合并代碼，接着就是直接線上上的應用伺服器上釋出。很可能就是手動把應用伺服器上的Tomcat給關掉，然後替換系統的代碼war包，接着重新啟動Tomcat。
資料庫一般就部署在一台獨立的伺服器上，存放網站的全部核心資料。
然後在另外一台獨立的伺服器上部署NFS作為圖檔伺服器，存放網站的全部圖檔。應用伺服器上的代碼會連接配接以及操作資料庫以及圖檔伺服器。如下圖所示：
二、初步的高可用架構
但是這種純單塊系統架構下，有高可用問題存在，最大的問題就是應用伺服器可能會故障，或者是資料庫可能會故障
是以在這個時期，一般稍微預算充足一點的公司，都會做一個初步的高可用架構出來。
對于應用伺服器而言，一般會叢集化部署。當然所謂的叢集化部署，在初期使用者量很少的情況下，其實一般也就是部署兩台應用伺服器而已，然後前面會放一台伺服器部署負載均衡裝置，比如說LVS，均勻的把使用者請求打到兩台應用伺服器上去。
如果此時某台應用伺服器故障了，還有另外一台應用伺服器是可以使用的，這樣就避免了單點故障問題。如下圖所示：
對于資料庫伺服器而言，此時一般也會使用主從架構，部署一台從庫來從主庫同步資料，這樣一旦主庫出現問題，可以迅速使用從庫繼續提供資料庫服務，避免資料庫故障導緻整個系統都徹底故障不可用。如下圖：
三、千萬級使用者量的壓力預估
這個假設這個網站預估的使用者數是1000萬，那麼根據28法則，每天會來通路這個網站的使用者占到20%，也就是200萬使用者每天會過來通路。
通常假設平均每個使用者每次過來會有30次的點選，那麼總共就有6000萬的點選（PV）。
每天24小時，根據28法則，每天大部分使用者最活躍的時間集中在（24小時 * 0.2）≈ 5小時内，而大部分使用者指的是（6000萬點選 * 0.8 ≈ 5000萬點選）
也就是說，在5小時内會有5000萬點選進來。
換算下來，在那5小時的活躍通路期内，大概每秒鐘會有3000左右的請求量，然後這5小時中可能又會出現大量使用者集中通路的高峰時間段。
比如在集中半個小時内大量使用者湧入形成高峰通路。根據線上經驗，一般高峰通路是活躍通路的2~3倍。假設我們按照3倍來計算，那麼5小時内可能有短暫的峰值會出現每秒有10000左右的請求。
四、伺服器壓力預估
大概知道了高峰期每秒鐘可能會有1萬左右的請求量之後，來看一下系統中各個伺服器的壓力預估。
一般來說一台虛拟機部署的應用伺服器，上面放一個Tomcat，也就支撐最多每秒幾百的請求。
按每秒支撐500的請求來計算，那麼支撐高峰期的每秒1萬通路量，需要部署20台應用服務。
而且應用伺服器對資料庫的通路量又是要翻幾倍的，因為假設一秒鐘應用伺服器接收到1萬個請求，但是應用伺服器為了處理每個請求可能要涉及到平均3~5次資料庫的通路。
按照3次資料庫通路來算，那麼每秒會對資料庫形成3萬次的請求。
按照一台資料庫伺服器最高支撐每秒5000左右的請求量，此時需要通過6台資料庫伺服器才能支撐每秒3萬左右的請求。
圖檔伺服器的壓力同樣會很大，因為需要大量的讀取圖檔展示頁面，這個不太好估算，但是大緻可以推算出來每秒至少也會有幾千次請求，是以也需要多台圖檔伺服器來支撐圖檔通路的請求。
五、業務垂直拆分
一般來說在這個階段要做的第一件事兒就是業務的垂直拆分
因為如果所有業務代碼都混合在一起部署，會導緻多人協作開發時難以維護。在網站到了千萬級使用者的時候，研發團隊一般都有幾十人甚至上百人。
是以這時如果還是在一個單塊系統裡做開發，是一件非常痛苦的事情，此時需要做的就是進行業務的垂直拆分，把一個單塊系統拆分為多個業務系統，然後一個小團隊10個人左右就專門負責維護一個業務系統。如下圖
六、分布式緩存扛下讀請求
這個時候應用伺服器層面一般沒什麼大問題，因為無非就是加機器就可以抗住更高的并發請求。
現在估算出來每秒鐘是1萬左右的請求，部署個二三十台機器就沒問題了。
但是目前上述系統架構中壓力最大的，其實是資料庫層面 ，因為估算出來可能高峰期對資料庫的讀寫并發會有3萬左右的請求。
此時就需要引入分布式緩存來抗下對資料庫的讀請求壓力了，也就是引入Redis叢集。
一般來說對資料庫的讀寫請求也大緻遵循28法則，是以每秒3萬的讀寫請求中，大概有2.4萬左右是讀請求
這些讀請求基本上90%都可以通過分布式緩存叢集來抗下來，也就是大概2萬左右的讀請求可以通過 Redis叢集來抗住。
我們完全可以把熱點的、常見的資料都在Redis叢集裡放一份作為緩存，然後對外提供緩存服務。
在讀資料的時候優先從緩存裡讀，如果緩存裡沒有，再從資料庫裡讀取。這樣2萬讀請求就落到Redis上了，1萬讀寫請求繼續落在資料庫上。
Redis一般單台伺服器抗每秒幾萬請求是沒問題的，是以Redis叢集一般就部署3台機器，抗下每秒2萬讀請求是絕對沒問題的。如下圖所示：
七、基于資料庫主從架構做讀寫分離
此時資料庫伺服器還是存在每秒1萬的請求，對于單台伺服器來說壓力還是過大。
但是資料庫一般都支援主從架構，也就是有一個從庫一直從主庫同步資料過去。此時可以基于主從架構做讀寫分離。
也就是說，每秒大概6000寫請求是進入主庫，大概還有4000個讀請求是在從庫上去讀，這樣就可以把1萬讀寫請求壓力分攤到兩台伺服器上去。
這麼分攤過後，主庫每秒最多6000寫請求，從庫每秒最多4000讀請求，基本上可以勉強把壓力給抗住。如下圖：
八、總結
本文主要是探讨在千萬級使用者場景下的大型網站的高并發架構設計，也就是預估出了千萬級使用者的通路壓力以及對應的背景系統為了要抗住高并發，在業務系統、緩存、資料庫幾個層面的架構設計以及抗高并發的分析。
但是要記住，大型網站架構中共涉及的技術遠遠不止這些，還包括了MQ、CDN、靜态化、分庫分表、NoSQL、搜尋、分布式檔案系統、反向代理，等等很多話題，但是本文不能一一涉及，主要是在高并發這個角度分析一下系統如何抗下每秒上萬的請求。