缓存对象集合的最佳方法。一起还是作为单独的物品？
假设我有一个用户集合。每个用户都有一个User_ID、用户名和Tenant_ID。
有时我需要特定 Tenant_ID 的所有用户。
有时我需要基于User_ID的特定用户”。
有时我需要一个基于用户名的用户。
我将始终将 Tenant_ID 用作查找的一部分。
为该数据实现缓存层的理想方法是什么？
由于我正在处理多租户系统，我应该考虑哪些因素？
管理所有可能涉及的缓存键的最佳方法是什么？
选项#1：将所有用户存储在“Tenant_1_Users”的单个键下。
这样做的问题是我将通过网络传输大量不需要的数据。如果我只需要查找特定用户，那么我需要在检索整个集合后使用 LINQ 或其他方法在代码中进行查找。
选项 #2：在不同键下复制相同的 User 对象，例如“TenantID_1_UserID_5”和“TenantID_1_Username_Jason”。
这里的问题是管理用户对象的所有各种键和位置。特别是如果我需要刷新特定用户，因为它已在数据库中更新。我现在需要知道它可以存储的所有可能的位置。还使用更多内存，因为同一用户可以在不同的键下。
相关：AppFabric 缓存“设计”- 缓存单个项目或集合？
问题是 Azure AppFabric 缓存不支持区域、标签或通知。
Say I have a collection of Users. Each user has a User_ID, Username and Tenant_ID.
Sometimes I need all Users for a specific Tenant_ID.
Sometimes I need a specific User based on User_ID".
Sometimes I need a User based on Username.
I will always have the Tenant_ID available to use as part of the lookup.
What is the ideal way to implement a cache layer for this data?
What considerations should I make since I'm dealing with a multi-tenant system?
What is the best way to manage all the possible cache keys involved?
Option #1: Store all Users together under a single key of "Tenant_1_Users"
The problem with this is that I will be transferring a lot of unwanted data over the wire. If I just need to find a specific user then I need to do the lookup in code using LINQ or something after retrieving the whole collections.
Option #2: Duplicate the same User object under different keys such as "TenantID_1_UserID_5" and "TenantID_1_Username_Jason".
The problem here is managing all the various Keys and location of User objects. Especially if I need to flush a specific User because it has been updated in the database. I now need to know all the possible places it could be stored. Also uses more memory since the same User can be under different keys.
Related: AppFabric Cache 'Design' - Caching Individual Items or Collections?
The problem is that Azure AppFabric Caching does not support Regions, Tags or Notifications.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
就其价值而言，我倾向于不想在多个键下缓存同一个对象，因为如果您稍后需要更新或删除该记录，则必须记住更新/删除它可能具有的所有可能的键用过的。
For what its worth, I would tend to not want to cache the same object under multiple keys, because if you need to update or delete that record later, you'll have to remember to update/delete all the possible keys that it could have used.
过去，我将项目单独添加到缓存中，将缓存与记录的主键分开。然后，在需要的地方，我维护了一个字典对象，它可以让我快速查找基于其他值的主键。当我需要这个时，我会创建一个自定义集合类，它包含维护字典的所有逻辑，查找已从缓存中过期的记录，搜索从未添加到缓存中的记录，提供用于检索项目的访问器这种结构使得每个数据项都可以单独过期，而不需要带走集合的其余部分，但我的字典仍然会维护哪些键属于哪些辅助值的列表，这样我就可以恢复过期的无论使用哪个访问器来请求项目，都可以轻松地获取该项目。
不能说这一定是最好的方法，但它似乎可以很好地减少数据存储的访问，而不会因为内存中塞满太多内容而使应用程序服务器陷入困境。当我开发这项技术时，我正在使用标准 ASP.NET 和 SQL 后端，但我看不出有任何原因无法将其转换到云环境。
In the past I have added items to the cache individually, keying the cache off of the primary key of the record. Then, where needed, I maintained a dictionary object that gave me a fast lookup to find the primary key(s) based on some other value. When I needed this I would create a custom collection class that wrapped up all of the logic for maintaining the dictionary, looking up records that had expired from the cache, searching for records that were never added to the cache, providing accessors for retrieving items by their various values, etc. This structure made it so that each data item could expire individually without taking the rest of the collection with it, but my dictionaries would still maintain the list of which keys belonged with which secondary values so I could restore an expired item easily no matter which accessor was used to request it.
Can’t say this is necessarily the best way, but it seemed to work well for reducing trips to the data store without bogging down the app server because it had too much crammed in memory. I was working with standard ASP.NET and a SQL backend when I developed this technique but I can't see any reason why it could not be converted over to a cloud environment.
在这种情况下，我会想做类似的事情：
这具有使用多个提供列表索引的查找字典缓存单个对象的好处。您可以将其封装在一些不错的方法中，例如 GetUserFromName(string username)...等等...以使其更易于在代码中使用。也许所有内容都放在 UserCache 类中，以便您可以实例化缓存并调用其查找方法。
In this case I'd be tempted to do something like:
This has the benefits of a single object being cached with multiple lookup dictionaries that provide the index into the List. You could encapsulate this in some nice methods like GetUserFromName(string username)... etc... to make it easier to use in your code. Maybe all put together in a UserCache class so you can instantiated the cache and call the lookup methods on it.