關於高併發問題

全文從CSDN的 zhangnana200  轉載而來，其中涉及的一些知識點，留着後續研究

 

門戶高併發處理方案

 

我的總結：

 

1：動靜分離；能夠作成靜態頁面的部分，由後臺發佈系統發佈爲靜態頁面；

 

2：增長外部系統訪問方式，可使用webservice和mq接口方式；

 

3：增長定時任務處理，對於不須要及時處理的信息，用定時任務處理；

 

4：增長登陸方式；

 

5：限定登陸頻率，對於一些登陸成功率較低的IP進行限定，對於一些登陸連續失敗的IP，鎖定登陸；

 

6：在數據庫上添加索引，減小對子表的查詢，提高效率；

 

7：優化查詢sql;

 

8：增長死鎖監控，出現死鎖後，能夠定位出某個SQL出現了死鎖，而後優化代碼；

 

9：儘可能使用緩存，好比用戶信息緩存等。

 

 

接口高併發：

若是接口調用頻繁（高併發），會出現問題，那麼如何解決，

1：優化查詢sql；

2：在數據庫表上加索引，以避免對子表操做的時候全表查詢。

3：接口異步處理，好比當接口調用到來時，直接返回成功，啓動子線程，經過mq或者webservice接口，處理業務邏輯並調用子系統；

4：分mq和webservice兩種接口調用；

5：數據庫創建死鎖監控，若是出現死鎖，能夠直接定位到某一個sql ，優化代碼；

6：對於不須要及時處理的問題，能夠保存到數據庫，由定時任務執行；

7：對於共享資源，確保同一順序訪問。

 

下面是網絡轉載

簡單作一個概括，從低成本、高性能和高擴張性的角度來講有以下處理方案： 
  一、HTML靜態化 
  二、圖片服務器分離 
  三、數據庫集羣和庫表散列 
  四、緩存 
   五、鏡像 
   六、負載均衡;一個典型的使用負載均衡的策略就是，在軟件或者硬件四層交換的基礎上搭建squid集羣，這種思路在不少大型網站包括搜索引擎上被採用，這樣的架構低成本、高性能還有很強的擴張性，隨時往架構裏面增減節點都很是容易。 

 

下面也是一個牛人所作的總結，跟上面部分相同。 
高併發時，性能瓶頸及當前經常使用的應對措施 


1.數據庫瓶頸。Mysql併發連接100 

2.apache 併發連接1500 

3.程序執行效率 



1.有數據庫瓶頸時，當前處理方案無外乎 主從，集羣。增長cache(memcached). 

如：手機之家新系統介紹及架構分享（http://www.slideshare.net/Fenng/ss-1218991?from=ss_embed） 

就是在cache層作優化 

又拍網架構（http://www.bopor.com/?p=652） 

是以增長數據庫，分表分庫的方法解決。 

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語句做分析。 


說到底。解決高併發就是上面所列技術，程序員要作的就是把每一個技術具體實現。