【发布时间】：2011-06-05 23:56:02
【问题描述】：
我有一个完全用 C# 编写的高性能系统（我认为，但还没有 100%），我认为我在设计时犯了一些重大的架构错误。原因是它不易扩展。
虽然它目前运行良好，但我想确保它可以横向扩展，以应对我预计几个月后可能会发生的交易量增加。
这个系统有大量的数据并发连接进入系统，这些数据在处理后最终会进入数据库。我们目前每分钟获得大约 300 条记录/连接。
系统的架构是这样的。
- 整个系统托管在 amazon 的 win 2003 服务器 8 GB RAM/4 vCPU infra 上
- 获取数据并放入 MSMQ 的 C# Socket 服务器
- 用于数据和插入到 sql server 2008 数据库表的处理器。即使在清除定期数据后，其中一个主表也有大约 3 GB 的数据。这具有正确的索引，并且目前的报告速度相当快，即使是到远程位置也是如此。
- 然后将处理后的数据发布到 MQ，然后根据规则进行处理，从而生成某些警报
- 除上述之外，还有一些其他相关的程序
现在主要担心的是步骤（3）中处理器的可扩展性和Sql server 2008的可扩展性。随着并发连接的大小随着sql server数据的增加而增加，这将使我的生活变得更加艰难。
我想出了 2 个替代方案。考虑到当前系统完全基于 Microsoft 技术构建的事实，其中之一是后端处理器的主要替代品。
对于所有选项，对于最大的主表，使用 postgresql/pgpool III 负载平衡（流复制）解决方案进行存储。其他表和架构仍将保留在 sql 2008 中。这为我提供了一种经济高效的数据库存储解决方案。
选项 1：
- 用 JBOSS 和 HornetQ 替换 MSMQ
- 将第 3 步中的数据处理器放入 JBOSS ejb 容器中的容器管理的“消息驱动 bean”中，这将为我提供负载平衡和集群的选项。
- 这个选项需要我将我的解决方案的主要部分转移到 unix/linux（我正在考虑 fedora）
选项 2：
- 将 MSMQ 替换为 ActiveMQ 队列（集群和负载平衡）
- 编写一个 Java 应用程序来处理队列消息并处理数据库持久性。
这个选项将允许我使用 activemq 集群实例和新的 java 应用程序实例来增加 linux 服务器的数量。
选项 3： - 将 MSMQ 替换为 ActiveMQ 队列（集群和负载平衡） - 仅使用当前的数据处理器（通过一些小的改动将数据推送到 postgresql） 此选项将迫使我继续使用 Windows
请注意，该系统是实时系统。如果系统有 99% 的故障证明就足够了。这不是一个交易系统，所以我可以承受少量的数据丢失。
不知道我是否已经清楚地解释了我想要什么。但我欢迎任何问题，因为它们肯定会帮助我更好地解释它。
请提出您宝贵的建议，以便为长期解决方案做出正确的选择。我自己实际上反对选项 3，但不想再犯错误，将其排除在列表之外。
穆图
为澄清而添加：
抱歉，不清楚。 1.问题实际上是关于架构的可扩展性。尤其是水平可扩展性。 2. 当前的平均负载约为每分钟 300 次，这可能不会完全在一分钟内传播。 3. 在接下来的 8 到 12 个月内，负载可能会更容易扩展到 10 倍。
问题是我们在一个月内销售了大约 50 台设备，而现在销售团队的发展速度太快了。我相信这可能很快会翻倍。
Sql server 有大约 8 GB 的数据，我们限制了每台设备的存储量，这有助于减小大小。目前最大的表被划分为每 200 个设备 1 个分区，查询是合理的。但我可以看到 Sql 方面的可扩展性瓶颈。
所以即使 Sql server 放在另一台服务器上，我可以在 sql server 上进行的同时更新量也会受到限制。我看不到具有 Sql 服务器负载平衡的水平可扩展性选项（尽管它支持具有集群的高可用性选项）。我是不是对负载均衡中的 MS Sql 有误解？
【问题讨论】：
-
"现在主要担心的是步骤（3）中处理器的可扩展性和 Sql server 2008 的可扩展性。" - 3GB 的数据不多。毫无疑问，SQL Server 2008 的扩展性比你我写的任何东西都要好！
标签： java sql-server performance postgresql architecture