java - 性能和可伸缩性的架构问题

Question

我有一个完全用C语言编写的高性能系统（我想是这样，但还没有达到100%），我认为我在设计时犯了一些大的架构错误。原因是它不容易扩展。
虽然它目前运行得很好，但我想确保它在水平方向上可伸缩，以适应几个月后可能出现的销量增长。
该系统有大量的数据并发连接进入系统，经过处理后最终进入数据库。我们目前每分钟大约有300条记录/连接。
系统的架构是这样的。
整个系统托管在亚马逊的win 2003服务器8gb RAM/4vcpu基础设施上
C#Socket服务器，获取数据并放入MSMQ
用于数据和插入到sql server 2008数据库表的处理器。其中一个主表即使清除了周期性数据，也有大约3gb的数据。这有正确的索引，而且当前的报告速度相当快，甚至到了远程位置。
然后将处理后的数据发送到MQ，然后对MQ进行处理，以生成某些警报的规则
除了上面提到的，还有其他一些相关的程序
现在主要担心的是步骤（3）中处理器的可伸缩性和Sql server 2008的可伸缩性。随着并发连接的大小随着sql server数据的增加而增加，这将使我的生活更加艰难。
我想出了两个选择。其中一个是后端处理器的主要替代品，因为当前的系统完全基于微软技术。
对于所有选项，对于最大的主表，使用postgresql/pgpool III负载平衡（流复制）存储解决方案。其他表和模式仍将保留在sql 2008中。这给了我一个经济有效的数据库存储解决方案。
选项1：
-用JBOSS&HornetQ替换MSMQ
-将步骤3中的数据处理器放到JBOSS ejb容器中的容器管理的“消息驱动bean”中，它将为我提供负载平衡和集群的选项。
-此选项将需要我将解决方案的主要部分转移到unix/linux（我正在考虑fedora）
选择2：
-用ActiveMQ的队列替换MSMQ（集群和负载平衡）
-编写一个Java应用程序来处理队列消息并处理数据库持久性。
此选项将允许我使用activemq集群实例和java应用程序的新实例增加linux服务器的数量。
选择3：
-用ActiveMQ的队列替换MSMQ（集群和负载平衡）
-只使用当前的数据处理器（通过一些小的更改将数据推送到postgresql）
此选项将强制我保留Windows
请注意，该系统是一个实时系统。如果系统是99%防故障的就足够了。这不是一个交易系统，所以我可以承受少量的数据丢失。
不知道我是否已经把我想要的解释清楚了。但我欢迎任何问题，因为它们肯定会帮助我更好地解释。
请您提出宝贵的建议，为长期解决方案作出正确的选择。实际上我自己也反对选项3，但我不想把它从列表中删除而再次犯错。
穆图
增加澄清：
很抱歉没有说清楚。
一。问题实际上是架构的可伸缩性。尤其是横向可伸缩性。
2。目前的平均负荷约为每分钟300次，可能不会在一分钟内完全分散。
三。在接下来的8-12个月内，负荷可能会更容易地扩大到10倍。
问题是我们在一个月内销售了大约50台设备，而现在销售团队的增长太快了。我相信很快就会翻倍。
Sql server有大约8gb的数据，我们限制了每个设备的存储量，这有助于减小大小。目前最大的表被划分为每200个设备一个分区，查询是合理的。但我可以看到Sql方面的一个瓶颈，即可伸缩性。
因此，即使将Sql server放在另一台服务器上，我在Sql server上可以同时执行的更新量也将受到限制。我看不到Sql server负载平衡的水平可伸缩性选项（尽管它支持集群的高可用性选项）。我是否在负载平衡方面误解了MS Sql？

Answer 1

根据连接数的不同，每个连接每秒5次更新的次数并不多。你没说你有多少人脉，只是希望有。
在Java中，我在您的情况下（我想在任何技术中都一样简单）要做的就是使用成批的数据。
消息传递和数据库的性能问题通常与您执行的消息/事务的速率有关。我将拥有一个任务/线程，它接收所有挂起的消息，并将这些消息滚动到一个批处理、一条MQ消息、一个数据库事务中。此解决方案的优雅之处在于，MQ消息传递越慢，批处理越大，处理每个连接消息的效率也越高。剩下的问题是，消息/数据库能否处理数据的带宽。