Die Anwendungsprogrammierschnittstelle (API, Application Programming Interface) für dynamischen Cache steht Java-EE-Anwendungen zur Verfügung, die in WebSphere Application Server implementiert sind. Der dynamische Cache-Provider kann genutzt werden, um Geschäftsdaten und generierte HTML zwischenzuspeichern oder um die zwischengespeicherten Daten in der Zelle über den Datenreplikationsservice (DRS) zu synchronisieren.
Früher war der einzige Serviceprovider für die Anwendungsprogrammierschnittstelle "Dynamic Cache" die in WebSphere Application Server integrierte Standardsteuerkomponente für dynamische Cache. Kunden können die Serviceproviderschnittstelle für dynamischen Cache in WebSphere Application Server verwenden, um eXtreme Scale in den dynamischen Cache zu integrieren. Indem Sie die Funktionalität konfigurieren, ermöglichen Sie Anwendungen, die mit der API für dynamischen Cache geschrieben wurden, und Anwendungen, die Caching auf Containerebene verwenden (z. B. Servlets), die Nutzung der Features und Leistungsfunktionen von WebSphere eXtreme Scale.
Sie können den dynamischen Cache-Provider, wie im Abschnitt Dynamischen Cache-Provider für WebSphere eXtreme Scale konfigurieren beschrieben, installieren und konfigurieren.
Die verfügbaren Features in WebSphere eXtreme Scale erweitern die verteilten Funktionen der API "Dynamic Cache" weit über das hinaus, was die Standardsteuerkomponente für dynamischen Cache und der Datenreplikationsservice bieten. Mit eXtreme Scale können Sie Caches erstellen, die wirklich auf mehrere Server verteilt, anstatt nur repliziert und unter den Servern synchronisiert werden. Außerdem sind die Caches von eXtreme Scale transaktionsorientiert und hoch verfügbar, wodurch sichergestellt wird, dass jeder Server denselben Inhalt für den dynamischen Cacheservice sieht. WebSphere eXtreme Scale bietet eine höhere Servicequalität für die Cachereplikation als der Datenreplikationsservice.
Diese Vorteile bedeuten jedoch nicht, dass der dynamische Cache-Provider von eXtreme Scale die richtige Wahl für jede Anwendung ist. Verwenden Sie die folgenden Entscheidungsbäume und Featurevergleichsmatrizes, um festzustellen, welche Technologie sich am besten für Ihre Anwendung eignet.
Cachefeatures | Standardprovider | eXtreme-Scale-Provider | eXtreme-Scale-API |
---|---|---|---|
Lokales Speicher-Caching |
x |
x |
x |
Verteiltes Caching |
Integriert |
Integriert, integriert-partitioniert und fern-partitioniert |
Mehrere |
Linear skalierbar |
x |
x |
|
Zuverlässige Replikation (synchron) |
ORB |
ORB |
|
Plattenüberlauf |
x |
||
Bereinigung |
Basierend auf LRU-/TTL-/Heapspeicher |
LRU/TTL (pro Partition) |
Mehrere |
Ungültigmachen |
x |
x |
x |
Beziehungen |
Abhängigkeits-IDs, Schablonen |
Abhängigkeits-IDs, Schablonen |
x |
Suchoperationen ohne Schlüssel |
Abfrage und Index |
||
Back-End-Integration |
Loader |
||
Transaktionsorientiert |
Implizit |
x |
|
Schlüsselbasierter Speicher |
x |
x |
x |
Ereignisse und Listener |
x |
x |
x |
Integration von WebSphere Application Server |
Nur einzelne Zelle |
Mehrere Zellen |
Zellenunabhängig |
Unterstützung von Java Standard Edition |
x |
x |
|
Überwachung und Statistiken |
x |
x |
x |
Sicherheit |
x |
x |
x |
Cachefeatures | Standardprovider | eXtreme-Scale-Provider | eXtreme-Scale-API |
Caching von Servlet-/JSP-Ergebnissen in WebSphere Application Server |
Version 5.1+ |
Version 6.1.0.25+ |
|
Caching von Web-Service-Ergebnissen (JAX-RPC) in WebSphere Application Server |
Version 5.1+ |
Version 6.1.0.25+ |
|
Caching von HTTP-Sitzungen |
x |
||
Cache-Provider für OpenJPA und Hibernate |
x |
||
Datenbanksynchronisation mit OpenJPA und Hibernate |
x |
Cachefeatures | Standardprovider | eXtreme-Scale-Provider | eXtreme-Scale-API |
---|---|---|---|
Befehlsbasierte API |
Befehls-Framework-API |
Befehls-Framework-API |
DataGrid-API |
Map-basierte API |
DistributedMap-API |
DistributedMap-API |
ObjectMap-API |
EntityManager-API |
x |
Eine ausführlichere Beschreibung zur Funktionsweise der verteilten Caches in eXtreme Scale finden Sie in Topologie planen.
Ein dynamischer Cacheservice, der mit dem eXtreme-Scale-Provider erstellt wurde, kann in jeder der drei verfügbaren Topologien implementiert werden und ermöglicht Ihnen, den Cache speziell an Ihren Leistungs-, Ressourcen-und Verwaltungsbedarf anzupassen. Diese Topologien sind die integrierte, die integriert, partitionierte Topologie und die ferne Topologie.
Integrierte Topologie
Die integrierte Topologie ist dem dynamischen Standardcache- und DRS-Provider sehr ähnlich. Verteilte Cacheinstanzen, die mit der integrierten Topologie erstellt werden, enthalten eine vollständige Kopie des Caches in jedem Prozess von eXtreme Scale, der auf den dynamischen Cacheservice zugreift und ermöglichen damit die lokale Durchführung aller Leseoperationen. Alle Schreiboperationen erfolgen über einen Einzelserverprozess, in dem die Transaktionssperren verwaltet werden, bevor sie auf den restlichen Servern repliziert werden. Deshalb eignet sich diese Topologie besser für Workloads, bei denen Anzahl der Leseoperationen im Cache im Vergleich mit den Schreiboperationen im Cache wesentlich höher ist.
Mit der integrierten Topologie werden neue oder aktualisierte Cacheeinträge nicht sofort in jedem einzelnen Serverprozess sichtbar. Ein Cacheeintrag wird erst dann sichtbar (selbst für den Server, der ihn generiert hat), wenn er über die asynchronen Replikationsservices von WebSphere eXtreme Scale weitergegeben wird. Diese Services arbeiten so schnell, wie es die Hardware zulässt, aber es kommt trotzdem zu einer kleinen Verzögerung. Die integrierte Topologie wird in der folgenden Abbildung veranschaulicht:
Integrierte, partitionierte Topologie
Für Workloads, bei denen die Anzahl der Schreiboperationen größer-gleich der Anzahl der Leseoperationen ist, wird die integrierte, partitionierte Topologie oder die ferne Topologie empfohlen. Bei der integrierten, partitionierten Topologie sind alle Cachedaten in den Prozessen von WebSphere Application Server enthalten, die auf den Cache zugreifen. In jedem einzelnen Prozess wird jedoch nur ein Teil der Cachedaten gespeichert. Alle Lese- und Schreiboperationen für die Daten in dieser "Partition" erfolgen über den Prozess, d. h., dass die meisten Anforderungen an den Cache über einen Prozedurfernaufruf verarbeitet werden. Dies führt zu einer höheren Latenzzeit für Leseoperationen als bei der integrierten Topologie, aber die Kapazität des verteilten Caches für die Verarbeitung von Lese- und Schreiboperationen steigt linear zur Anzahl der Prozesse von WebSphere Application Server, die auf den Cache zugreifen. Außerdem wird die maximale Größe des Caches bei dieser Topologie nicht durch die Größe eines einzelnen WebSphere-Prozesses beschränkt. Da jeder Prozess nur einen Teil des Caches enthält, entspricht die maximale Cachegröße der summierten Größe alle Prozesse abzüglich der Kosten für den Prozess. Die integrierte, partitionierte Topologie wird in der folgenden Abbildung veranschaulicht:
Angenommen, Sie haben ein Grid von Serverprozessen mit jeweils 256 MB freiem Heapspeicher für einen dynamischen Cacheservice. Der dynamische Standardcacheprovider und der Provider von eXtreme Scale, der die integrierte Topologie verwendet, sind beide auf eine Speichercachegröße von 256 MB abzüglich Prozesskosten beschränkt. Lesen Sie hierzu den Abschnitt "Kapazitätsplanung und hohe Verfügbarkeit" weiter hinten in diesem Dokument. Der eXtreme-Scale-Provider, der die integrierte, partitionierte Topologie verwendet, ist auf eine Cachegröße von 1 GB abzüglich Prozesskosten beschränkt. Der Provider von WebSphere eXtreme Scale unterstützt somit speicherinterne dynamische Cacheservices, die die Größe eines einzelnen Serverprozesses überschreiten. Der dynamische Standardcacheprovider stützt sich auf die Verwendung eines Plattencaches, damit Cacheinstanzen über die Größe eines Einzelprozesses hinweg anwachsen können. In vielen Situationen können Sie sich durch den Provider von WebSphere eXtreme Scale den Plattencache und die kostenintensiven Plattenspeichersysteme, die für eine angemessene Leistung des Plattencaches erforderlich sind, sparen.
Ferne Topologie
Die ferne Topologie kann ebenfalls verwendet werden, um den Bedarf an einem Plattencache zu umgehen. Der einzige Unterschied zwischen der fernen Topologie und der integrierten, partitionierten Topologie besteht darin, dass bei einer fernen Topologie alle Cachedaten außerhalb der Prozesse von WebSphere Application Server gespeichert werden. WebSphere eXtreme Scale unterstützt eigenständige Containerprozesse für Cachedaten. Diese Containerprozesse haben geringere Kosten als ein Prozess von WebSphere Application Server und sind auch nicht auf die Verwendung einer bestimmten Java Virtual Machine (JVM) beschränkt. Die Daten für einen dynamischen Cacheservice, auf den mit einem 32-Bit-Prozess von WebSphere Application Server zugegriffen wird, könnte sich beispielsweise in einem eXtreme-Scale-Containerprozess befinden, der in einer 64-Bit-JVM ausgeführt wird. Dies ermöglicht Benutzern, die höhere Speicherkapazität von 64-Bit-Prozessen für das Caching zu nutzen, ohne das zusätzliche Kosten für den 64-Bit-Betrieb bei den Anwendungsserverprozessen anfallen. Die ferne Topologie wird in der folgenden Abbildung veranschaulicht:
Datenkomprimierung
Ein weiteres Leistungsfeature, das der dynamische Cache-Provider von WebSphere eXtreme Scale Benutzern für die Verwaltung der Cachekosten bietet, ist Komprimierung. Der dynamische Standardcacheprovider unterstützt keine Komprimierung zwischengespeicherter Daten im Speicher. Mit dem Provider von eXtreme Scale ist dies möglich. Die Cachekomprimierung mit dem Komprimierungsalgorithmus (deflate) kann in jeder der drei verteilten Topologien aktiviert werden. Die Aktivierung der Komprimierung erhöht die Kosten für Lese- und Schreiboperationen, steigert aber drastisch die Cachedichte für Anwendungen wie das Caching von Servlets und JSP-Dateien.
Lokaler Speichercache
Der dynamische Cache-Provider von WebSphere eXtreme Scale kann auch zur Unterstützung dynamischer Cacheinstanzen verwendet werden, in denen die Replikation inaktiviert ist. Wie beim dynamischen Standardcacheprovider können in diesen Caches nicht serialisierbare Daten gespeichert werden. Außerdem bieten Sie in großen Mehrprozessorunternehmensservern häufig eine bessere Leistung als der dynamische Standardcacheprovider, weil der Codepfad von eXtreme Scale auf einem möglichst hohe Anzahl gemeinsamer Zugriff auf den Speichercache ausgelegt ist.
Bei lokalen Speichercaches, in denen die Replikation inaktiviert ist, sind keine wesentlichen funktionalen Unterschiede zwischen Caches, die vom dynamischen Standardcacheprovider unterstützt werden, und WebSphere eXtreme Scale bemerkbar. Dem Benutzer sollten eigentlich keine funktionalen Unterschiede zwischen den beiden Caches auffallen, abgesehen davon, dass von WebSphere eXtreme Scale unterstützte Caches keine Auslagerung auf die Platte oder Statistiken und Operationen unterstützen, die sich auf die Größe des Caches im Speicher beziehen.
Bei Caches, in denen die Replikation aktiviert ist, unterscheiden sich die von den meisten Aufrufen der API "Dynamic Cache" zurückgegebenen Ergebnisse kaum, unabhängig davon, ob der Kunde den dynamischen Standardcacheprovider oder den dynamischen Cache-Provider von eXtreme Scale verwendet. Für einige Operationen kann das Verhalten der dynamischen Cachesteuerkomponente nicht mit eXtreme Scale emuliert werden.
Statistiken zum dynamischen Cache werden über die Anwendung "CacheMonitor" oder die MBean der API "dynamic cache" berichtet. Wenn Sie den dynamischen Cache-Provider von eXtreme Scale verwenden, werden Statistiken weiterhin über diese Schnittstellen berichtet, aber der Kontext der Statistikwerte ist anders.
Wenn eine dynamische Cacheinstanz von drei Servern (A, B und C) gemeinsam genutzt wird, gibt das Statistikobjekt des dynamischen Caches nur Statistiken für die Kopie des Caches auf dem Server zurück, auf dem der Aufruf abgesetzt wurde. Wenn die Statistiken auf Server A abgerufen werden, spiegeln sie nur die Aktivitäten auf Server A wider.
Mit eXtreme Scale gibt es nur einen einzigen verteilten Cache, der von allen Servern gemeinsam genutzt wird, so dass es nicht möglich ist, die meisten Statistiken auf Serverbasis zu verfolgen, wie es der dynamische Standardcacheprovider tut. Im Folgenden finden Sie eine Liste der Statistiken, die von der API für Cachestatistiken berichtet werden, einschließlich einer Beschreibung ihrer Funktionalität, wenn Sie den dynamischen Cache-Provider von WebSphere eXtreme Scale verwenden. Wie der Standardprovider werden diese Statistiken nicht synchronisiert und können deshalb bei gleichzeitigen Workloads bis zu 10 % variieren.
Der dynamische Cache-Provider ermöglicht Ihnen, Cachestatistiken zurückzusetzen. Mit dem Standardprovider löscht die Rücksetzoperation nur die Statistiken des betroffenen Servers. Der dynamische Cache-Provider von eXtreme Scale verfolgt die meisten seiner Statistikdaten in fernen Cachecontainern. Diese Daten werden weder gelöscht noch geändert, wenn die Statistiken zurückgesetzt werden. Stattdessen wird das Verhalten des dynamischen Standardcaches im Client simuliert, indem die Differenz zwischen dem aktuellen Wert einer bestimmten Statistik und dem Wert dieser Statistik beim letzten Aufruf der Rücksetzoperation auf diesem Server berichtet wird.
Wenn der Datenverkehr auf Server A beispielsweise 10 entfernte Cacheeinträge generiert, werden in den Statistiken für Server A und Server B 10 entfernte Einträge berichtet. Werden die Statistiken auf Server B jetzt zurückgesetzt und generiert der Datenverkehr auf Server A weitere 10 entfernte Einträge, werden in den Statistiken für Server A 20 entfernte Einträge berichtet und in den Statistiken für Server B 10.
Die API "Dynamic Cache" ermöglicht Benutzern die Registrierung von Ereignis-Listenern. Wenn Sie eXtreme Scale als dynamischen Cache-Provider verwenden, arbeiten die Ereignis-Listener für lokale Speichercaches erwartungsgemäß.
Bei verteilten Caches richtet sich das Ereignisverhalten nach der verwendeten Topologie. Für Caches, die die integrierte Topologie verwenden, werden Ereignisse auf dem Server generiert, der die Schreiboperationen verarbeitet, dem so genannten primären Shard. Das bedeutet, dass nur ein einziger Server Ereignisbenachrichtigungen empfängt, aber dieser Server erhält alle Ereignisbenachrichtigungen, die normalerweise vom dynamischen Cache-Provider erwartet werden. Da WebSphere eXtreme Scale das primäre Shard zur Laufzeit auswählt, ist es nicht möglich sicherzustellen, dass immer ein bestimmter Serverprozess diese Ereignisse empfängt.
Integrierte partitionierte Caches generieren Ereignisse auf jedem Server, der eine Partition des Caches enthält. Wenn ein Cache also 11 Partitionen hat und jeder Server in einem Grid von WebSphere Application Server Network Deployment mit 11 Servern eine der Partitionen enthält, empfängt jeder Server die dynamischen Cacheereignisse für die Cacheeinträge, die er enthält. Es gibt keinen einzigen Prozess, der alle Ereignisse sieht, es sei denn, alle 11 Partitionen befinden sich in diesem einen Serverprozess. Wie bei der integrierten Topologie ist es nicht möglich sicherzustellen, dass immer ein bestimmter Serverprozess einen bestimmten Ereignissatz empfängt.
Caches, die die ferne Topologie verwenden, unterstützen keine dynamischen Cacheereignisse.
Der dynamische Cache-Provider von WebSphere eXtreme Scale unterstützt kein Platten-Caching. Alle MBean-Aufrufe, die sich auf Platten-Caching beziehen, funktionieren nicht.
Der in WebSphere Application Server integrierte dynamische Cache-Provider unterstützt mehrere Richtlinien für die Cachereplikation. Diese Richtlinien können global oder für jeden Cacheeintrag konfiguriert werden. In der Dokumentation zum dynamischen Cache finden Sie eine Beschreibung dieser Replikationsrichtlinien.
Der dynamische Cache-Provider von eXtreme Scale berücksichtigt diese Richtlinien nicht direkt. Die Replikationsmerkmale eines Caches richten sich nach dem konfigurierten Typ für die verteilte eXtreme-Scale-Topologie und gelten für alle Werte in diesem Cache, unabhängig von der vom dynamischen Cacheservice definierten Replikationsrichtlinie für den Eintrag. Die folgende Liste enthält alle Replikationsrichtlinien, die vom dynamischen Cacheservice unterstützt werden, und veranschaulicht, welche eXtreme-Scale-Topologie ähnliche Replikationsmerkmale bietet.
Beachten Sie, dass der dynamische Cache-Provider von eXtreme Scale die Richtlinieneinstellungen für die DRS-Replikation für einen Cache bzw. Cacheeintrag ignoriert. Benutzer müssen die Topologie auswählen, die ihren Replikationsanforderungen am besten entspricht.
Diese Informationen werden hauptsächlich bereitgestellt, damit Sie sicherstellen können, dass die Topologie Ihre Anforderungen bezüglich verteilter Konsistenz erfüllt. Wenn die integrierte Topologie beispielsweise die bessere Wahl für Ihre Implementierungs- und Leistungsanforderungen ist, Sie aber die von SHARED_PUSH_PULL unterstützte Cachekonsistenzstufe benötigen, sollten Sie die integrierte, partitionierte Topologie verwenden, selbst wenn die Leistung geringfügig schwächer ist.
Sie können dynamische Cacheinstanzen, die in einer integrierten oder einer integrierten, partitionierten Topologie ausgeführt werden, mit den in WebSphere Application Server integrierten Sicherheitsfunktionen schützen. Weitere Informationen hierzu finden Sie in der Dokumentation zum Sichern von Anwendungsservern im Information Center von WebSphere Application Server.
Wenn ein Cache in einer fernen Topologie ausgeführt wird, kann ein eigenständiger extreme-Scale-Client eine Verbindung zum Cache herstellen und den Inhalt der dynamischen Cacheinstanz beeinflussen. Der dynamische Cache-Provider von eXtreme Scale besitzt ein Verschlüsselungsfeature, das nur geringe Kosten produziert, aber verhindern kann, dass Cachedaten von Clients, die keine Clients von WebSphere Application Server sind, gelesen oder geändert werden. Zum Aktivieren dieses Features setzen Sie den optionalen Parameter com.ibm.websphere.xs.dynacache.encryption_password in jeder Instanz von WebSphere Application Server, die auf den dynamischen Cache-Provider zugreift, auf denselben Wert. Daraufhin werden der Wert und die Benutzermetadaten für den Cacheeintrag mit 128-Bit-AES-Verschlüsselung verschlüsselt. Es ist sehr wichtig, dass für alle Server derselbe Wert definiert wird. Server können keine Daten lesen, die von Servern mit einem anderen Wert für diesen Parameter in den Cache gestellt werden.
Wenn der Provider von eXtreme Scale erkennt, dass unterschiedliche Werte für diese Variable in demselben Cache gesetzt sind, generiert er eine Warnung im Protokoll des Containerprozesses von eXtreme Scale.
Lesen Sie in der Dokumentation zu eXtreme Scale die Informationen zur Übersicht über die Sicherheit, wenn SSL- oder Clientauthentifizierung erforderlich ist.