採用什麼架構,才能夠承受大訪問量
一般情況下,架構分兩種來討論的,一種是開發架構,一種是部署架構
部署架構,就是開發完的程式在實際執行環境下,通過負載均衡,DNS輪詢,SquID等等來減輕單臺伺服器負載,達到效能優化的目的
這裡大家估計更想了解的是開發上的架構
我對這個的觀點是,所有的架構都是死的,而效能優化策略是活的,我在開發中,所有的東西都不是一定要按照什麼固定的模式,去死開發,更多的是針對需要優化的資訊進行鍼對處理,下面說說我的優化策略
1、資料庫優化,這個是所有的優化策略中中重要的,可以說資料庫設計的好壞,直接影響了一個系統的承受力。普通的資料庫細節優化,網上已經有大筆文章了,沒什麼好說的,想了解的自己去找。而我要說的就是在資料庫設計中的一個思路,分庫、分表、快取表。
1)分庫指的是在設計中,要考慮到後期資料量大的情況下,你的資料庫能夠隨著應用隨時拆分,這個拆分並不是只是針對功能模組對應的資料拆分。舉個例子,就用這個CSDN論壇吧,比如裡面有很多類,C#版,JAVA版,系統設計版等等,拆分的目的是可以把任何一個版的資料拆分到單獨的一個數據庫中去。
2)分表相對的就好理解了,就是說同類型的資料,你可以為了效能優化,進行拆分到多個表中去,拆分規則可以有多種,按照型別、按照時間、按照姓名等等。同樣以這個CSDN論壇來說,我要設計的話,我會按照裡面的大版面進行資料庫拆分,而按照小版,進行表拆分。
3)而對於快取表,網上我還很少看到有人來說這個東西,這個的目的就是針對一個大的資料表中,一般中有死資料庫和活動資料,比如使用者表,裡面有很多基本不來的使用者,那麼針對這樣的情況,當表資料上了千萬的時候,我就會採用快取表的模式來進行了,就是在實際表和使用者之間在搭建一個臨時表,訪問使用者資料時,首先訪問臨時表,如果不存在,則進入實際表中獲取,然後放入快取表中,同時會通過後臺執行緒,定時將快取表資料同步到實際資料庫中,同步時間可以針對系統要求來進行。
如果理解了上面的東西,那麼在資料承載上,可以上升一個很大的層次。。。。。
2、程式優化。這個對我來說相對的就不是那麼的看中了,程式的優化,我更多的認為是個技巧,而不是架構了,包括現在經常見到的那些各種設計模式,另外這裡提下,很多設計模式,他的出發點並不是效能優化,而是考慮的系統擴充套件性,所以在單個技術細節上,很多人也發現了,並不如直接的寫程式碼來的快,但是就是推薦那樣,是因為採用了那些模式的程式,擴充套件性比你的強,那麼一旦系統要求變動,或者是要求進行拆分的時候要比你方便的多,在分擔到多個伺服器上時,效能相對的就起到了優化也。廢話了通,繼續說我對程式部分經常採用的方式吧
1) 首推靜態化,這個的優化效果不用多說,直接減輕了伺服器負擔,不過如果用上了Squid,那麼有第三放來做靜態,也可以達到同樣的效果
2) 合適的資料快取,快取很多人都用到了,但是在使用前,是否認真思考過為這個這個要進行Cache,Cache他的標準是什麼?我說下我的標準:小資料量、大訪問量、更新儘量少的資料,全部可以進行快取。另外我提到的快取,並不只是說。NET本身提供的Cache,我說的快取還包括了使用Static來進行的資料
3) 活用執行緒,很多人的觀念中感覺執行緒好象在B/S中是用不到的,或者是沒有必要。其實這個觀念完全錯,在特定情況下使用執行緒,可以提高的區域性效能不是一點兩點
4) 功能模組拆分,這個一般人基本都在做,我要補充的是,不只是在單個專案中進行功能模組的拆分,而是為了進行分步式開發而進行拆分
在其它的基本都是細節優化了,這個沒有太多興趣寫了,網上資料應該不少,可以自己搜尋查閱
上面的這幾部分如果能在開發中,靈活運用上,可以說,你開發個CSDN這樣規模的站點,絕對不是難事。
我曾經開發的過的站點中,也有過社群,一個WEB 伺服器,一個DB伺服器,主題帖千萬,回覆帖有6000W左右吧,其它資料不算,執行過程中沒出過任何問題,日訪問在100W PV情況下,還沒有達到效能瓶頸