通过提高负载均衡的SQL查询的应用程序性能上始终在可用性组节点？

Question

我们已经写在ASP.NET中使用MS SQL Server作为后台数据库的基于浏览器的Intranet应用程序。我们的一位客户始终可用性组设置有两个节点。我们的应用程序的请求被路由（通过可用性组侦听）到初级R / W节点和我们的客户端使用R / O节点为他们的定制报告（晶体的报告）。

随着用户数量的不断增长，我们得到的性能问题 - 主要是CPU相关。

我们希望客户增加更多的CPU，而他们希望我们启动路由只读查询到R / O节点。

我们真的很犹豫，因为这些将是应用的变化，真正不平凡的：

1. 据我们了解，报告将被发送到R / O节点的理想情况（减少负载，阻塞，...）。它是一个推荐的做法通过发送只读查询到只读节点（或多个）负载平衡？
2. 在我看来，我们将需要在我们能够负担得起方面非常小心。这需要一些时间的R / O节点同步之前，所以我们要始终明白，我们可以读出旧数据。例如，用户点击“保存”按钮，保存记录后，我们重新读取要显示的记录列表。我认为我们将不得不去R / W节点，以保证新的记录将在那里。那是对的吗？
3. 如果我们将查询发送到R / O节点，我们不降低系统的鲁棒性？如果一个节点出现问题，其它节点必须能够维持自身的负荷。有什么可以推荐的场景时是有意义的请求发送到R / O节点，当它不？

Answer 1

最好是要发送的相关报告（只），以辅助节点，使CPU密集型报表不会降低您的在线数据库的查询性能。您的交易行为没有得到来自非事务性使用状况的影响。

然而，这并不意味着你需要做辅助节点上的所有R / O查询。比方说你有一个事务性操作，其首先需要具有行锁定选择操作，你不应该从主动节点被动节点和DML操作执行读取操作。

我们可以说，所有操作查询可以从主动节点进行查询，而被动节点（S）更适合用于长期刚刚运行报告。

关于第二个问题如果第二个节点配置为异步，则是可能会有一些延迟，还对日志传送失败的情况下，可以看到旧数据。

对于第三个问题，它实际上取决于当前/未来/高峰小时的系统负载。这是很难说这个或那个。这也取决于预算，如果你能买得起它，你可以有更多的1点。这一切都取决于。但是，请记住，RDBMS系统是不是水平扩展十分可行的。