以下是我们所处的情况。
我们正在向我们的客户分发我们的程序集（纯粹的DLL）（我们无法控制他们的环境）。
他们通过传递项目ID的列表来打电话给我们，我们搜索我们庞大的数据库并返回价格最高的项目。由于我们要满足SLA（30毫秒），我们将内容缓存中的项目缓存（使用Microsoft MemoryCache）我们正在缓存大约一百万个项目。
这里的问题是，它只在我们的客户端应用程序生命周期中缓存。当进程退出时，所有缓存的项都是如此。
有没有办法可以让我的记忆缓存更长寿，以便后续流程可以重复使用缓存的项目？
我考虑过拥有一个窗口服务并允许所有这些不同的进程与同一个盒子上的一个进行通信，但这会在部署时造成巨大的混乱。
我们使用AppFabric作为分布式缓存，但我们实现SLA的唯一方法是使用memorycache。
非常感谢任何帮助。谢谢
答案 0 :(得分：2)
我没有办法确保您的AppDomain存活时间更长 - 因为所有调用程序集都必须卸载AppDomain ...
一个选项可能 - 尽管也很混乱 - 实现某种“持久存储器缓存”...以实现性能，您可以/将使用ConcurrentDictionary MemoryMappedFile中持久保存... < / p>
另一种选择是使用本地数据库 - 甚至可以是Sqlite并实现缓存内存中的接口，使得所有写入/更新/删除都是“直写”，而读取是纯RAM访问...
另一种选择可能是包含一个EXE（例如嵌入式资源），如果它没有运行，则从DLL内部启动... EXE提供MemoryCache，通信可以通过IPC（例如共享内存......）。由于EXE是一个单独的进程，即使在卸载AppDomain之后它也会保持活跃...这个问题更多的是客户端喜欢和/或权限允许它...
我真的很喜欢Windows服务方法，虽然我同意这可能是一个部署混乱......
答案 1 :(得分：1)
基本问题似乎是您无法控制运行时主机 - 这就是控制生命周期（以及缓存）的原因。
我会调查创建某种（轻量？）主机 - 可能是.exe或服务。
你的大部分DLL会挂起新主机，但你仍然可以部署一个“外观”DLL，它反过来称为你的主要解决方案（绑定到你的主机）。是的，您可以让外部客户端直接调用您的新主机，但这意味着更改/重新配置这些外部调用者 - 因为保留原始DLL / API会将外部调用者与内部更改隔离开来。
这将（我假设）意味着完全摧毁和重新构建您的解决方案，特别是外部呼叫者当前所遇到的任何DLL，因为它不会处理请求本身，而是将请求传递给您的新主机。
<强>性能
进程间通信比将其保持在进程中更昂贵 - 我不确定方法的改变会如何影响您的性能和达到SLA的能力。
特别是，引发主机的新实例将导致性能损失。