支模網(wǎng)整體開發(fā)到上線為10個月左右，后端采用php開源框架destoon，站點總數(shù)據(jù)為800萬，其中每天會更新入庫數(shù)據(jù)5000-50000數(shù)據(jù)不等，日流量光手機端熊掌號流量為：8000以上
加上其他搜索引擎和用戶鏈接直接進了的流量，每天日流量在1w以上，因為公司是單臺服務器，配置也比較低，還需要每天數(shù)據(jù)入庫文件，數(shù)據(jù)庫之前一直會奔潰狀態(tài)，所以自己通過以下的優(yōu)化思路進行優(yōu)化，效果好轉(zhuǎn)了許多，希望廣大朋友可以參考借鑒，如有不足，可以指出更好的方法。大家一起進步！
1.了解你的網(wǎng)站和項目到底有多大的流量和并發(fā)？
當項目的用戶量達到一定規(guī)模以后，網(wǎng)站往往會經(jīng)常出現(xiàn)502 bad gateway(nginx),連接超時(apache)，mysql拒絕連接等問題。這個時候，一般的理解就是網(wǎng)站的訪問量比較大，請求數(shù)比較高，所以服務器不堪重負，開小差去了。這個時候最快的解決辦法一般就是重啟apache,nginx或mysql，當然這個不能解決根源，只是臨時解決一下而已。
那么，首先你應該清楚你的網(wǎng)站的流量到底有多大？每秒的流量到底有多高？cpu占用峰值是多少？對于這個問題，首當其沖方案的肯定使用是監(jiān)控軟件了，這類的監(jiān)控軟件比較多，有cacti（完全圖形化的流量監(jiān)控工具），zabbix（支持各種數(shù)據(jù)的監(jiān)控且可自己擴展監(jiān)控模塊并集成報警功能，非常強大！）所以第一步你就一定要先在所有服務器上安裝監(jiān)控客戶端，如cacti的snmp，zabbix的zabbix_client，然后搭建自己的監(jiān)控服務端。然后靜默收集數(shù)據(jù)一段時間，可以是幾天也可以是一周。然后了解服務器的峰值是多少，平均值是多少，cpu占用，內(nèi)存占用。這樣你能先做到對服務器的狀態(tài)心里有底。
2.查找高并發(fā)源泉
如果服務器一直運行得比較正常，但突然一段時間經(jīng)常出現(xiàn)502，超時，超高cpu時，排除流量的超大幅度增長以外的原因，那么原因就有可能是程序卡死了或服務器硬件故障。如果排除硬件故障以后這個時候最好第一步查詢mysql、php、nginx、apache的錯誤日志，慢日志，定位根源文件及代碼塊，往往新功能如果沒有經(jīng)過完整的測試就上線，就非常容易引起這類的問題。
比如我們的一臺線上服務器有段時間曾經(jīng)上線了一個新功能，就是要求在某代碼模塊中將mysql服務器地址更改為其它機房的mysql服務器，由于代碼沒有經(jīng)過嚴格的測試，而直接使用了mysql_connect重新連接。在這個功能上線以后，服務器經(jīng)常出現(xiàn)502，超時，cpu90%。后來排查時才看到這里，由于其它機房的網(wǎng)絡問題引起mysql_connect超慢，所以大量的mysql_connect卡死在這里引起了阻塞。另外一個統(tǒng)計模塊的file_get_contents也是同樣的問題，所以我們在后面的開發(fā)中要求一定要禁止使用file_get_contents，另外mysql_connect也要限制超時的時間。
如果程序上沒有問題，那就要從數(shù)據(jù)庫或隊列上去查找原因了。數(shù)據(jù)庫上的問題會非常多，比如一條沒有經(jīng)常優(yōu)化的sql語句引起表的鎖死啊，mysql并發(fā)量達到預設峰值，表崩潰啊，等待進程過多啊等等。
3.使用隊列和緩存
經(jīng)驗告訴我們，隊列和緩存絕對是解決高并發(fā)的非常有效的辦法。比如郵件發(fā)送，這類功能其實客戶端并不需要等待完成，所以我們在前端只需要一直把要發(fā)送的郵件地址，內(nèi)容等一并放到隊列里，后臺程序慢慢從隊列里面去取就ok。對于隊列的解決方案有許多，比如memcache，redis等。
關(guān)于memcache，前段時間嘗試自己用memcache來寫了一個隊列，平臺windows。最終效果非常不理想，在循環(huán)的get或set時，memcache會顯得非常緩慢，并且最終的命中率一點都不高。在windows平臺上的redis會由于pull的不支持造成在高并發(fā)時經(jīng)常redis server gone away的情況。在*inux平臺上，redis表現(xiàn)了非常棒的性能和穩(wěn)定性，目前公司線上產(chǎn)品在使用redis后，已經(jīng)非常穩(wěn)定，所以redis絕對是值得使用的神器。
4.特別注意阻塞
這是一個非常嚴重的問題。http上的阻塞，mysql的阻塞，阻塞的結(jié)果將是服務器不能正常響應請求，cpu居高不下，并且很難發(fā)現(xiàn)問題。這要求我們在開發(fā)階段，對于容易引起阻塞的地方一定要特別注意，如果某段代碼執(zhí)行的時間會非常長，就一定要交給子進程來做這個事情。對于這個情況，node.js是一個非常好的解決方案，因為node.js正是為非阻塞而生的。并且這幾年node.js發(fā)展迅速，各類模塊越來越多，也越來越穩(wěn)定，框架的出現(xiàn)也大大的提升了代碼編寫的速度，像express和eventproxy這類的，新手可以非常快的開發(fā)一個node.js未阻塞應用。
5.數(shù)據(jù)庫的優(yōu)化
在高并發(fā)和大數(shù)據(jù)量的情況下，分表分庫是一定要的，并且盡量按模塊分。不要相信分區(qū)，分區(qū)這貨非常容易引起表崩潰，特別是myisam引擎下，分區(qū)不僅會在一個文件夾下產(chǎn)生一堆的文件，還非常有可能因為打開的文件句柄過多而出現(xiàn)各種mysql錯誤。
根據(jù)情況選擇不同的引擎或數(shù)據(jù)庫軟件，myisam,innodb等引擎要在不同的情況下使用，mysiam適用于查詢多，插入少；innodb適用于寫入多，查詢少和事務支持。nosql也是非常值得嘗試的產(chǎn)品，php對mongdb的支持還行，操作也挺方便的。
m/s在高并發(fā)下存在延遲問題，臨時解決方案是可以用緩存。
6.靜態(tài)資源與動態(tài)分離
帶寬是非常珍貴和昂貴的。有條件一定要使用cdn，在速度上提升會非常明顯，同時也能保證動態(tài)程序服務器的穩(wěn)定。
好了，以上就是近期總結(jié)的一些經(jīng)驗。
作者68喜科技的原創(chuàng)作品，如需轉(zhuǎn)載，請注明出處，否則將追究法律責任
轉(zhuǎn)載地址：https://blog.51cto.com/11024720/2321644


深圳到安順物流專線
合肥到正定物流專線
南京到興安盟物流專線
杭州到馬鞍山物流專線
青島到肥城物流專線
從企業(yè)數(shù)字化轉(zhuǎn)型到云原生解決方案
新型的網(wǎng)站建設該怎樣抓住用戶？
江西租用服務器需要多少錢？