看的qps；如果qps有上萬(wàn)，建議使用go為一個(gè)高并發(fā)接口服務(wù)；其它業(yè)務(wù)可以使用webman；然后nginx作為代理負(fù)載

我主要這個(gè)不是常駐內(nèi)存么，萬(wàn)一進(jìn)程卡住了咋辦

你之前用過(guò)webman么，覺(jué)得如何

除非數(shù)據(jù)庫(kù)有問(wèn)題掛了，不然怎么會(huì)卡住？webman我們一直在用，性能確實(shí)比f(wàn)pm的好非常多。

嗯

之前沒(méi)搞過(guò)高并發(fā)的，很多工具都不熟悉，嗯，謝謝

嗯，是呀，就是覺(jué)得牽扯太多。

務(wù)實(shí)??

另外再多提一嘴,你這個(gè)業(yè)務(wù)算是比較簡(jiǎn)單的秒殺邏輯(至少?gòu)拿枋鲋锌雌饋?lái)比較簡(jiǎn)單),可以考慮在業(yè)務(wù)上做優(yōu)化(如果可以),采用先扣庫(kù)存再進(jìn)行后續(xù)邏輯處理的方式(比如隊(duì)列),比較典型的例子就是常見(jiàn)的"優(yōu)惠券將會(huì)在稍后發(fā)放到您的賬戶中"這種, 前面上個(gè)負(fù)載均衡,平時(shí)就一臺(tái)機(jī)器,發(fā)券前提前多開(kāi)幾臺(tái),結(jié)束后降回一臺(tái)

是的，現(xiàn)在用的就是，除了會(huì)員的生成用mysql有點(diǎn)大，其他都放到了redis里，然后服務(wù)器有個(gè)計(jì)劃任務(wù)負(fù)責(zé)發(fā)券，當(dāng)前自己用到時(shí)沒(méi)啥問(wèn)題。

客戶想包裝成產(chǎn)品，做云端，買個(gè)其他各城市的部門來(lái)發(fā)券，相當(dāng)于重新搞一個(gè)新系統(tǒng)再。

負(fù)載均衡還沒(méi)有上，這幾天正在研究nginx搞這個(gè)，現(xiàn)在有3臺(tái)服務(wù)器，打算用最弱的一臺(tái)做分發(fā)，其他兩臺(tái)方程序。

@nitron 現(xiàn)在mysql是了一臺(tái)高性能的數(shù)據(jù)庫(kù)服務(wù)器，但是還是感覺(jué)慢，想做主從，不過(guò)之前沒(méi)弄過(guò)，還沒(méi)有搭建好。

上次在客戶公眾號(hào)上搞，因?yàn)橐跈?quán)，必須跳轉(zhuǎn)一次PHP做會(huì)員初始化，結(jié)果一次來(lái)太多人，當(dāng)時(shí)開(kāi)了1000個(gè)靜態(tài)的fpm進(jìn)程，卡在那里不動(dòng)了。

最后過(guò)了十分鐘還那樣，重啟了phpfpm后好了，我覺(jué)得是cpu（8核）已經(jīng)到頭了沒(méi)能力處理進(jìn)程了。

授權(quán)這個(gè),因?yàn)閺墓娞?hào)獲取用戶信息需要服務(wù)器向微信服務(wù)器發(fā)起一個(gè)Http請(qǐng)求,這個(gè)涉及第三方系統(tǒng),沒(méi)辦法.
注意不要重復(fù)獲取access_token就好

是的，這個(gè)沒(méi)有，access_token都是緩存了的，就是一次太多人訪問(wèn)。。不過(guò)也的確沒(méi)有好的辦法，下次弄負(fù)載均衡估計(jì)就解決了。

大佬發(fā)言給力呀，先優(yōu)化，實(shí)在扛不住了再換webman，也別一下子全搬過(guò)來(lái)，高并發(fā)的請(qǐng)求可以用webman處理，多異步，這么高并發(fā)的請(qǐng)求應(yīng)該不會(huì)有新增完數(shù)據(jù)就要看的，mysql的增加刪除和修改全給它異步了，查詢緩存一做基本io上redis扛得住，就問(wèn)題不大

@tanhongbin 【這么高并發(fā)的請(qǐng)求應(yīng)該不會(huì)有新增完數(shù)據(jù)就要看的，mysql的增加刪除和修改全給它異步了】是什么意思哈？求

為啥那？swoole似乎學(xué)習(xí)成本有點(diǎn)高

IO操作多的話Swoole表現(xiàn)會(huì)更好，workerman在異步這塊現(xiàn)在可以說(shuō)是空白

哦，我了解下。

他本來(lái)就是沒(méi)有常駐內(nèi)存的經(jīng)驗(yàn)，直接上swoole玩php協(xié)程非常不推薦，學(xué)習(xí)swoole的難度不亞于學(xué)習(xí)一門新語(yǔ)言例如go。
如果系統(tǒng)瓶頸在數(shù)據(jù)庫(kù)，那上啥也沒(méi)用。如果瓶頸在框架性能低下，上webman是很好的選擇，學(xué)習(xí)基本沒(méi)有成本，同樣的代碼寫(xiě)法性能提高數(shù)倍，穩(wěn)定性也好與swoole，并且性能也比swoole高。

感謝各位兄弟的建議，嗯，項(xiàng)目也比較緊，學(xué)習(xí)太久估計(jì)不行，就一個(gè)月時(shí)間。

如果說(shuō)沒(méi)有扎實(shí)的網(wǎng)絡(luò)與操作系統(tǒng)相關(guān)的基礎(chǔ)或經(jīng)驗(yàn)，別說(shuō)用swoole了，就是用了go也難解決性能瓶頸！～
深（身）有體會(huì)！！ ^_^

看來(lái)要惡補(bǔ)基礎(chǔ)知識(shí)啦

說(shuō)的不錯(cuò),記得我以前剛開(kāi)始工作的時(shí)候,有個(gè)項(xiàng)目每天零點(diǎn)要執(zhí)行任務(wù),當(dāng)時(shí)項(xiàng)目有8,9萬(wàn)個(gè)會(huì)員以后,執(zhí)行任務(wù)需要2,3個(gè)小時(shí)才執(zhí)行完,但是現(xiàn)在如果讓我再執(zhí)行同樣的任務(wù),也就是十幾分鐘的事情.

你現(xiàn)在咋搞的？

減少數(shù)據(jù)庫(kù)查詢,批量插入或者更新數(shù)據(jù)庫(kù),這些是從代碼層面去優(yōu)化sql. 一個(gè)接口能少查詢一次sql,那高并發(fā)下一秒就是少上千次查詢.

??

為什么不學(xué)go?

好吧

怎么突然問(wèn)這個(gè)了。

哇~

用redis了么，如果用了是放到了一臺(tái)業(yè)務(wù)服務(wù)器上了么

沒(méi)有用到redis

那mysql壓力很大呀

我問(wèn)下，你每個(gè)業(yè)務(wù)的機(jī)器上就是啟動(dòng)了一個(gè)webman是吧。

使用docker打包部署服務(wù)，每臺(tái)機(jī)子部署2個(gè)

對(duì)于mysql和redis，如果有預(yù)算并且是要短期保證業(yè)務(wù)穩(wěn)定，個(gè)人建議使用云服務(wù)。比如阿里云的云rds或云redis，都有集群版的，比自己部署的要好要穩(wěn)定要便捷。自己部署的話，非專業(yè)運(yùn)維，包括調(diào)優(yōu)，監(jiān)控等等都會(huì)比較麻煩，并且單機(jī)部署，流量，性能和IO，都會(huì)有瓶頸。

你這邊是如何發(fā)券的，減庫(kù)存跳轉(zhuǎn)鏈接用戶點(diǎn)擊領(lǐng)取 或 減庫(kù)存調(diào)用api接口？

減庫(kù)存，然后后臺(tái)有個(gè)計(jì)劃任務(wù)負(fù)責(zé)發(fā)券。

計(jì)算任務(wù)是crontab，還是？

嗯嗯，是crontab

以下思路，僅供參考：

1. 流量分流（前端資源加cdn或放在對(duì)象存儲(chǔ)上；后端的用作負(fù)載的服務(wù)器，性能要好，帶寬要高，保證接口請(qǐng)求的流量穩(wěn)定）
2. 后端服務(wù)負(fù)載均衡（后端服務(wù)多臺(tái)服務(wù)器部署，負(fù)載處理業(yè)務(wù)，后續(xù)有壓力可擴(kuò)容）
3. 云mysql 或 云redis 做庫(kù)存處理（mysql的原子操作 或 redis的lua腳本執(zhí)行 保證不會(huì)超發(fā)）
4. 消息中間件做發(fā)券處理（redis消息隊(duì)列或rabbitmq等，減庫(kù)存后，將發(fā)券任務(wù)交給中間件，多個(gè)消費(fèi)者服務(wù)同時(shí)發(fā)券處理）

使用crontab會(huì)造成任務(wù)堆積的

現(xiàn)在是在一個(gè)內(nèi)存最大的服務(wù)器上安置了redis，所在的云上沒(méi)有云redis，這時(shí)候其他機(jī)器通過(guò)局域網(wǎng)訪問(wèn)這臺(tái)機(jī)器的redis你覺(jué)得會(huì)不會(huì)有問(wèn)題那？

還有問(wèn)個(gè)問(wèn)題哈，常駐內(nèi)存的，如果這個(gè)進(jìn)程比如調(diào)用一些外部api服務(wù)，響應(yīng)時(shí)間比較長(zhǎng)，豈不是后面的都卡主了。

crontab 之前發(fā)生過(guò)數(shù)據(jù)問(wèn)題，正在考慮換個(gè)

fpm也一樣卡住，所以調(diào)用外部api需要控制好超時(shí)時(shí)間，比如設(shè)置1秒超時(shí)。

如果當(dāng)前請(qǐng)求未處理完，其他的請(qǐng)求會(huì)等待。
具體的業(yè)務(wù)場(chǎng)景有不同的處理方案。要在接口中等待外部api請(qǐng)求完成，比如微信授權(quán)，則可以把該接口分離成一個(gè)單獨(dú)的服務(wù)來(lái)部署，這樣可避免影響其他業(yè)務(wù) 或 合理設(shè)置超時(shí)時(shí)間；若可異步處理，比如發(fā)券，可使用消息中間件服務(wù)。

我這邊在使用mysql或redis服務(wù)時(shí)，結(jié)合使用場(chǎng)景，一般會(huì)從三個(gè)角度去考慮，流量，性能及多機(jī)活備。
通過(guò)內(nèi)網(wǎng)訪問(wèn)，流量是沒(méi)問(wèn)題的，至于性能及活備，因?yàn)闊o(wú)法預(yù)知上線后的業(yè)務(wù)情況，所以無(wú)法評(píng)估你當(dāng)前配置的redis服務(wù)有沒(méi)有問(wèn)題。

如果沒(méi)有更好的方案，建議提前開(kāi)發(fā)好業(yè)務(wù)功能，按照當(dāng)前思路部署服務(wù)，然后做壓測(cè)來(lái)定位服務(wù)瓶頸。

@靜默 但是fpm不是每個(gè)請(qǐng)求開(kāi)一個(gè)進(jìn)程么，如果一個(gè)進(jìn)程卡出，應(yīng)該不影響其他的把

@CaesarTang 好的，太感謝了

fpm不是每個(gè)請(qǐng)求開(kāi)一個(gè)進(jìn)程，是的話一秒來(lái)1萬(wàn)個(gè)請(qǐng)求，服務(wù)器內(nèi)存直接爆了。
都是預(yù)先開(kāi)一些進(jìn)程，每個(gè)進(jìn)程排隊(duì)處理消息，包括nginx也是一樣。

@靜默 是的，我的意思是說(shuō)每個(gè)fpm進(jìn)程間不互相干擾，不需要等待。

webman在前面加一層nginx也一樣，新請(qǐng)求會(huì)發(fā)給空閑的進(jìn)程，不互相干擾

@靜默 哦

我想問(wèn)下，redis是放到一個(gè)機(jī)器上么？比如負(fù)載均衡了3臺(tái)機(jī)器，redis要單獨(dú)放一個(gè)機(jī)器么？

redis放任一臺(tái)服務(wù)器，只要能訪問(wèn)即可。

好的，謝謝，現(xiàn)在也有了一些思路，不過(guò)我估計(jì)要用你的那個(gè)大膽的方案，客戶所在的云沒(méi)有云redis。。。

redis單機(jī)一般問(wèn)題也不大的。webman啟動(dòng)的時(shí)候加載帶領(lǐng)取的卷id到redis里，領(lǐng)劵的時(shí)候redis取個(gè)出來(lái)，然后丟隊(duì)列，隊(duì)列update 到取mysql那。

肯定是政務(wù)云機(jī)房哪些。。。。。

@MarkGo 被你說(shuō)對(duì)了，特麻煩，開(kāi)個(gè)端口還得發(fā)郵件申請(qǐng)。

我們之前也用過(guò)，價(jià)格特別貴，然后window系統(tǒng)還要另外支付授權(quán)費(fèi)用。申請(qǐng)端口和遠(yuǎn)程進(jìn)去要用跳板機(jī)。

@ MarkGo 對(duì)啊對(duì)啊，超級(jí)麻煩，那個(gè)堡壘機(jī)傳文件夾還不智能，上次開(kāi)個(gè)443端口，說(shuō)要和省里申報(bào)，最少要一天（非工作日）才能過(guò)。

讓加個(gè)白名單，相當(dāng)不愿意。