Treffer: Die erforderlichen Daten können direkt über den Cache abgerufen werden.
Fehlend: Die gewünschten Daten können nicht direkt über den Cache abgerufen werden und die Datenbank muss erneut abgefragt oder andere Vorgänge ausgeführt werden. Der Grund könnte sein, dass es einfach nicht im Cache vorhanden ist oder dass der Cache abgelaufen ist.
Im Allgemeinen gilt: Je höher die Cache-Trefferrate, desto größer sind die Vorteile der Verwendung des Caches, desto besser ist die Leistung der Anwendung (kürzere Antwortzeit, höherer Durchsatz) und desto stärker ist die Fähigkeit, der Parallelität zu widerstehen.
Es ist ersichtlich, dass in einem Internetsystem mit hoher Parallelität die Cache-Trefferrate ein entscheidender Indikator ist.
Führen Sie in Memcached den Statusbefehl aus, um die Statusinformationen des Memcached-Dienstes anzuzeigen, wobei cmd_get die Gesamtzahl der Gets und get_hits die Gesamtzahl darstellt Anzahl der Treffer, Trefferquote = get_hits/cmd_get.
Natürlich können wir den gesamten Memcached-Cluster auch über einige Open-Source-Tools von Drittanbietern überwachen, wodurch die Anzeige intuitiver wird. Typische sind: zabbix, MemAdmin usw.
Wie in der Abbildung gezeigt: MemAdmins Überwachungsstatistik der Trefferquote des zwischengespeicherten Dienstes
In ähnlicher Weise können Sie Informationen ausführen in redis Verwenden Sie den Befehl, um die Statusinformationen des Redis-Dienstes anzuzeigen, wobei keyspace_hits die Gesamtzahl der Treffer, keyspace_misses die Gesamtzahl der Fehlschläge und die Trefferrate = keyspace_hits/(keyspace_hits + keyspace_misses) ist.
Das Open-Source-Tool Redis-star kann Redis-Service-bezogene Informationen in einem Diagramm visualisieren. Gleichzeitig stellt zabbix auch zugehörige Plug-Ins zur Überwachung von Redis-Services bereit.
Im vorherigen Kapitel haben wir die Bedeutung der Cache-Trefferquote erwähnt. Lassen Sie uns mehrere Faktoren analysieren, die die Cache-Trefferquote beeinflussen.
Cache ist für Geschäftsszenarien mit „mehr Lesen und weniger Schreiben“ geeignet. Im Gegenteil, die Verwendung von Cache ist tatsächlich nicht von Bedeutung großartig. Die Trefferquote wird sehr niedrig sein.
Geschäftsanforderungen bestimmen die Aktualitätsanforderungen, die sich direkt auf die Cache-Ablaufzeit und die Aktualisierungsstrategie auswirken. Je geringer die Aktualitätsanforderung ist, desto besser eignet sie sich für das Caching. Bei gleichem Schlüssel und gleicher Anzahl an Anfragen ist die Trefferquote umso höher, je länger die Cache-Zeit ist.
Cache ist für die meisten Geschäftsszenarien von Internetanwendungen geeignet.
Im Allgemeinen gilt: Je kleiner die Cache-Granularität, desto höher die Trefferquote. Ein praktisches Beispiel:
Beim Zwischenspeichern eines einzelnen Objekts (z. B. einer einzelnen Benutzerinformation) müssen wir den Cache nur aktualisieren oder den Cache entfernen, wenn sich die dem Objekt entsprechenden Daten ändern. Beim Zwischenspeichern einer Sammlung (z. B. aller Benutzerdaten) muss der Cache aktualisiert oder entfernt werden, wenn sich die einem Objekt entsprechenden Daten ändern.
Es gibt eine andere Situation: Unter der Annahme, dass auch andere Orte die dem Objekt entsprechenden Daten abrufen müssen (z. B. müssen andere Orte auch individuelle Benutzerinformationen abrufen), ist dies möglich, wenn der Cache ein einzelnes Objekt ist Schlagen Sie direkt auf den Cache zu, andernfalls kann er nicht direkt treffen. Dies ist flexibler und die Cache-Trefferquote ist höher.
Darüber hinaus wirkt sich die Cache-Aktualisierungs-/Ablaufrichtlinie auch direkt auf die Cache-Trefferquote aus. Wenn sich die Daten ändern, hat das direkte Aktualisieren des zwischengespeicherten Werts eine höhere Trefferquote als das Entfernen des Caches (oder das Ablaufenlassen des Caches). Natürlich ist auch die Systemkomplexität höher.
Die Cache-Kapazität ist begrenzt, was leicht zu Cache-Ausfällen und -Beseitigungen führen kann (die meisten Cache-Frameworks oder Middleware verwenden derzeit den LRU-Algorithmus). Gleichzeitig ist auch die Auswahl der Cache-Technologie von entscheidender Bedeutung. Beispielsweise führt die Verwendung eines in die Anwendung integrierten lokalen Caches eher zu einem Engpass auf einer einzelnen Maschine, während die Verwendung eines verteilten Caches leicht zu erweitern ist. Daher ist es notwendig, die Systemkapazität zu planen und zu prüfen, ob sie skalierbar ist. Darüber hinaus unterscheiden sich auch die Effizienz und Stabilität verschiedener Caching-Frameworks oder Middleware.
Wenn ein Cache-Knoten ausfällt, muss eine Cache-Invalidierung vermieden und die Auswirkungen minimiert werden. Auch diese besondere Situation muss vom Architekten berücksichtigt werden. Ein typischer Ansatz in der Branche ist die Verwendung eines konsistenten Hash-Algorithmus oder Knotenredundanz.
Einige Freunde haben möglicherweise dieses Missverständnis: Da die Geschäftsanforderungen hohe Anforderungen an die Aktualität der Daten stellen und die Cache-Zeit die Cache-Trefferquote beeinflusst, sollte das System den Cache nicht verwenden. Tatsächlich wird dabei ein wichtiger Faktor außer Acht gelassen: die Parallelität. Im Allgemeinen ist bei gleicher Cache-Zeit und gleichem Schlüssel der Cache-Umsatz umso höher, je höher die Parallelität ist, selbst wenn die Cache-Zeit kurz ist.
Aus Sicht eines Architekten muss die Anwendung Daten so weit wie möglich direkt über den Cache abrufen und eine Cache-Ungültigmachung vermeiden. Dies stellt auch die Fähigkeiten des Architekten auf die Probe und erfordert umfassende Überlegungen und Kompromisse in verschiedenen Aspekten wie Geschäftsanforderungen, Cache-Granularität, Cache-Strategie und Technologieauswahl. Konzentrieren Sie sich so weit wie möglich auf Hot-Services, auf die häufig zugegriffen wird und die geringe Aktualitätsanforderungen haben, und verbessern Sie die Trefferquote durch Vorladen (Erwärmen) des Caches, Erhöhen der Speicherkapazität, Anpassen der Cache-Granularität und Aktualisieren des Caches.
Bei Anwendungen mit hoher Aktualität (oder begrenztem Cache-Speicherplatz), großer Inhaltsspanne (oder sehr zufälligem Zugriff) und geringem Zugriffsvolumen kann die Cache-Trefferquote über einen längeren Zeitraum sehr niedrig sein. Der Cache ist abgelaufen bevor überhaupt darauf zugegriffen wurde.
Weitere technische Artikel zum Thema Redis finden Sie in der Spalte Redis-Tutorial, um mehr darüber zu erfahren!
Das obige ist der detaillierte Inhalt vonSo verbessern Sie die Trefferquote des Redis-Cache. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!