我很难确定APPFabric缓存或SQL Server是否应该在我们的需求环境中使用（考虑到我们目前正在使用SQL服务器进行大多数事情）。
我们只需要（现在）缓存小块数据（~16KB），每个数据块对应于与从一个应用服务器（传出请求）发送的特定请求相关联的信息。
任何应用服务器都可以接收与初始传出请求相关联的传入请求，并且根据我们的需要，我们需要找回与此传出请求相关联的原始信息...这就是为什么我们无法将本地存储在内存中缓存在每个应用服务器中，因为我们无法确定传入请求是否会从发送传出请求的应用服务器到达。
然而，我们基本上只需要保留~16kb的信息一次（非常罕见的更新可能性），并且能够从任何应用服务器访问它，但是在绝大多数情况下只能访问它一次的情况。 所以基本上大部分时间它都是来自应用服务器（缓存）和稍后的一次写入，一次从相同或另一个应用服务器读取。
在这个特定的上下文中，是否有通过AppFabric缓存集群而不是直接进入数据库的任何收获（考虑到它将是一个简单的插入/选择语句）？
牢记可扩展性，这意味着我们目前没有高吞吐量的put_data / get_data操作（~160ops / sec），但我们可能达到1K / s ... 10k / s，并且可能在不久的将来更多。< / p>
提前感谢您的回答。
答案 0 :(得分：1)
AppFabric Cache与SQL DB的增益是访问时间。您可以更快地访问AppFabric，因为它将所有内容存储在内存（RAM）中，而SQL需要从磁盘查询其数据。
AppFabric Cache的缺点是，除非您在群集中实施了HA（高可用性），否则可能会丢失数据，以避免在系统出现故障时丢失数据。 SQL DB在这里获胜，因为它支持数据库系统失败时的数据可恢复性（通过备份日志 - LDF ）。
如果您需要有保证的消息传递，您可能不应该使用AppFabric Cache集群，而是使用SQL DB来实现临时持久性，因为它具有强大的数据恢复支持。