c# - ASP.NET 应用程序中搜索结果的缓存体系结构

Question

在 ASP.NET 系统中缓存昂贵搜索结果的好的设计是什么？

任何想法都将受到欢迎......特别是那些不需要我们自己发明复杂基础设施的想法。

以下是与问题相关的一些一般要求:

• 每个搜索结果可以产生从零到几百条结果记录
• 执行每个搜索都相对昂贵且耗时(在数据库中 5-15 秒)
• 结果在客户端显示之前必须分页以避免用户信息过载
• 用户希望能够在返回的结果中进行排序、过滤和搜索
• 用户希望能够在搜索结果中快速切换页面
• 用户希望能够在任意数量的页面上选择多个项目(通过复选框)
• 用户希望在搜索完成后获得相对快速的性能

我看到了一些关于在哪里以及如何实现缓存的可能选项:

<强>1。在服务器上缓存(在 session 或应用程序缓存中)，使用回发或 Ajax 面板来促进高效的分页、排序、过滤和搜索。

• 优点:易于实现，来自 ASP.NET 基础设施的良好支持
• 缺点:非常健谈，服务器内存密集，数据缓存的时间可能比必要的长；禁止负载平衡做法

<强>2。在服务器缓存(如上)但使用可序列化结构，这些结构在一段时间后移出内存以减少服务器上的内存压力

• 优点:有效使用服务器内存；使用负载平衡进行横向扩展的能力；
• 缺点:.NET 基础设施的支持有限；当数据结构发生变化时可能很脆弱；给数据库增加额外的负载；复杂得多

<强>3。在客户端缓存(使用 JSON 或 XML 序列化)，使用客户端 Javascript 对结果进行分页、排序、过滤和选择。

• 优点:用户体验可以接近“富客户端”级别；大多数浏览器可以原生处理 JSON/XML - 存在用于操作的体面库(例如 jQuery)
• 缺点:初始请求可能需要很长时间才能下载；客户端机器上的大量内存占用；将需要在某种程度上手工制作 Javascript 来实现

<强>4。使用数据的压缩/编码表示在客户端缓存 - 在切换页面、排序、过滤和搜索时回调到服务器进行解码。

• 优点:最小化对服务器的内存影响；只要客户需要它，就允许状态存在；通过 JSON/XML 略微改进了客户端的内存使用
• 缺点:在客户端/服务器之间来回移动的大数据集；与使用 JSON/XML 的纯客户端缓存相比，性能较慢(由于网络 I/O)；实现起来要复杂得多 - .NET/浏览器的支持有限

<强>5。我没有考虑过的一些替代缓存方案......

Answer 1

对于 #1，您是否考虑过使用状态服务器(甚至是 SQL 服务器)或共享缓存机制？有plenty的 good ones至 choose来自，和 Velocity正在变得非常成熟 - 可能很快就会 RTM。基于用户是否创建新搜索、点击搜索分页以外的任何其他页面以及最终标准超时(20 分钟)的缓存失效方案应该能够非常成功地将缓存减少到最小大小。

References:

• SharedCache (FOSS)
• NCache ($995/CPU)
• StateServer (~$1200/server)
• StateMirror ("Enterprise pricing")
• Velocity (Free?)