我有一个完全用C＃编写的高性能系统（我认为，但还没有100％），我认为我在设计时犯了一些重大的架构错误。原因是它不易扩展。
虽然它目前工作得很好，但我想确保它可以横向扩展以增加数量，我预计可能会在几个月后发生。
该系统具有大量并入数据的并发连接，系统最终会在处理后进入数据库。我们目前每分钟有大约300条记录/连接。
系统的架构如下。
现在主要担心的是步骤（3）中处理器的可扩展性和Sql server 2008的可扩展性。随着并发连接的大小随着sql server数据的增加而增加，它将使我的生活变得更加艰难。
我想出了两个选择。其中一个是后端处理器的主要替代品，考虑到当前系统完全基于Microsoft技术。
对于所有选项，对于主要最大的表，使用postgresql / pgpool III负载平衡（流复制）解决方案进行存储。其他表＆amp;架构仍将保留在sql 2008中。这为我提供了一种经济高效的数据库存储解决方案。
选项1：
- 用JBOSS＆amp; amp;替换MSMQ HornetQ的
- 将步骤3中的数据处理器放入JBOSS ejb容器中的容器管理“消息驱动bean”中，这将为我提供负载平衡和群集选项。
- 这个选项需要我将我的解决方案的主要部分移到unix / linux（我正在考虑fedora）
选项2： - 将MSMQ替换为ActiveMQ的队列（群集和负载平衡） - 编写一个Java应用程序，它将处理队列消息并处理数据库持久性 这个选项允许我使用activemq集群实例和java应用程序的新实例增加linux服务器的数量。
选项3： - 将MSMQ替换为ActiveMQ的队列（群集和负载平衡） - 仅使用当前的数据处理器（通过一些小的更改将数据推送到postgresql） 此选项将强制我保留Windows
请注意，该系统是一个实时系统。如果系统具有99％的故障证明就足够了。这不是一个交易系统，因此我可以承受少量的数据丢失。
不知道我是否已经清楚地解释了我想要的东西。但我欢迎任何问题，因为它们肯定会帮助我更好地解释它。
请提供宝贵的建议，为长期解决方案做出正确的选择。我自己实际上反对选项3，但是不想再将它排除在列表之外再犯错误。
MUTHU
添加以澄清：
道歉，不清楚。 问题实际上是关于架构的可扩展性。特别是水平可扩展性。 2.目前的平均负载大约是每分钟300个，这可能不会在一分钟内完全分散。 3.在接下来的8-12个月内，负载可能会轻松扩展到10倍。
问题是我们在一个月内销售了大约50台设备，而现在销售团队正在加速增长。我相信这可能会很快翻倍。
Sql server有大约8 GB的数据，我们限制了每台设备的存储量，这有助于减小尺寸。目前，最大的表被划分为每200个设备1个分区，查询是合理的。但我可以看到Sql方面的瓶颈具有可扩展性。
因此，即使将Sql服务器放在另一台服务器上，我在sql server上可以同时进行的更新量也会受到限制。我看不到具有Sql server负载平衡的水平可伸缩性选项（尽管它支持带有群集的高可用性选项）。我是否在负载均衡中误解了MS Sql？
答案 0 :(得分：1)
性能和可伸缩性是完全不同的东西，你不应该混淆它们。所以我的第一个问题是：“你的问题到底是什么？”。
稍微简化但是：提高性能意味着您可以在更短的时间内执行给定的任务。可伸缩性衡量的是系统在添加资源时增加吞吐量的能力。
可伸缩性完全取决于架构，所以我有点困惑为什么你如此强调工具而不是架构本身。 MSMQ在很多方面都具有很强的可扩展性，并且SQL Server不能很好地扩展（如大多数关系数据库），但在扩展方案中表现非常好。
你说你主要担心的是数据处理器。由于我假设传入的连接是相互独立的，因此一个标准的解决方案是使用物理双层并为SQL Server设置不同的机器（这就是SQL Server喜欢它的方式）。然后SQL Server可以担心（磁盘）I / O并利用它的机器的完整RAM，而网络处理程序/数据处理器会消耗CPU周期，这些CPU周期很容易扩展（或通过多个副本在不同的机器上通过负载均衡器）。
Stackoverflow不适合这种讨论，所以我们需要将评论保持在最低限度并修改问题和答案。
答案 1 :(得分：1)
每个连接每秒五次更新并不多，具体取决于连接数。你没有说你有多少联系，希望有。
在Java中，我在你的情况下做的事情（我想在任何技术中都会如此简单）就是使用批量数据。
消息传递和数据库的性能问题通常与您执行的消息/事务的速率有关。我将有一个任务/线程，它将所有消息挂起并将这些消息转换为批处理，一条MQ消息，一条到数据库的事务。这种解决方案的优雅之处在于MQ消息传递越慢，批处理越大，处理每条连接消息的效率越高。剩下的问题是唯一的，消息/数据库可以处理数据的带宽。