高併發解決方案

2021-06-11 00:08:34 字數 1188 閱讀 2998

時常看到高併發的問題,但高併發其實是最不需要考慮的東西。為何,他虛無縹緲,很少有**真的需要這些東西,而且其中很多技術,其實你已經在用了。有這個意識就夠了,不需要時刻盯著這個問題。只有很少的**真的能達到高併發。 

簡單做乙個歸納,從低成本、高效能和高擴張性的角度來說有如下處理方案: 

1、html靜態化 

2、伺服器分離 

3、資料庫集群和庫表雜湊 

4、快取 

5、映象 

6、負載均衡;乙個典型的使用負載均衡的策略就是,在軟體或者硬體四層交換的基礎上搭建squid集群,這種思路在很多大型**包括搜尋引擎上被採用,這樣的架構低成本、高效能還有很強的擴張性,隨時往架構裡面增減節點都非常容易。 

下面也是乙個總結,跟上面部分相同。 

高併發時,效能瓶頸及當前常用的應對措施 

1.資料庫瓶頸。mysql併發鏈結100 

2.apache 併發鏈結1500 

3.程式執行效率 

1.有資料庫瓶頸時,當前處理方案無外乎 主從,集群。增加cache(memcached). 

如:手機之家新系統介紹及架構分享( 

就是在cache層做優化 

又拍網架構( 

是以增加資料庫,分表分庫的方法解決。 

sina增加了mq(訊息佇列)來分發資料。 

還有風站用了key-value的資料庫。其實這可以理解成乙個持久化的快取。 

2.apache瓶頸。 

增加伺服器。負載均衡。如sina的f5 

由於程序數的限制。會把一些基本不變的**挪出來放到單獨的伺服器。如css/js/。 

國內成功的案例是tom的cdn 

又如nginx的橫空出世和squid的反向**都是基於這個原因出來的。 

3.php的執行效率。原因有多個。 

1).本身的效率低。 

解決的成功案例是zend optimizer 和 facebooke的hiphop 

taobao是把php**編譯成模組解決效率問題。 

2). 資料庫查詢效率問題。如可能有order by ,group by 等sql資料問題。 

這個其實應該歸結到資料庫設計問題。 

解決的辦法是建立正確的索引。增加memcache.。 

對like表 用專用的sphinx.和lucence 等搜尋服務。 

程式設計師都應該會用explain對sql語句作分析。 

高併發解決方案

將靜態資源分離到靜態站,對靜態資源的請求打到靜態站,增加動態站的請求處理量 頁面靜態化是將程式生成的頁面儲存起來,使用模板技術如freemarker和velocity生成靜態頁面 nginx快取頁面資訊,再次請求時直接從快取中獲取,不需要重新生成,頁面快取記憶體中,提高訪問速度 具有相同處理功能的伺...

高併發解決方案

秒殺場景一般會在電商 舉行一些活動或者節假日在12306 上搶票時遇到。對於電商 中一些稀缺或者 商品,電商 一般會在約定時間點對其進行限量銷售,因為這些商品的特殊性,會吸引大量使用者前來搶購,並且會在約定的時間點同時在秒殺頁面進行搶購。限流 鑑於只有少部分使用者能夠秒殺成功,所以要限制大部分流量,...

高併發解決方案2

大型 在面對大量使用者訪問 高併發請求方面,基本的解決方案集中在這樣幾個環節 使用高效能的伺服器 高效能的資料庫 高效率的程式語言 還有高效能的web容器。但是除了這幾個方面,還沒法根本解決大型 面臨的高負載和高併發問題。1 html靜態 對於互動性要求很高的社群型別 來說,盡可能的靜態化也是提高效...