Cache-Tags

Cache-Tags = Datenabhängigkeiten

Cache-Tags beschreiben Abhängigkeiten von Daten, die von Drupal verwaltet werden.

Warum?

Cache-Tags bieten eine deklarative Möglichkeit, nachzuverfolgen, welche Cache-Elemente von bestimmten, von Drupal verwalteten Daten abhängen.

Das ist wichtig für ein Content Management System bzw. Framework wie Drupal, weil derselbe Inhalt auf unterschiedliche Weise wiederverwendet werden kann. Anders gesagt: Es ist unmöglich vorherzusagen, wo ein Inhalt verwendet wird. An jedem Ort, an dem Inhalt verwendet wird, kann er gecacht werden. Das bedeutet, derselbe Inhalt kann an dutzenden Stellen gecacht werden. Das führt zu dem bekannten Zitat: In der Informatik gibt es nur zwei ernsthafte Probleme: Cache-Invalidierung und Namensgebung. — also wie willst du alle Cache-Elemente löschen, die diesen Inhalt verwenden?

Hinweis: Drupal 7 bot drei Methoden der Cache-Invalidierung: ein spezifisches CID ungültig machen, alle CIDs mit einem Präfix ungültig machen oder den gesamten Cache-Container ungültig machen. Keine dieser Methoden erlaubte es, nur die Cache-Elemente zu invalidieren, die eine geänderte Entität enthalten, weil das nicht vorherzusehen war!

Was ist ein Cache-Tag?

Ein Cache-Tag ist ein String.

Cache-Tags werden als Mengen von Strings übergeben (Reihenfolge spielt keine Rolle) und als string[] dargestellt. Das sind Mengen, weil ein Cache-Element von vielen Cache-Tags abhängen kann.

Syntax

Konventionell haben sie die Form ding:identifier – und wenn es keine Mehrfachinstanzen des Dinges gibt, einfach ding. Die einzige Regel ist, dass sie keine Leerzeichen enthalten dürfen.

Es gibt keine strenge Syntax.

Beispiele:

• node:5 – Cache-Tag für den Node mit ID 5 (wird bei jeder Änderung ungültig)
• user:3 – Cache-Tag für User mit ID 3 (wird bei jeder Änderung ungültig)
• node_list – Cache-Tag für die Liste von Node-Objekten (wird ungültig, wenn irgendein Node erstellt, gelöscht oder geändert wird). Gilt für jeden Entitätstyp im Format {entity_type}_list.
• config:system.performance – Cache-Tag für die Konfiguration system.performance
• library_info – Cache-Tag für Asset-Bibliotheken

Allgemeine Cache-Tags

Daten, die von Drupal verwaltet werden, sind in drei Kategorien unterteilt:

• Entitäten – sie haben Cache-Tags in der Form <entity type ID>:<entity ID> sowie <entity type ID>_list und <entity type ID>_list:<bundle> für Listen-Invalidierung. Konfigurationsobjekte verwenden den Cache-Tag des Basiskonfigurationsobjekts.
• Konfiguration – sie haben Cache-Tags in der Form config:<configuration name>
• Benutzerdefiniert „custom“ (z. B. library_info)

Drupal stellt Cache-Tags für Entitäten und Konfiguration automatisch bereit – siehe Basisklasse Entity und Basisklasse ConfigBase. (Alle konkreten Entitätstypen und Konfigurationsobjekte erben davon.)

Obwohl viele Objekttypen ein vorhersagbares Cache-Tag-Format <entity type ID>:<entity ID> nutzen, sollte Drittanbieter-Code sich nicht darauf verlassen. Stattdessen sollte er die Cache-Tags für ein einzelnes Objekt mit der Methode ::getCacheTags() ermitteln, z. B. $node->getCacheTags(), $user->getCacheTags(), $view->getCacheTags() usw.

Manchmal muss auch basierend auf Listen invalidiert werden, die von Daten einer Entität abhängen (z. B. soll gerenderter HTML für eine Liste beim Erstellen eines neuen Objekts in der Liste aktualisiert werden). Das geht mit EntityTypeInterface::getListCacheTags(), womit dann alle von dieser Methode zurückgegebenen Tags zusammen mit den Tags des Objekts invalidiert werden. Ab Drupal 8.9 (Change Notice) haben Entitäten mit Bundles automatisch einen spezifischeren Cache-Tag, der ihr Bundle einschließt, um gezieltere Listeninvalidierungen zu ermöglichen.

Es ist auch möglich, benutzerdefinierte, spezifischere Cache-Tags basierend auf Objektwerten zu definieren, z. B. ein Feld mit Verweisen auf Taxonomiebegriffe für Listen, die Objekte mit einem bestimmten Begriff zeigen. Die Invalidierung solcher Tags kann in benutzerdefinierten Presave-/Delete-Hooks gesetzt werden:

function yourmodule_node_presave(NodeInterface $node) {
  $tags = [];
  if ($node->hasField('field_category')) {
    foreach ($node->get('field_category') as $item) {
      $tags[] = 'mysite:node:category:' . $item->target_id;
    }
  }
  if ($tags) {
    Cache::invalidateTags($tags);
  }
}

Diese Tags können im Code und in Views mit dem bereitgestellten Modul Views Custom Cache Tag verwendet werden.

Hinweis: Es gibt derzeit keine API, um einzelne Bundles und spezifischere Cache-Tags von einem Objekt abzurufen, da nicht das Objekt selbst, sondern die Abfrage bestimmt, welche List-Cache-Tags relevant sind. Künftige Drupal Core-Versionen werden wahrscheinlich die Cache-Tag-Unterstützung pro Bundle verbessern und diese z. B. in Entity Query Builder und Views integrieren.

Wie

Setzen

Jeder Cache-Backend muss das CacheBackendInterface implementieren, also geben Sie beim Setzen eines Cache-Items mit ::set() den dritten und vierten Parameter an, z. B.:

$cache_backend->set(
  $cid, $data, Cache::PERMANENT, ['node:5', 'user:7']
);

Dies speichert das Cache-Element mit der ID $cid permanent (also unbegrenzt lang), macht es aber invalidierbar über die Cache-Tags node:5 oder user:7.

Invalidierung

Cache-Elemente werden mit cache_tags.invalidator:invalidateTags() (oder wenn Sie den Service nicht injizieren können: Cache::invalidateTags()) invalidiert, das ein Set von Cache-Tags (string[]) akzeptiert.

Hinweis: Die Invalidierung betrifft alle Cache-Bins. Es macht keinen Sinn, Cache-Tags nur für einzelne Bins zu invalidieren, weil geänderte Daten, deren Cache-Tags ungültig sind, von Cache-Elementen in anderen Bins abhängen können.

Debugging

Obiges ist hilfreich zum Debuggen von Caches. Außerdem: Wenn etwas mit Cache-Tags ['foo', 'bar'] gecacht wird, hat das Cache-Element eine Spalte mit Tags (angenommen Datenbankcache) mit folgendem Wert:

bar foo

Anders gesagt:

• Cache-Tags sind durch Leerzeichen getrennt
• Cache-Tags sind alphabetisch sortiert

Das erleichtert Analyse und Debugging von Caches!

Header (Debugging)

Zuletzt: Es ist leicht zu sehen, von welchen Cache-Tags eine Antwort abhängt (und damit ungültig wird), indem man nur den Header X-Drupal-Cache-Tags betrachtet!

(Deshalb sind Leerzeichen verboten: weil der Header X-Drupal-Cache-Tags, wie viele HTTP-Header, Leerzeichen als Trennzeichen verwendet.)

Hinweis: Wenn Sie diese Header nicht sehen, müssen Sie Drupal für die Entwicklungsumgebung konfigurieren.

Integration mit Reverse Proxies

Anstatt Antworten in Drupal zu cachen und mit Cache-Tags zu invalidieren, können Sie auch Antworten in Reverse Proxies (Varnish, CDN usw.) cachen und die gecachten Antworten dann mit den Cache-Tags ungültig machen, die mit den Antworten verbunden sind. Damit die Reverse Proxies wissen, welche Cache-Tags mit jeder Antwort verknüpft sind, können Sie die Cache-Tags im Header mitsenden.

Wie Drupal 8 den Header X-Drupal-Cache-Tags für Debugging sendet, kann es auch den Header Surrogate-Keys mit leerzeichen-getrennten Werten senden, wie es manche CDNs erwarten, oder den Header Cache-Tag mit komma-getrennten Werten, wie es andere CDNs erwarten. Und das kann ein Reverse Proxy sein, den Sie selbst betreiben, kein kommerzieller CDN-Service.

Üblicherweise sollte Ihr Webserver und Reverse Proxy Headerwerte bis zu 16 KB unterstützen.

1. HTTP ist textbasiert. Cache-Tags basieren daher auch auf Text. Reverse Proxies können Cache-Tags beliebig in anderen Datenstrukturen darstellen. Die 16 KB Headerlänge wurde gewählt, um a) 99% Kompatibilität sicherzustellen und b) praktisch erreichbar zu sein. Übliche Webserver (Apache) und CDNs (Fastly) unterstützen Headerwerte bis 16 KB, was etwa 1000 Cache-Tags entspricht, genug für 99% der Fälle.
2. Die Anzahl der Cache-Tags variiert je nach Site und Antwort stark. Manche Antworten hängen von sehr vielen Dingen ab und enthalten viele Cache-Tags. Mehr als 1000 Tags in einer Antwort sind selten.
3. Diese Richtlinie (~1000 Tags pro Antwort) wird sich mit der Zeit entwickeln, da a) immer mehr reale Anwendungen sie nutzen und b) Systeme speziell auf dieser Funktionalität aufbauen.

Alles über 1000 Cache-Tags deutet meist auf ein zu komplexes Antwort-Design hin, das aufgeteilt werden sollte. Es spricht nichts dagegen, dieses Limit in Drupal zu überschreiten, aber das kann manuelle Konfiguration erfordern, was für sehr komplexe Use Cases akzeptabel ist. Möglicherweise trifft das auch schon bei weit weniger als 1000 Tags zu.

Lesen Sie die Dokumentation zu Varnish mit Cache-Tags.

Bekannte CDNs mit Tag-basiertem Purge:

CloudFlare
Fastly
KeyCDN
Akamai

Interner Seiten-Cache

Die umfassende Nutzung von Cache-Tags in Drupal 8 ermöglicht es, Drupal 8 mit standardmäßig aktiviertem internem Seiten-Cache auszuliefern. Das ist nichts anderes als ein eingebauter Reverse Proxy.

Siehe auch

• Cacheability von Render-Arrays
• Cache-Kontexte
• Cache max-age