2012-12-26 70 views
0

我爲一個車隊跟蹤公司工作,這個問題是關於我如何計劃做報告。讓我解釋我們的環境。我們有1個數據庫,1個負載分配過程和3個報表處理服務器(假設這些服務器在各方面都是相同的)。當客戶請求報告時,該報告的所有參數都會存入數據庫。我目前正在開發一個負載分發應用程序,該應用程序將接收來自數據庫的待處理報告,並將它們委派給構建並通過電子郵件發送報告的3個報告處理服務器當服務器完成報告(或出現錯誤)時,它會通知負載分配應用程序。報告可以來自各種規模,從1天的1天GPS數據到數百部車輛的3個月GPS數據。負載均衡加權報告?

我能想到的幾個方法可以做到負載均衡,但我不與他們非常高興。我可以讓每臺服務器最多隻能執行5次報告,但1臺服務器可能會得到5份小型報告,而另一臺服務器可能會得到5份大型報告我可以採用「循環」方法,只是在服務器之間順序地發佈報告,但這仍然無法防止任何服務器過載。

我認爲我現在最好的想法是保持每個報告需要多少GPS數據的計數(一個簡單的任務),並且當我將報告分配給每個服務器時,我爲每個服務器保留一個運行總計服務器。當服務器完成報告(並通知負載平衡器)時,從該服務器的運行總數中減去該報告的GPS數據量。這樣,我可以使用最少量的GPS數據將下一個報告分配給服務器。我也可以設置一個最大值,以便服務器無法工作(導致我們重新構建整個報表流程的問題)。如果在所有服務器達到最大值時有更多報告,則可以將它們排隊並稍後在服務器完成其幾個報告時嘗試它們。

我不相信它是儘可能快地完成報告的最佳方法。這些是迄今爲止我所提出的最好的。

如何優化我的方法以跨多個服務器對不同大小的負載均衡報告進行優化?

回答

0

假設你只有一個,你選擇從數據主要表,然後我將配置一臺服務器先做所有大報告,並留下另外兩個做最小到最大。否則,大報告可能永遠無法完成。

對於較小的報告,你想嘗試,在沒有什麼更好的主意,讓他們嘗試運行「類似」的報告,這意味着那些在主要採用指數圍繞在相似的價值觀。例如,如果服務器剛剛完成了2011年6月的報告,那麼要運行的下一個最佳報告是同一時期,而不是跳到2012年11月。這取決於實際的表格,但我假定您有大量的日期排序包含選擇的大部分的數據。你真正想要做的就是分組報告,這些報告可能會重用緩存索引/等,因爲這應該會提供最佳吞吐量。

我有一個類似的調度問題,那是針對大表有任何疑問去一臺服務器(慢隊列)和其他任何走向另一(快速隊列),有一些例外的特殊情況。