我們的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中。 –