实现只读/只写数据库服务器架构

Question

我们有一个 ASP.NET MVC3 Web 应用程序，它包含以下内容：

• 网站 (MVC3)
• 数据访问服务 (WCF + EF)
• 数据库服务器 (SQL Server 2008 R2)

建议我们实现以下架构以获得性能优势：

• Web 服务器集群（网站+数据访问服务）
  • 它具有循环负载平衡
  • 此集群中的每台服务器都有一个缓存（只读）数据库
  • 我们有一组 SP，可以清楚地分为两类 - 读取 SP 和 写入 SP
  • 每个 Read SP 都将连接到 Cache DB，每个 Write SP 将连接到 Write DB
• 具有复制/镜像功能的数据库服务器
  • 这是Write DB。
  • 每当它发生变化时，它会将所有变化传播到所有缓存数据库
  • 除此之外，它还实现了复制/镜像，因此它在出现故障时具有备份。

这是一个非常粗略的想法，我不确定它是否会给我们的系统带来性能提升。

赞成它的论据是 80% 次，操作是只读的。它们可以在 Cache DBs 上创建（因为它们被配置为只读，所以它们更快）。剩下的 20% 可以在 Write DBs 上完成。

但是，我有以下问题：

• 只读配置：我们真的可以将缓存数据库配置为只读吗？因为 Write DB 需要在更改时将更改推送给它们。
• 同步：网络上的所有这些复杂性，确保一切同步有多容易？ 网络延迟：为了保持一切同步，网络开销又如何？
• 复杂性和维护：增加维护开销和增加系统复杂性真的值得吗？

Answer 1

不错的设计，类似于我曾经讨论过如何创建一个每个人都可以添加但无法更新或删除的审计数据库。

如果状态设置为只读，则无法更改数据库，因此无法利用 SQL Server 中的该功能。我认为只读数据库的真正优势在于您可以在执行查询时忽略锁定，并且可以创建专门的索引，因为您知道什么都不会改变。根据http://sqlblog.com/blogs/linchi_shea/archive/2007/10/01/performance-impact-setting-a-database-to-read-only.aspx（对于 SQL 2005），将其设置为只读的收益并不大。

如果您愿意牺牲一些一致性，您可以将查询的隔离级别降低到例如读已提交，以便生成更少的锁。

创建两个数据库的一个优点是它使您能够跨不同的数据库服务器分离数据库。即使 CacheDb 服务器具有 100% 的 CPU 负载和网络负载，您也可以保证写入操作成功。

我假设 Write DB 将允许所有用户写入（甚至可能不允许读取？），而 Cache DB 只会为用户提供读取权限，并且特定的服务帐户具有写入权限。

Write DB 和 Cache DB 之间的内容同步可以使用 SQL Server Integration Services (SSIS) 进行，我认为设计传输逻辑并不难。将两台服务器放在同一个建筑物中，它们之间有千兆网络，这意味着您的传输延迟会很低。