sql-server - 缓存到 Web 服务器上的本地 SQL 实例

Question

我运行一个使用 .net 构建的高流量(每天 1000 万次展示)/高收入的网站。核心元数据存储在 SQL 服务器上。我和我的团队有一个独特的缓存策略，包括定期从中间层服务器查询数据库中的新元数据，将数据序列化为文件并将其发送到 Web 节点。 Web 应用程序使用这些文件中的数据(有些实际上是序列化对象)来实例化对象并将它们缓存在内存中以用于实时请求。

该模型的优点在于:

允许 Web 节点将所有数据缓存在内存中，并且不会产生任何查询数据库的 IO 开销。

如果数据库意外或由于维护窗口而停机，Web 服务器将继续运行并产生收入。您甚至可以启动 Web 服务器而无需从数据库检索其初始数据，因为它需要的所有数据都在其自己磁盘上的文件中。

允许我们完全横向扩展。如果吞吐量受到影响，我们可以添加一个 Web 服务器。

缺点是这种缓存和持久层增加了查询数据库、打包数据和在 Web 服务器上解包的代码的复杂性。每当我们的领域模型需要我们添加实体时，就必须对更多的这种“管道”进行编码。这种架构已经存在四年了，可能有更好的方法来解决这个问题。

我一直在考虑的一种策略是使用复制将我们的主 sql 服务器数据库复制到安装在每个 Web 服务器上的本地数据库实例。 Web 服务器应用程序将使用普通的 sql/ORM 技术来实例化对象。在这里，我们仍然可以维持主数据库中断，我们不必编写专门的缓存代码，而是可以使用 nHibernate 来处理持久性。

这似乎是一个更优雅的解决方案，并希望了解其他人的想法，或者其他人是否有其他建议。

Answer 1

我觉得你想多了。 SQL Server 已经有可用的机制来处理这些类型的事情。

首先，实现一个 SQL Server 集群来保护您的主数据库。您可以在集群中从一个节点到另一个节点进行故障转移而不会丢失数据，停机时间最多只有几秒钟。

其次，实现数据库镜像以防止集群故障。根据您使用同步还是异步镜像，您的镜像服务器将实时更新或延迟几分钟更新。如果您实时执行此操作，则可以在应用程序内自动故障转移到镜像 - SQL Server 2005 及更高版本支持在连接字符串中嵌入镜像服务器的名称，因此您甚至不必动弹手指。该应用程序只是连接到任何服务器的实时。

在这两件事之间，除了数据中心范围的断电或网络中断之外，您几乎可以免受任何主要数据库故障的影响，并且没有复制内容的复杂性。这涵盖了您的高可用性问题，并让您单独回答扩展问题。

我最喜欢的扩展起点是在您的应用程序中使用三个单独的连接字符串，并根据您的查询需要选择正确的一个:

实时 - 直接指向一台主服务器。所有写入都进入这个连接字符串，只有最关键的读取进入这里。

近实时 - 指向正在通过复制或日志传送更新的只读 SQL Server 的负载平衡池。在您的原始设计中，这些位于 Web 服务器上，但这是危险的做法和维护噩梦。 SQL Server 需要大量内存(更不用说许可费用了)，并且您不希望被束缚在为每台 Web 服务器添加一个数据库服务器上。

延迟报告 - 在您现在的环境中，它将指向同一个负载平衡的订阅者池，但在 future ，您可以使用日志传送等技术将服务器池延迟 8-24 小时。这些扩展非常好，但数据远远落后。它非常适合报告、搜索、长期历史记录和其他非实时需求。

如果您从一开始就设计您的应用程序以使用这 3 个连接字符串，则扩展会容易得多，并且不涉及任何编码复杂性 - 只需选择正确的连接字符串即可。