在分布式缓存场景中，通常建议使用还是避免缓存中存储的单体对象？
我正在使用 EAV 架构支持的服务，因此我们将缓存放在适当的位置，以最大限度地减少在从数据库中检索所有主要记录和相应属性集合时 EAV 造成的感知性能缺陷。我们将在服务启动时启动缓存。
我们并没有特别频繁地调用所有产品——客户在首次使用对象映射填充本地缓存后调用差异。为了执行该差异，分布式缓存将需要反射(reflect)数据库中在任意基础上执行的单个记录的更改，并在客户端调用差异时针对更改进行处理。
首先想到的是使用 List 或 Dictionary 将记录存储在分布式缓存中——获取整个集合，在本地内存中对其进行操作或搜索，然后将整个集合放回缓存中。然而，后来的想法导致了用单独的记录填充缓存的想法，每个记录都以一种方式键入，使它们可以单独从缓存中检索/更新到缓存中。这导致想知道在更新所有数据时哪种方法的性能更高。
我们使用的是 Windows Server AppFabric，因此我们可以使用 BulkGet 操作。不过，我不认为有任何批量更新的概念。
关于分布式缓存对象的大小是否存在普遍的想法？如果我们对所有项目有更多请求，我会担心网络带宽，但至少现在，对所有项目的需求应该相当小。
是的，我们将测试和分析每种方法，但我想知道是否有任何超出当前思考范围的内容需要考虑。
最佳答案
因此在我们的场景中，单体缓存对象似乎更受欢迎。在数据中心的大管道中，大约 30 MB 的序列化产品数据通过线路传输几乎感觉不到任何时间。使用 Dictionary<TKey, TValue>我们能够在集合中快速找到产品，以便退回或更新单个项目。
缓存中有数千个单独的实体，所有实体都在 1 MB 以下，批量操作的时间太长了。开销太大，网络操作延迟。
编辑:我们现在正在考虑同时维护实体和实体的整体集合，因为对于整体而言，使用生产数据集检索单个实体似乎成为一个相当昂贵的过程。
关于c# - Best-practice caching : monolithic vs. 细粒度缓存数据，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5751181/