Table of Contents
Request Cache
Übersicht
Ziel ist es, zu vermeiden, dass identische Anfragen mehrmals beantwortet werden, also Rechenzeit verschwendet wird. Hier gilt es zwei Fälle zu unterscheiden: Erstens, Anfragen die nicht an einen Nutzer gebunden gebunden sind und zweitens, Anfragen die präferenz-gestützt sind. Im ersten Fall werden die Rückgaben nicht von Modellparametern beeinflusst und sind wiederverwendbar. Für den zweiten Fall ist es nicht möglich, die Resultate einer Anfrage wiederzuverwenden, da die Parameter sich für zwei Nutzer unterschieden und so eine Anpassung der Resultate notwendig sind. Deshalb dient der Cache nur zur Speicherung “normaler” Anfragen.
Aufgrund von dem Parameter “limit” ist es notwendig, im Cache immer die gesamte Liste der sortierten Rückgaben zu speichern. Da Kategorien beliebig groß sein können, ist es wichtig, Daten effizient im Cache zu speichern. Dies ist auch notwendig, da ein Transfer sonst länger dauert als ein Lookup im Cache.
In beiden Fällen sind alle Werte zu invalidieren, falls ein Kunde seinen Feed aktualisiert hat, da ggf. Produkte nicht mehr existieren, oder neue Produkte zu einer Kategorie hinzugefügt wurden. Alternativ kann eine TTL pro Anfrage gesetzt werden, so das alte Objekte automatisch invalidiert werden.
Interface
Abrufen einer Anfrage
RequestCache.get(Kunden_ID, Produkt_ID_ID)
Testen ob eine Anfrage existiert
RequestCache.contains(Kunden_ID, Produkt_ID)
Hinzufügen einer Anfrage
RequestCache.set(Kunden_ID, Produkt_ID, Ergebnis_Liste, ttl=unlimited)