J2EE-Objekt-Caching-Frameworks

Auf Webanwendungen wird normalerweise von vielen gleichzeitigen Benutzern zugegriffen. Normalerweise werden die Daten der Anwendung in einer relationalen Datenbank oder einem relationalen Dateisystem gespeichert, und der Zugriff auf diese Datenquellen erfordert Zeit und Kosten. Engpässe beim Datenbankzugriff können die Anwendung verlangsamen oder sogar zum Absturz bringen, wenn zu viele gleichzeitige Anforderungen eingehen. Das Zwischenspeichern von Objekten ist eine Technik, die dieses Problem überwindet. In diesem Artikel beschreibt Srini Penchikala ein einfaches Caching-Implementierungsframework, das er zum Zwischenspeichern der Suchdatenobjekte in einem Webportalprojekt erstellt hat.

Durch das Zwischenspeichern von Objekten können Anwendungen Objekte für mehrere Anforderungen und Benutzer freigeben und die Lebenszyklen der Objekte prozessübergreifend koordinieren. Durch das Speichern von Objekten, auf die häufig zugegriffen wird oder deren Erstellung teuer ist, im Objekt-Caching entfällt die Notwendigkeit, Daten wiederholt zu erstellen und zu laden. Es vermeidet die teure Wiedererfassung von Objekten, indem die Objekte nicht unmittelbar nach ihrer Verwendung freigegeben werden. Stattdessen werden die Objekte im Speicher gespeichert und für nachfolgende Clientanforderungen wiederverwendet.

So funktioniert das Caching: Wenn die Daten zum ersten Mal aus der Datenquelle abgerufen werden, werden sie vorübergehend in einem als Cache bezeichneten Speicherpuffer gespeichert . Wenn erneut auf dieselben Daten zugegriffen werden muss, wird das Objekt anstelle der Datenquelle aus dem Cache abgerufen. Die zwischengespeicherten Daten werden aus dem Speicher freigegeben, wenn sie nicht mehr benötigt werden. Um zu steuern, wann ein bestimmtes Objekt aus dem Speicher freigegeben werden kann, muss eine angemessene Ablaufzeit definiert werden. Danach werden die im Objekt gespeicherten Daten aus Sicht einer Webanwendung ungültig.

Nachdem wir uns nun mit den Grundlagen der Funktionsweise des Zwischenspeicherns befasst haben, wollen wir uns einige der bekannten Szenarien in einer J2EE-Anwendung ansehen, die Objektspeichermechanismen verwenden, die dem Zwischenspeichern ähnlich sind.

Herkömmliche Methoden für die Objektsuche wie eine einfache Hashtabelle, JNDI (Java Naming and Directory Interface) oder sogar EJB (Enterprise JavaBeans) bieten eine Möglichkeit, ein Objekt im Speicher zu speichern und die Objektsuche basierend auf einem Schlüssel durchzuführen. Keine dieser Methoden bietet jedoch einen Mechanismus zum Entfernen des Objekts aus dem Speicher, wenn es nicht mehr benötigt wird, oder zum automatischen Erstellen des Objekts, wenn nach Ablauf darauf zugegriffen wird. Das HttpSessionObjekt (im Servlet-Paket) ermöglicht auch das Zwischenspeichern von Objekten, es fehlen jedoch die Konzepte der Freigabe, Ungültigmachung, des Ablaufs pro Objekt, des automatischen Ladens oder des Spoolens, die die wesentlichen Elemente eines Caching-Frameworks sind.

Objekt-Caching in Webportalen

Ein Portal muss sowohl Benutzerprofile als auch die im Portal verfügbaren Objekte verwalten. Da die meisten Webportale die SSO-Funktion (Single Sign-On) bieten, ist das Speichern der Benutzerprofildaten auch dann von entscheidender Bedeutung, wenn der Benutzer zwischen verschiedenen Modulen in der Webportalanwendung wechselt. Die Benutzerprofile sollten sicher im Cache gespeichert sein, damit andere Webbenutzer nicht darauf zugreifen können. Die Objekte können aus dem Cache gealtert werden, um Speicherplatz freizugeben, oder die Leerlauffunktion kann Objekte entfernen, auf die nicht zugegriffen wird. Dies vereinfacht die Objektverwaltung, da die Anwendung nicht ständig überwachen muss, welche Objekte zu einem bestimmten Zeitpunkt nachgefragt werden. Die "heißen" Objekte sind automatisch im Cache verfügbar. Objekte, deren Erstellung oder Abruf teuer ist, können auf eine lokale Festplatte geschrieben und bei Bedarf transparent abgerufen werden. So,Das Objekt-Caching kann zum Verwalten der Benutzerprofilinformationen und Suchdaten verwendet werden, z. B. Produktinformationen des Unternehmens, die von mehreren Portalbenutzern gemeinsam genutzt werden können.

Vorteile und Verbindlichkeiten für das Zwischenspeichern von Objekten

Einer der Hauptvorteile des Objekt-Caching ist die signifikante Verbesserung der Anwendungsleistung. In einer mehrschichtigen Anwendung ist der Datenzugriff im Vergleich zu anderen Aufgaben ein teurer Vorgang. Indem wir Daten, auf die häufig zugegriffen wird, aufbewahren und nach ihrer ersten Verwendung nicht freigeben, können wir die Kosten und die Zeit vermeiden, die für die erneute Erfassung und Freigabe der Daten erforderlich sind. Das Zwischenspeichern von Objekten führt aus folgenden Gründen zu einer verbesserten Leistung von Webanwendungen:

  • Es reduziert die Anzahl der Fahrten zur Datenbank oder zu anderen Datenquellen wie XML-Datenbanken oder ERP-Legacy-Systemen (Enterprise Resource Planning)
  • Dadurch werden die Kosten für die wiederholte Neuerstellung von Objekten vermieden
  • Es teilt Objekte zwischen Threads in einem Prozess und zwischen Prozessen
  • Prozessressourcen werden effizient genutzt

Die Skalierbarkeit ist ein weiterer Vorteil des Objekt-Caching. Da auf zwischengespeicherte Daten über mehrere Sitzungen und Webanwendungen hinweg zugegriffen wird, kann das Zwischenspeichern von Objekten ein wichtiger Bestandteil des Designs einer skalierbaren Webanwendung werden. Durch das Zwischenspeichern von Objekten werden die Kosten für das Erfassen und Freigeben von Objekten vermieden. Es setzt wertvolle Hardware- und Softwareressourcen des Systems frei, indem Daten über ein Unternehmen verteilt werden, anstatt sie an einem zentralen Ort wie der Datenschicht zu speichern. Lokal gespeicherte Daten adressieren direkt die Latenz, senken die Betriebskosten und beseitigen Engpässe. Das Caching erleichtert die Verwaltung von Webanwendungen, indem sie zu Spitzenverkehrszeiten ohne die Kosten zusätzlicher Server skaliert werden können. Es kann Leistungskurven in einer Webanwendung effektiv glätten, um eine rundum bessere Leistung und Ressourcenzuweisung zu erzielen.

Das Zwischenspeichern von Objekten weist auch einige Nachteile auf, wie beispielsweise die Speichergröße. Der Cache belegt möglicherweise erheblichen Heap-Speicherplatz auf dem Anwendungsserver. Die JVM-Speichergröße kann unannehmbar groß werden, wenn sich viele nicht verwendete Daten im Cache befinden und nicht in regelmäßigen Abständen aus dem Speicher freigegeben werden.

Ein weiterer Nachteil ist die Komplexität der Synchronisation. Abhängig von der Art der Daten nimmt die Komplexität zu, da die Konsistenz zwischen dem Status der zwischengespeicherten Daten und den Originaldaten der Datenquelle sichergestellt werden muss. Andernfalls können die zwischengespeicherten Daten nicht mehr mit den tatsächlichen Daten synchron sein, was zu Datenungenauigkeiten führt.

Schließlich können Änderungen an den zwischengespeicherten Daten verschwinden, wenn der Server abstürzt. Ein weiterer Nachteil. Ein synchronisierter Cache könnte dieses Problem verhindern.

Objekt-Caching verwenden

Typische Anwendungen des Objekt-Caching sind das Speichern von HTML-Seiten, Datenbankabfrageergebnissen oder Informationen, die als Java-Objekt gespeichert werden können. Grundsätzlich sind alle Daten, die sich nicht häufig ändern und für die Rückgabe aus der Datenquelle viel Zeit benötigen, ein guter Kandidat für das Caching. Dies umfasst die meisten Arten von Suchdaten, Code- und Beschreibungslisten sowie allgemeine Suchergebnisse mit Paging-Funktionen (Suchergebnisse können einmal aus der Datenquelle extrahiert und im Cache gespeichert werden, damit sie verwendet werden können, wenn der Benutzer auf den Paging-Link des Ergebnisbildschirms klickt).

Das HttpSessionObjekt im Tomcat-Servlet-Container bietet ein gutes Beispiel für das Zwischenspeichern von Objekten. Tomcat verwendet eine Instanz von Hashtable, um Sitzungsobjekte zu speichern und veraltete Sitzungsobjekte mithilfe eines Hintergrundthreads abzulaufen.

Middleware-Technologien wie EJB und CORBA ermöglichen die Remoteübertragung von Objekten, bei denen das Remoteobjekt zwischen dem Client und dem Server übertragen wird. Diese Art des Zugriffs, auch als grobkörniger Datenzugriff bezeichnet, minimiert die Anzahl teurer Remote-Methodenaufrufe. Diese Datenübertragungsobjekte (auch als Wertobjekte bezeichnet) können im Cache gespeichert werden, wenn sich die Objekte nicht häufig ändern. Dies begrenzt die Häufigkeit, mit der der Servlet-Container auf den Anwendungsserver zugreifen muss.

Weitere Beispiele für die Verwendung von Objekt-Caching folgen:

  • Enterprise JavaBeans: EJB-Entity-Beans repräsentieren Datenbankinformationen in der mittleren Ebene, dem Anwendungsserver. Nach der Erstellung werden die Entity-Beans im EJB-Container zwischengespeichert, wodurch teures Abrufen von Daten (Ressourcenerfassung) aus der Datenbank vermieden wird.
  • EJBHomeFactoryCache: Wenn Clientanwendungen den Stub nicht irgendwo zwischenspeichern, kann der Aufruf einer Remotemethode viel teurer werden, da für jeden logischen Aufruf des Servers zwei Remoteaufrufe erforderlich sind: einer an den Namensdienst zum Abrufen eines Stubs und einer an den eigentlichen Server. Dieses Problem kann gelöst werden, indem eine EJBHomeFactoryKlasse erstellt wird, um die Verweise auf EJB- HomeSchnittstellen zwischenzuspeichern und für die nachfolgenden Aufrufe wiederzuverwenden.
  • Webbrowser: Die gängigsten Webbrowser wie Netscape und Internet Explorer zwischenspeichern häufig auf Webseiten. Wenn ein Benutzer auf dieselbe Seite zugreift, rufen die Browser den Inhalt der Seite aus dem Cache ab, wodurch das teure Abrufen des Inhalts von der Website vermieden wird. Zeitstempel legen fest, wie lange die Seiten im Cache aufbewahrt werden sollen und wann sie entfernt werden sollen.
  • Datencache: In einem RDBMS (relationales Datenbankverwaltungssystem) gespeicherte Daten werden als eine Ressource angesehen, die manchmal schwer zu beschaffen ist. Ein Cache mit der richtigen Größe ist eine wichtige Komponente einer gut abgestimmten Datenbank. Die meisten Datenbanken enthalten einen Datencache. Oracle enthält beispielsweise einen gemeinsam genutzten globalen Bereich, der einen Cache mit kürzlich verwendeten Datenbankblöcken und Caches mit kompiliertem Code für gespeicherte Prozeduren, analysierten SQL-Anweisungen, Datenwörterbuchinformationen und mehr enthält.

Wie wäre es mit Daten, die nicht zum Zwischenspeichern geeignet sind? Hier ist eine Liste von Daten, die für das Caching nicht empfohlen werden:

  • Sichere Informationen, auf die andere Benutzer auf einer Website zugreifen können
  • Persönliche Informationen wie Sozialversicherungsnummer und Kreditkartendaten
  • Geschäftsinformationen, die sich häufig ändern und Probleme verursachen, wenn sie nicht aktuell und genau sind
  • Sitzungsspezifische Daten, auf die andere Benutzer möglicherweise nicht zugreifen können

Caching-Algorithmen

Im Cache gespeicherte Ressourcen benötigen Speicher. Wenn diese Ressourcen längere Zeit nicht genutzt werden, erweist sich das Festhalten an ihnen als ineffizient. Da die Kapazität des Caches begrenzt ist, müssen wir bei vollem Cache einen Teil des Cache-Inhalts löschen, bevor wir ihn erneut füllen. Eine Anwendung kann zwischengespeicherte Objekte auf drei verschiedene Arten explizit ungültig machen: durch Verknüpfen einer "Time-to-Live" (TTL) oder "Idle-Time" mit einem Objekt oder wenn die Kapazität des Caching-Systems erreicht wurde (dies ist ein konfigurierbarer Wert ) werden nicht kürzlich verwendete Objekte vom Caching-System entfernt.

Eine Vielzahl von Cache-Ablaufmechanismen kann Objekte aus einem Cache entfernen. Diese Algorithmen basieren auf Kriterien wie am wenigsten verwendet (LFU), am wenigsten verwendet (LRU), zuletzt verwendet (MRU), First-In-First-Out (FIFO), Letzte Zugriffszeit und Objektgröße. Jeder Algorithmus hat Vor- und Nachteile. LFU und LRU sind einfach, berücksichtigen jedoch nicht die Objektgröße. Ein größenbasierter Algorithmus entfernt große Objekte (die viel Speicher benötigen), aber die Byte-Trefferquote ist niedrig. Es ist wichtig, alle Anforderungen der Webanwendung zu berücksichtigen, bevor Sie entscheiden, welcher Cache-Algorithmus zum Ablaufen zwischengespeicherter Objekte verwendet werden soll.

Objekt-Caching in einer J2EE-Anwendung

In verteilten Systemen wie einer J2EE-Anwendung können zwei Arten des Caching existieren: clientseitiges und serverseitiges Caching. Das clientseitige Caching ist nützlich, um die Netzwerkbandbreite und die Zeit zu sparen, die zum wiederholten Übertragen von Serverdaten an den Client erforderlich ist. Andererseits ist das serverseitige Caching nützlich, wenn viele Clientanforderungen zu wiederholten Erfassungen derselben Ressource auf dem Server führen. Serverseitiges Caching kann in jeder Schicht erreicht werden, dh in jeder Datenbank, jedem Anwendungsserver, Servlet-Container und Webserver.

Serversubsysteme wie die Servlet-Engine können die Serverleistung verbessern, indem Elemente wie Anforderungs-, Antwort- und Pufferobjekte zusammengefasst werden. Die Servlet-Objekte selbst können im Cache gespeichert werden. Die Funktion zur Ungültigmachung von Gruppen kann dann verwendet werden, wenn ein erneutes Laden der Anwendung erforderlich ist. Alle Servlets und verwandten Objekte in einer Anwendung können mit einem einzigen Methodenaufruf bereinigt werden. Ein Teil oder die gesamte Antwort kann zwischengespeichert werden, wenn sie auf mehr als eine Antwort anwendbar ist, was die Antwortzeit erheblich verbessern kann. In ähnlicher Weise kann das Zwischenspeichern in der Datenschicht eine signifikante Leistungsverbesserung bewirken.

Der IronEye-Cache (von IronGrid) bietet die Möglichkeit, häufig angeforderte SQL-Anweisungen in einem Cache zu speichern, um Datenbankaufrufe zu minimieren und häufig angeforderte Informationen schnell bereitzustellen. Oracle bietet Objekt-Caching in allen Ebenen. Oracle Web Cache befindet sich vor den Anwendungsservern (Webservern), speichert deren Inhalt zwischen und stellt diesen Inhalt Webbrowsern zur Verfügung, die ihn anfordern. Der Object Caching Service für Java bietet das Caching für teure oder häufig verwendete Java-Objekte in Java-Programmen. Der Object Caching Service für Java lädt und aktualisiert Objekte automatisch, wie von der Java-Anwendung angegeben. Und schließlich bietet Oracle iCache Data Source das Zwischenspeichern von Daten innerhalb des Datenbankservers.

Objekt-Caching in einem J2EE-Cluster

Das Zwischenspeichern von Objekten in einem Cluster ist wichtig, da mehrere JVMs in einem Cluster ausgeführt werden und das Synchronisieren aller zwischengespeicherten Daten aller Clustermitglieder von entscheidender Bedeutung ist. Da jeder Servlet-Container eine Cache-Manager-Instanz in seiner JVM hat, müssen Datenänderungen in allen Caches berücksichtigt werden, um veraltete Lesevorgänge zu verhindern. Dies kann erreicht werden, indem eine nachrichtengesteuerte Bean (MDB) verwendet wird, um alle Cache-Manager zu benachrichtigen, wann die zwischengespeicherten Daten aktualisiert werden sollen. Viele Caching-Frameworks bieten integrierte Clusterunterstützung für das Caching von Daten.

Caching-Frameworks

Mehrere Objekt-Caching-Frameworks (sowohl Open Source- als auch kommerzielle Implementierungen) bieten verteiltes Caching in Servlet-Containern und Anwendungsservern. Es folgt eine Liste einiger der derzeit verfügbaren Frameworks:

Open Source:

  • Java Caching System (JCS)
  • OSCache
  • Java Object Cache (JOCache)
  • Java Caching Service, eine Open Source-Implementierung der JCache-API (SourceForge.net)
  • SwarmCache
  • JBossCache
  • IronEye-Cache

Kommerziell:

  • SpiritCache (von SpiritSoft)
  • Kohärenz (Tangosol)
  • ObjectCache (ObjectStore)
  • Object Caching Service für Java (Oracle)

Wenn Sie mehr über diese Caching-Implementierungen erfahren möchten, finden Sie unter Ressourcen Links zu all diesen Frameworks.

Faktoren, die in einem Objekt-Caching-Framework berücksichtigt werden müssen

Suchen Sie in einem Caching-Framework nach den folgenden Faktoren: