專案大概情況：2000個儀表每2秒中向服務器發送一次資料，服務器計算后再回傳給儀表，也就是說要求2秒鐘之內完成2000次資料的接受-運算-發送。
之前有個專案是4000個表60秒左右來回一次，結果ActiveMq會積壓資料，這次求一個不積壓的解決方案
uj5u.com熱心網友回復：
額，沒有方案。擠壓資料只是表示你消費不夠所以你需要的是加快消費，而不是其他方案
uj5u.com熱心網友回復：
你可以自己寫上百十行代碼，實作一臺 master 服務器與 n 臺 worker 服務器的任務調度通訊，不外乎就是 worker 領一下任務、然后把結果回傳給 worker 之類的 3、4個命令而已。uj5u.com熱心網友回復：
然后把結果回傳給 worker 之類的 --> 然后把結果回傳給 master 之類的如果感覺通用框架太復雜、太繁瑣、太慢，自己用它幾十分之一的代碼就能寫一個更適用于自己的。
uj5u.com熱心網友回復：
也許俺們說的話不那么好聽。但你只需要想一下實際我們都天天見到的實際場景每天地鐵大廳，高鐵大廳都一堆人。------------也就是你說的“積壓”
現在到處下雨，各個水庫爆滿，有些道路淹沒半米---------------也就是你說的“積壓"
那么問題本質是什么？
1.其實是運力調度不夠，地鐵車次不夠，排水不夠，泄洪不夠。所以不是說在上面折騰方案。而是去下面加快調度
2.不要怕“積壓”，建水庫的目的就是調控。地鐵大廳也是中轉調控。道路排水也是調控。我們并不是要求水庫為空不“積壓”，也不要求地鐵大廳根本木人不“積壓”，也不是要求城市排水溝里沒有水不“積壓”，我們要求的是他們不會漫過設計要求。如果漫過了，就的開閘，就得分流，就的泄洪，就得抽水（人類的手段都一樣，控上游，釋下游。一條釋放路徑不夠，就多加幾條釋放路徑）
總歸來說ActiveMq這里東西其實就是水庫，有庫容是對的，調節消峰也是對的，他保護的是下游。如果說你覺著庫容過大，想想人類怎么干？很明顯不是找東西替代水庫，而是限流，分流，泄洪
uj5u.com熱心網友回復：
不知道你慢的是程式，還是資料庫。方案不少。
1 負載均衡，同一套專案，可以部署多個站點。然后讓請求均勻分散到每個webapi。
2 就如sp所說，創建主次同步的資料庫。一臺master，N臺slave，一般來說都是屬于讀寫分離的范疇。
uj5u.com熱心網友回復：
請說出你的細節。uj5u.com熱心網友回復：
如果是一臺服務器，那沒啥方案；如果是多臺服務器，那就 分發，執行，統計，回傳
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/19460.html
標籤：C#