牛

哇哦，那一個(gè)程序更改，怎么發(fā)布到幾百臺的

老大 這些除了webman 還搭配使用了哪些技術(shù)啊
啊？

大佬你在用友也工作嗎

+1

你們公司 挺認(rèn)可webman呀，這么大規(guī)模使用 很牛

嗯，就剛剛給客戶發(fā)消費(fèi)券，5秒鐘，15000人訪問，6000個(gè)券，負(fù)載3%僅

那是你設(shè)計(jì)的架構(gòu)好，可以分享一下

分享一下，不過架構(gòu)設(shè)計(jì)再好你用fpm 也不行 cpu 內(nèi)存還是高

其實(shí)最多就是6000個(gè)請求

http://m.wtbis.cn/q/8581
他以前問過

是的，去年沒敢，后來今年春節(jié)和秋季轉(zhuǎn)到了webman上，滿意。

"給客戶發(fā)消費(fèi)券，5秒鐘，15000人訪問，6000個(gè)券" 請問這時(shí)候 用了幾臺服務(wù)器 開了多少進(jìn)程啊

哈哈，嗯，一共三臺，nginx的反向代理，當(dāng)然redis起了莫大的作用。

是先存入redis隊(duì)列后延遲消費(fèi)嗎？

你這一臺機(jī)器 感覺都夠用呀，上三臺 是防止 一臺服務(wù)器掛了導(dǎo)致系統(tǒng)不給用吧，系統(tǒng)三臺比較健壯哈

@tanhongbin 原則一臺夠了，不過有兩個(gè)問題，這臺服務(wù)器還在進(jìn)行另外一個(gè)大城市評比活動，流量也很大，以及一些投票啊、問券調(diào)查啥的，東西有點(diǎn)多，因此將這臺服務(wù)器做了轉(zhuǎn)發(fā)，掛了兩個(gè)節(jié)點(diǎn)。

市政項(xiàng)目，不出事是最主要的，多幾個(gè)機(jī)器沒關(guān)系。

@TM 發(fā)券肯定redis

@阿北 沒毛病 市政 項(xiàng)目 不出事第一，還是可用性高好

燃起來了

我很好奇 他們這么大流量 帶寬 是多大的？前后端分離 前端是放在云oss上嘛？

做過類似項(xiàng)目，其中2/3的流量是各種腳本 爬蟲，頭疼的狠

@tanhongbin 三個(gè)10M，靜態(tài)文件放七牛，前后端分離的，vue+webman

@jianqi 對，各種刷單的，哈哈

前端 vue 也放在 七牛 嘛 還是和后端放在一個(gè)服務(wù)器上？

前端vue一臺服務(wù)器、前端靜態(tài)文件放七牛，API放一個(gè)服務(wù)器、數(shù)據(jù)庫放一個(gè)服務(wù)器，后端也在一個(gè)服務(wù)器上。。。。

一個(gè)局域網(wǎng)。

哦哦，是這么應(yīng)用的呀，就是后端服務(wù)器 還是有會掛了導(dǎo)致整個(gè)服務(wù)不可用哈 ，前端vue是不是也可以放在七牛

放在哪里后端掛了才不會導(dǎo)致整個(gè)服務(wù)不可用？

多個(gè)后端 負(fù)載一下，掛了一個(gè) 不影響使用 ，我們都這么干 ，必須得三臺機(jī)器 上不封頂

額，我理解他說的是后端在單獨(dú)的服務(wù)器，不是一臺，如果一臺的話確實(shí)有風(fēng)險(xiǎn)

也可以在一臺部署，開多個(gè)端口用nginx負(fù)載

現(xiàn)實(shí)是一臺服務(wù)如果能支撐的住[哈哈]

@tanhongbin
一共3臺服務(wù)器 + 2臺節(jié)點(diǎn)
服務(wù)器1：vue
服務(wù)器2：api（+兩臺節(jié)點(diǎn)）
服務(wù)器3：后臺
數(shù)據(jù)庫單獨(dú)的服務(wù)器，哦，其實(shí)redis也在服務(wù)器1上

這個(gè)排列并不是因?yàn)檫@個(gè)項(xiàng)目，因此也沒有特別的針對這個(gè)項(xiàng)目做調(diào)整，這個(gè)項(xiàng)目只是多了兩個(gè)節(jié)點(diǎn)其實(shí)。

后臺除了消費(fèi)券，還有其的活動管理，所以獨(dú)立出來了。

@tanhongbin 我理解錯了，你說的后端就是我說的API，是的，nginx反向代理就好了。

我剛說的后端是后臺。

@小w 對這塊沒有深入，我老覺得一臺服務(wù)器再負(fù)載多個(gè)端口，會有效果么？

負(fù)載多個(gè)實(shí)例端口，防止某個(gè)實(shí)例異常導(dǎo)致整個(gè)服務(wù)掛掉

我覺得和一個(gè)實(shí)例開多開幾個(gè)進(jìn)程，是有區(qū)別的

@ 小w 這個(gè)有時(shí)間試試

我們之前用過消息隊(duì)列，不過老串號，就沒敢再用，有時(shí)間研究下再。

串號 ？？？？ 沒明白啥意思

反正很亂，估計(jì)還是用的不對，有時(shí)間要研究下。

是key沖突了？還是啥的

十有八九用是共享DBn同時(shí)key沖突了。

@liziyu 還不知道，當(dāng)時(shí)是發(fā)錯人了，哈哈

很多任務(wù)塞現(xiàn)成隊(duì)列也很方便

啥也不用優(yōu)化就能很小的響應(yīng)，這個(gè)很吊，你響應(yīng)快 處理的請求就多，用戶體驗(yàn)也好

對啊，很強(qiáng)，直接跑就行了，如果并發(fā)高再跟著文檔優(yōu)化一下linux內(nèi)核 無敵，只能說早用早享受，之前一直用TP感覺兩者差太多了

不是一個(gè)級別的框架

0.0 相見恨晚

協(xié)程 處理請求第三放接口 也很爽 ，就等群主 mysql 等其他io協(xié)程化 ，那就太好用了

嗯嗯，在上面看到了去看了一下文檔，后期mysql也攜程化就無敵了

我感覺后面肯定會出 的

目前框架只有作者在維護(hù)嗎？還是有團(tuán)隊(duì)。如果單獨(dú)作者一個(gè)人不會太累嗎？可以開一下倉庫讓社區(qū)的大佬一起維護(hù)一下

基本都是老大一個(gè)人吧，不過他有團(tuán)隊(duì)，放心使用

挺放心的，每個(gè)帖子的問題作者都是很快就定位問題然后解決

我們都是老司機(jī)了，20年剛出就用上了，用了以后我把tp laravel fpm的框架都拋棄了哈哈

我上一年才用，之前都沒發(fā)現(xiàn)，作者也不推廣的哈 0.0

mysql 協(xié)程化 是什么樣的??

就是遇到 mysql 阻塞 正常你能處理10個(gè)并發(fā) ，協(xié)程沒有io阻塞問題，請求可能上到100個(gè)并發(fā)，和請求第三方阻塞是一樣的

哇哦，大神好，你的異常捕獲，我每個(gè)webman項(xiàng)目都在使用

感謝支持！

膜拜大佬！

沒有沒有，叫我小兄弟就好了，我不是大佬??

膜拜校長

666