1.實(shí)現(xiàn)一個(gè)多并發(fā)的網(wǎng)站任務(wù)，開(kāi)始做的時(shí)候并不知道實(shí)際的并發(fā)量會(huì)有多少，經(jīng)過(guò)討論決定使用如下的流程方式
2.解釋一下，收到客戶端發(fā)過(guò)來(lái)的請(qǐng)求后，通過(guò)負(fù)載均衡分配到空閑的web服務(wù)器進(jìn)行請(qǐng)求處理，請(qǐng)求期間的操作都是使用redis作為數(shù)據(jù)讀取和存儲(chǔ)（不要用數(shù)據(jù)庫(kù)，要不然會(huì)出現(xiàn)MySQL連接數(shù)過(guò)大，服務(wù)器卡死的情況），然后購(gòu)票成功后再寫(xiě)入數(shù)據(jù)庫(kù)中。下面分布解說(shuō)
3.首先需要用到負(fù)載均衡，不要以為很麻煩，現(xiàn)在很方便，阿里云就提供相應(yīng)的服務(wù)，直接購(gòu)買就好，然后將服務(wù)器綁定到負(fù)載均衡實(shí)例中，域名指向負(fù)載均衡實(shí)例就好，可以寫(xiě)兩個(gè)靜態(tài)頁(yè)面分別放到web服務(wù)器1和web服務(wù)器2中，不停刷新看看是否是請(qǐng)求到不同的服務(wù)器了。
4.負(fù)載均衡可以跑通知之后將自己的代碼傳到兩臺(tái)服務(wù)器中，然后測(cè)試能否跑起來(lái)。
5.在測(cè)試過(guò)程中發(fā)現(xiàn)用戶登錄有問(wèn)題，因?yàn)槭琴?gòu)票系統(tǒng)，所以肯定存在用戶模塊，這里用戶登錄使用session存儲(chǔ)的，所以搭建負(fù)載均衡還牽扯到一個(gè)session共享的問(wèn)題。不過(guò)用到的是laravel框架，框架里面的session默認(rèn)是使用文件存儲(chǔ)方式，支持redis存儲(chǔ)，而我們兩臺(tái)web服務(wù)器連接的是同一個(gè)redis服務(wù)器，所以將存儲(chǔ)方式換成redis存儲(chǔ)后就解決了問(wèn)題。其他不支持的框架也可以使用memcache,數(shù)據(jù)庫(kù)等解決，方法很多，可以單獨(dú)看看這方面的解決方法。
6.代碼傳到服務(wù)器也能跑通之后，就需要進(jìn)行壓力測(cè)試了。
7.使用的服務(wù)器配置是2臺(tái)2核8G內(nèi)存5M寬帶的web服務(wù)器，一臺(tái)4核16的數(shù)據(jù)庫(kù)redis服務(wù)器。
8.并發(fā)測(cè)試工具阿里云也有，買了一個(gè)便開(kāi)始測(cè)試，但實(shí)際測(cè)試過(guò)程中發(fā)現(xiàn)與理想的差距甚大，4百并發(fā)便已經(jīng)有不少失敗請(qǐng)求。
9.優(yōu)化吧，首先修改了一下nginx和php-fpm之間的通信方式，把原來(lái)TCP修改成了UNIX Domain Socket.相比之下減少了很多tcp/ip層，物理層，路由層之間的連接，再跑一邊，效果好了一點(diǎn)點(diǎn)。
10.然后發(fā)現(xiàn)再跑壓測(cè)的時(shí)候，活躍進(jìn)程數(shù)很低，發(fā)現(xiàn)PHP里面的配置max_children本來(lái)就很小，然后按照網(wǎng)上說(shuō)的計(jì)算方式，把值調(diào)整到了400，接著監(jiān)聽(tīng)，發(fā)現(xiàn)是好很多，但是活躍進(jìn)程一直到60~80就上不去了，而查看cup，負(fù)載等都已經(jīng)到100%，原來(lái)cpu忙不過(guò)來(lái)了。。。
11.升級(jí)cpu，到8核，內(nèi)存升級(jí)到16G，然后max_children調(diào)整到了800，哇哦，質(zhì)的飛躍，還是硬件給力，并發(fā)一兩千還是支持的住的。
12.想要支持的并發(fā)跟多的話，可以通過(guò)增加web服務(wù)器來(lái)分擔(dān)負(fù)載，程序優(yōu)化優(yōu)化，服務(wù)器方面的優(yōu)化還有待提升，后面慢慢研究吧。
粵公網(wǎng)安備 44010602005325號(hào)