我们的Google AppEngine Java应用程序涉及缓存从服务器请求信息的最近用户。在memcache中缓存对象列表的最佳方法
当前工作的解决方案是我们存储在一个列表中，然后将其缓存的用户信息。
当我们需要最近的用户时，我们只需从这个列表中抓取一个。
最近的用户列表不是我们的应用程序的工作是至关重要的，如果它丢弃缓存它只是重建为用户不断从服务器请求。
我想知道的是：我能更好地做到这一点吗？
使用目前的方法，我们可以在列表变大（用于memcache）之前存储一定数量的用户（我们目前将列表限制为1000，并在插入新时删除最老的列表）。此外，该列表将需要非常快速地更新，其中涉及从memcache中检索完整列表以添加单个用户。
具有存储在缓存中的每个用户，我们要求当前用户在30分钟后到期分别是对我们有利的。目前，这是一项手动任务，我们要确保列表中不包括过期用户。
这种情况下最好的方法是什么？如果它将用户单独存储在缓存中，跟踪用户的最佳方法是什么，以便我们可以检索它？
你可以保留在内存缓存列表只是“指针”，您可以使用来构建个人的memcache键访问分别存储在内存缓存用户实体。这使得列表的memcache大小足迹更小并且易于处理。
如果用户实体有父母则指针将不得不（如果需要的话很好，他们urlsafe版本）是他们的钥匙，这是唯一的，这样它们可以和使用内存缓存键。
但是，如果用户实体没有父母（即他们在自己的实体组根实体），那么你可以使用自己的数据存储密钥ID为指针 - 通常比键短。更好的是，如果这些ID是数字ID，您甚至可以将它们存储为数字，而不是字符串。对于这些实体，这些ID是唯一的，但它们可能不足以充当memcache密钥，您可能需要添加前缀/后缀以使各个memcache密钥具有唯一性（对于您的应用程序）。
当你需要一个用户实体数据从列表中你第一次获得“指针”，建立用户实体的memcache键，检索与该密钥的实体。
这当然假设你有理由保留这个列表。如果列表本身不是强制性的，则只需要获得每个实体的（唯一）memcache键的配方。
谢谢。列表中的指针而不是实体（或我的例子中的散列表）是一个好主意，但对我而言，唯一的好处是可以在列表中存储更多内容。我的个人缓存用户将在30分钟后过期，将列表中的指针留给不存在的对象。 – Simon
因此，我最后一段：您是否确实需要列表或列表只是现有缓存解决方案的工件？您是否需要知道在过去30分钟内哪些用户需要从应用程序获取信息（这可能解释了列表），或者您只想使用（长达30分钟）缓存的用户信息，而不是数据存储信息（您可以在没有列表的情况下执行此操作）？ –
如果使用NDB caching，很会照顾内存缓存的为您服务。简单地请求用户使用ndb.Key(Model, id).get()或Model.get_by_id(id)关键，其中id是用户ID。
用户信息非常基本，目前甚至没有实体。该列表是一个简单的hashmaps列表，其中一个hashmap代表一个用户。散列表包含用户的性别，语言，插入时间戳和用户iOS推送通知标识符是否存在。 – Simon
HashMap听起来像是错误的数据类型。 HashMap只对大量的键值对有效。我只是将一个“用户”实体存储在memcache中。 –