性能和可伸縮性的體系結構問題

Question

我有一個完全用C＃編寫的高性能系統（當然，我認爲，但還沒有100％），我認爲在設計時我犯了一些大的架構錯誤。原因是它不容易擴展。

雖然它目前工作得很好，但我想確保它可以水平擴展以增加預計在幾個月後可能發生的數量。

該系統有大量的數據併發連接進入系統，最終在處理後進入數據庫。我們目前每分鐘獲得約300條記錄/連接。

系統是這樣構建的。

1. 整個系統託管在一個雙贏2003服務器8 GB RAM/4在亞馬遜vCPU的紅外
，其獲取數據，並把成MSMQ
2. 處理器，用於數據和插入到
3. C＃套接字服務器sql server 2008數據庫表。即使在清除定期數據之後，其中一張主表也有大約3 GB的數據。這具有正確的索引，而且即使是遠程位置，當前的報告也足夠快。然後
4. 該處理的數據發佈到MQ，然後將其用於將產生一定的警示規則處理
5. 還有一些其他的相關方案除了上述

現在主要擔心的是有關的可擴展性（3）中的處理器以及Sql server 2008的可伸縮性。隨着併發連接的大小隨着sql server數據的增加而增加，這會使我的生活更加艱難。

我想出了2種選擇。考慮到目前的系統完全建立在微軟技術基礎之上，其中之一是後端處理器的主要替代品。

對於所有選項，對於主要的最大表格，使用postgresql/pgpool III負載平衡（流複製）解決方案進行存儲。其他表&架構仍將保留在SQL 2008.這給我一個成本效益的數據庫存儲解決方案。

選項1： - 與JBOSS & HornetQ的 替換MSMQ - 將所述數據處理器在步驟3到一個容器管理在JBOSS EJB容器，這將給我用於負載平衡和集羣選項「消息驅動豆」。
- 此選項將需要我我的解決方案的重要組成部分遷移到Unix/Linux操作系統（正在考慮的Fedora）

選項2： - 和ActiveMQ的隊列替換MSMQ（羣集和負載平衡） - 編寫一個Java應用程序將處理隊列消息並照顧數據庫持久性。
該選項將允許我通過activemq集羣實例和java應用程序的新實例來增加Linux服務器的數量。

方案3： - 和ActiveMQ的隊列（羣集和負載平衡）更換MSMQ - 只使用當前數據處理器（有一些小的變化將數據推到PostgreSQL） 此選項將迫使我仍然與Windows

請注意，該系統是一個實時系統。如果系統具有99％的故障證明就足夠了。這不是一個交易系統，所以我可以負擔少量的數據丟失。

不知道我是否已經清楚地解釋了我想要的內容。但我歡迎任何問題，因爲他們肯定會幫助我更好地解釋它。

請提供寶貴的建議，爲長期解決方案做出正確的選擇。我實際上反對選項3，但不想再次將其排除在列表之外。

MUTHU

新增澄清：

道歉沒有說清楚。 1.問題實際上是關於體系結構的可伸縮性。特別是橫向可伸縮性。 2.目前的平均負荷約爲每分鐘300次，這可能不會在一分鐘內完全分散。 3.在接下來的8-12個月內，負載可能會擴大到10倍。

問題是，我們在一個月內銷售了大約50臺設備，現在銷售團隊過快增長。我相信這可能會很快加倍。

Sql服務器有大約8 GB的數據，我們限制每個設備的存儲量，這有助於減小尺寸。目前最大的表格被劃分爲每200個設備1個分區，並且查詢是合理的。但是我可以看到Sql方面的瓶頸和可擴展性。

因此，即使將Sql服務器放在另一臺服務器上，也會限制我在sql server上可以同時執行的更新數量。我看不到具有Sql服務器負載平衡的水平可伸縮性選項（儘管它支持具有羣集的高可用性選項）。我在理解負載均衡中的MS Sql嗎？

Answer 1

根據連接數量，每個連接每秒更新五次並不多。你沒有說你有多少連接，期望有。在Java中，我會在你的情況下做什麼（我想在任何技術中都會如此簡單）就是使用批量數據。

與通訊和數據庫性能問題往往涉及您執行郵件/交易的速度。我將有一個任務/線程將所有消息掛起，並將其轉換爲批處理，一個MQ消息和一個到數據庫的事務。此解決方案的優點在於MQ消息傳遞越慢，批量越大，處理每條連接消息的效率越高。剩下的問題是唯一的，消息/數據庫可以處理數據的帶寬。

Answer 2

性能和可伸縮性是完全不同的東西，你不應該混淆它們。所以我的第一個問題是：「你的問題真的是什麼？」。

有點簡化，但是：提高性能意味着您在更短的時間內執行給定的任務。可擴展性衡量您的系統在添加資源時增加吞吐量的能力。

可伸縮性是關於架構的，所以我有點困惑，爲什麼你把太多的重點放在工具上而不是架構本身上。 MSMQ具有很多擴展性，SQL Server不能很好地擴展（與大多數關係數據庫一樣），但在擴展方案中的表現非常好。

你說你主要關心的是數據處理器。因爲我假設傳入連接是相互獨立的，所以一個標準的解決方案將是物理雙層併爲SQL Server設置不同的機器（無論如何，這是SQL Server喜歡的方式）。然後，SQL Server可以擔心（磁盤）I/O並利用其機器的全部RAM，而網絡處理程序/數據處理器則燒燬CPU週期，這些週期很容易通過不同機器上的多個副本進行擴展負載平衡器）。

＃2不能很好地適合於這種討論，所以我們需要不斷地評論到最低限度，修正的問題和答案，而不是。