發(fā)消費券用webman做API適合么？各位大佬幫忙哦。
政府發(fā)的市民消費券
可能剛開始同時要1-2萬人進來搶，不過就幾分鐘就沒了。
現(xiàn)在用的yii2，上次cpu被弄到100%了
現(xiàn)在計劃用我們的webman，之前沒弄過常駐內(nèi)存的，不知道適合不適合？
會不會出現(xiàn)一些問題？
當前是想用一個機器nginx做反向代理，內(nèi)網(wǎng)兩個機器做業(yè)務處理。
就怕出現(xiàn)問題，會被弄死的。
10個回答
我覺得合適，2臺webman相當于10臺yii的性能，甚至更多。
2萬人來搶，假設搶1分鐘，每秒支持333個請求就行。高峰期假設乘以3，大概每秒能承受1000請求估計就行。
做完之后用ab壓測下。
已有項目,并且運行沒問題的,建議先考慮優(yōu)化,確定瓶頸在哪里,比如OPCACHE是否開啟,DB Server配置是否足夠,DB索引是否合理,FPM根據(jù)內(nèi)存大小預先開啟足量進程,還有其他一些業(yè)務邏輯設計等,都做了還是不行再考慮換框架這類操作
不否認換了Webman性能會更好,但是你要權衡更換成本,比如更換過程中的遇到的坑你有沒有辦法填,出了問題你能不能擔得起,畢竟這是市政項目,牽扯的東西很多
-
-
-
nitron 2022-06-01
另外再多提一嘴,你這個業(yè)務算是比較簡單的秒殺邏輯(至少從描述中看起來比較簡單),可以考慮在業(yè)務上做優(yōu)化(如果可以),采用先扣庫存再進行后續(xù)邏輯處理的方式(比如隊列),比較典型的例子就是常見的"優(yōu)惠券將會在稍后發(fā)放到您的賬戶中"這種, 前面上個負載均衡,平時就一臺機器,發(fā)券前提前多開幾臺,結束后降回一臺
-
abei 2022-06-01
是的，現(xiàn)在用的就是，除了會員的生成用mysql有點大，其他都放到了redis里，然后服務器有個計劃任務負責發(fā)券，當前自己用到時沒啥問題。
客戶想包裝成產(chǎn)品，做云端，買個其他各城市的部門來發(fā)券，相當于重新搞一個新系統(tǒng)再。
負載均衡還沒有上，這幾天正在研究nginx搞這個，現(xiàn)在有3臺服務器，打算用最弱的一臺做分發(fā)，其他兩臺方程序。
-
-
abei 2022-06-01
上次在客戶公眾號上搞，因為要授權，必須跳轉一次PHP做會員初始化，結果一次來太多人，當時開了1000個靜態(tài)的fpm進程，卡在那里不動了。
最后過了十分鐘還那樣，重啟了phpfpm后好了，我覺得是cpu（8核）已經(jīng)到頭了沒能力處理進程了。
-
nitron 2022-06-02
授權這個,因為從公眾號獲取用戶信息需要服務器向微信服務器發(fā)起一個Http請求,這個涉及第三方系統(tǒng),沒辦法.
注意不要重復獲取access_token就好 -
-
tanhongbin 2022-06-02大佬發(fā)言給力呀，先優(yōu)化，實在扛不住了再換webman，也別一下子全搬過來，高并發(fā)的請求可以用webman處理，多異步，這么高并發(fā)的請求應該不會有新增完數(shù)據(jù)就要看的，mysql的增加刪除和修改全給它異步了，查詢緩存一做基本io上redis扛得住，就問題不大
-
這種情況用swoole可能會更好一點。
-
-
-
-
six 2022-06-02
他本來就是沒有常駐內(nèi)存的經(jīng)驗，直接上swoole玩php協(xié)程非常不推薦，學習swoole的難度不亞于學習一門新語言例如go。
如果系統(tǒng)瓶頸在數(shù)據(jù)庫，那上啥也沒用。如果瓶頸在框架性能低下，上webman是很好的選擇，學習基本沒有成本，同樣的代碼寫法性能提高數(shù)倍，穩(wěn)定性也好與swoole，并且性能也比swoole高。 -
-
liziyu 2022-06-02
如果說沒有扎實的網(wǎng)絡與操作系統(tǒng)相關的基礎或經(jīng)驗，別說用swoole了，就是用了go也難解決性能瓶頸！～
深（身）有體會??！ ^_^ -
-
2548a 2022-06-02說的不錯,記得我以前剛開始工作的時候,有個項目每天零點要執(zhí)行任務,當時項目有8,9萬個會員以后,執(zhí)行任務需要2,3個小時才執(zhí)行完,但是現(xiàn)在如果讓我再執(zhí)行同樣的任務,也就是十幾分鐘的事情.
-
-
2548a 2022-06-02
減少數(shù)據(jù)庫查詢,批量插入或者更新數(shù)據(jù)庫,這些是從代碼層面去優(yōu)化sql. 一個接口能少查詢一次sql,那高并發(fā)下一秒就是少上千次查詢.
-
-
端午節(jié)上線的項目，項目中使用到數(shù)據(jù)庫訪問，單純的增刪改查（有索引），使用docker部署，cpu占用在 10-20% 間，webman的性能讓我著實震驚。8小時將近 1200w 的流量穩(wěn)定支撐，并且cpu占用并不高。主要服務架構如下：
- 一臺服務器使用nginx做負載（8C16g）
- 兩臺服務做業(yè)務，每臺服務器兩個節(jié)點（均為 4c8g）
- 云數(shù)據(jù)庫（4C8G）
順帶一提，該項目也使用了thinkphp開發(fā)的一個服務，簡單的一個查詢數(shù)據(jù)庫（有索引），使用docker部署，cpu占用卻有 300-400%。
當然，這只是我這邊的實際使用場景，僅供參考。你的項目需要具體業(yè)務具體分析。至于業(yè)務層涉及到的服務器調(diào)優(yōu)，數(shù)據(jù)庫優(yōu)化，redis緩存等等，這里就不過多討論了。
-
-
-
-
-
-
-
Caesar-Tang 2022-06-14
對于mysql和redis，如果有預算并且是要短期保證業(yè)務穩(wěn)定，個人建議使用云服務。比如阿里云的云rds或云redis，都有集群版的，比自己部署的要好要穩(wěn)定要便捷。自己部署的話，非專業(yè)運維，包括調(diào)優(yōu)，監(jiān)控等等都會比較麻煩，并且單機部署，流量，性能和IO，都會有瓶頸。
-
-
-
-
-
Caesar-Tang 2022-06-14
以下思路，僅供參考：
- 流量分流（前端資源加cdn或放在對象存儲上；后端的用作負載的服務器，性能要好，帶寬要高，保證接口請求的流量穩(wěn)定）
- 后端服務負載均衡（后端服務多臺服務器部署，負載處理業(yè)務，后續(xù)有壓力可擴容）
- 云mysql 或 云redis 做庫存處理（mysql的原子操作 或 redis的lua腳本執(zhí)行 保證不會超發(fā)）
- 消息中間件做發(fā)券處理（redis消息隊列或rabbitmq等，減庫存后，將發(fā)券任務交給中間件，多個消費者服務同時發(fā)券處理）
-
-
abei 2022-06-14
現(xiàn)在是在一個內(nèi)存最大的服務器上安置了redis，所在的云上沒有云redis，這時候其他機器通過局域網(wǎng)訪問這臺機器的redis你覺得會不會有問題那？
還有問個問題哈，常駐內(nèi)存的，如果這個進程比如調(diào)用一些外部api服務，響應時間比較長，豈不是后面的都卡主了。
-
-
-
Caesar-Tang 2022-06-14
如果當前請求未處理完，其他的請求會等待。
具體的業(yè)務場景有不同的處理方案。要在接口中等待外部api請求完成，比如微信授權，則可以把該接口分離成一個單獨的服務來部署，這樣可避免影響其他業(yè)務 或 合理設置超時時間；若可異步處理，比如發(fā)券，可使用消息中間件服務。 -
Caesar-Tang 2022-06-14
我這邊在使用mysql或redis服務時，結合使用場景，一般會從三個角度去考慮，流量，性能及多機活備。
通過內(nèi)網(wǎng)訪問，流量是沒問題的，至于性能及活備，因為無法預知上線后的業(yè)務情況，所以無法評估你當前配置的redis服務有沒有問題。 -
-
-
-
-
-
-
給個建議，可以自己試試內(nèi)網(wǎng)壓測。
1、消費卷數(shù)量存到redis。
2、領取消費卷的時候查redis結果，有卷領取成功的話通過隊列回寫mysql結果?！井惒健?br />
3、前端搶劵的時候增加個setTimeout，隨機延遲10～1000毫米時間發(fā)送請求，避免產(chǎn)生毛刺。
其實避免了mysql的同步操作，剩下的就是帶寬問題了，所有接口非必要信息不要返回，減少請求大小，開啟gzip就好了。
靜態(tài)資源建議上cdn，針對請求異常時前端做好友好提示，類似活動異常爆滿，請稍后重試。這樣就算webman倒了也對客戶影響不大。
- 暫無評論
當前是想用一個機器nginx做反向代理，內(nèi)網(wǎng)兩個機器做業(yè)務處理。
更加建議租用云負載，按量付費。
以騰訊云為例：
建議：
clb-〉（CVM 3） -〉云redis -〉 云數(shù)據(jù)庫
膽大的：
clb->CVM 2 -> CVM(redis單機) -> 云數(shù)據(jù)庫
-
-
MarkGo 2022-06-20
redis單機一般問題也不大的。webman啟動的時候加載帶領取的卷id到redis里，領劵的時候redis取個出來，然后丟隊列，隊列update 到取mysql那。
-
-
-
-
