【问题标题】:APPFabric Caching or SQL server - Specific scenarioAPPFabric 缓存或 SQL 服务器 - 特定场景
【发布时间】:2012-05-09 03:20:19
【问题描述】:

我很难确定是否应该在我们需要的上下文中使用 APPFabric 缓存或 SQL Server(考虑到我们目前在大多数情况下都使用 SQL Server)。

我们只需要(目前)缓存一小块数据(~16KB),每个数据块对应于与从一个应用服务器(传出请求)发送的特定请求相关联的信息。

任何应用服务器都可以接收与初始传出请求相关联的传入请求,并且为了我们的需要,我们需要找回与该传出请求相关联的原始信息......这就是为什么我们不能在内存中保留一个本地缓存在每个应用服务器中,因为我们无法确定传入请求是否会到达发送传出请求的应用服务器。

但是,我们基本上只需要将大约 16kb 的信息只保留一次(更新的可能性非常少),并且能够从任何应用服务器访问它,但绝大多数情况下只访问一次的案例。 所以基本上大部分时间都是从应用服务器(缓存)写入一次,然后从同一个或另一个应用服务器读取一次。

在这个特定的上下文中,通过 AppFabric 缓存集群而不是直接进入数据库是否会有任何好处(考虑到这将是一个简单的插入/选择语句)?

牢记可扩展性,这意味着我们目前没有高吞吐量的 put_data / get_data 操作(~160ops/sec),但我们可能会达到 1K/s .. 10k/s 甚至在不久的将来可能会更高。

提前感谢您的回答。

【问题讨论】:

    标签: sql-server-2008 caching appfabric distributed-caching


    【解决方案1】:

    AppFabric Cache 与 SQL DB 相比的优势在于访问时间。 AppFabric 将有更快的访问时间,因为它将所有内容存储在内存 (RAM) 中,而 SQL 需要从磁盘查询其数据。

    AppFabric 缓存的缺点是您可能会丢失数据,除非您已在集群中实施 HA(高可用性)以避免系统发生故障时丢失数据。 SQL DB 在这里获胜,因为它支持数据可恢复性(通过备份日志 - LDF),以防数据库系统出现故障。

    如果您需要有保证的消息传递,您可能不应该使用 AppFabric Cache 集群,而是使用 SQL DB 来实现临时持久性,因为它具有强大的数据恢复支持。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2011-08-28
      • 1970-01-01
      • 2011-09-27
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多