Implementieren Sie einen benutzerdefinierten sitzungsähnlichen Cache in Sitecore

Question

Aufgrund von Einschränkungen, die außerhalb meiner Kontrolle liegen, muss ich benutzerdefinierte Objekte für jeden angemeldeten Benutzer meiner Sitecore-Site speichern. Derzeit wird dies im Sitzungsstatus gespeichert. Aufgrund der exclusive locksim Sitzungsspeicher, wie in diesem Artikel von Sitecore beschrieben, herrscht im Sitzungsspeicher viel Druck auf den Sitzungsstatusspeicher . Gemäß diesem Artikel sollte das Speichern von benutzerdefinierten Objekten in einer Sitzung vermieden und custom cachestattdessen in einem gespeichert werden.

Hat jemand einen solchen benutzerdefinierten Cache implementiert und wenn ja, wie wurde das gemacht? Ich suche nach dem gleichen Verhalten für diesen benutzerdefinierten Cache wie der Sitzungsstatus, z. B. eindeutig für die Browsersitzung des aktuellen Benutzers, nach Beendigung der Sitzung beenden, nur für alle Anforderungen in der Sitzung verfügbar usw.

Zu Ihrer Information, meine Probleme beziehen sich auf die exclusive locksim Sitzungsspeicher. Die neuere Version Microsoft.AspNet.SessionState.SessionStateModuleAsync ermöglicht mehrere aspnet:AllowConcurrentRequestsPerSessionEinstellungen pro Sitzung durch Einstellung. AFAIK Dieses Sitzungsstatusmodul wird von Sitecore nicht unterstützt. Wenn jemand dieses Problem auf diese Weise behoben hat, würde mich auch der Ansatz sehr interessieren.

Answer 1

Ich habe etwas Ähnliches getan, obwohl es nicht genau ein benutzerdefinierter Cache ist, der einem Sitzungsstatus entspricht.

In meinem Projekt haben wir Couchbase verwendet, obwohl die Prinzipien auch leicht auf Redis angewendet werden können.

Wir haben ein einfaches geschrieben ICacheProvider, das uns alle Eigenschaften / Methoden gab, die wir brauchten, und es im Container als registriert Scoped, sodass wir einen Singleton pro Anfrage erhalten. Das hat sich beim Erstellen und Zerstören von Verbindungen usw. besser bewährt. YMMV Wenn Sie Redis verwenden, befolgen Sie dort die Best Practice.

Dann können Sie diesen Cache-Anbieter auf ähnliche Weise wie die Sitzung verwenden. Fügen Sie einfach die Objekte in den Cache ein, geben Sie einen eindeutigen Schlüssel ein. In Ihrem Fall können Sie problemlos die Sitzungs-ID verwenden und dann eine Möglichkeit angeben, dass der Cache abläuft.

Wenn Sie die Sitzungs-ID als eindeutigen Schlüssel verwenden, kann der Cache einfach eine lange Dauer haben, möglicherweise 24 bis 48 Stunden vor Ablauf. Es ist unwahrscheinlich, dass eine Sitzung länger dauert. Wenn sich der Benutzer das nächste Mal auf der Site anmeldet, erhält er ohnehin eine neue Sitzungs-ID. Es ist hacky, sollte aber funktionieren.

Alternativ können Sie sich in das session_endEreignis einbinden und den Cache direkt auf diese Weise ungültig machen.

Sobald Sie alles erstellt haben, tauschen Sie einfach Ihre vorhandenen Sitzungsstatusaufrufe aus und ersetzen sie durch Ihre benutzerdefinierten Redis / Couchbase-Cache-Provider-Aufrufe.

Der große Vorteil der Verwendung eines verteilten Anbieters für Ihren Cache besteht darin, dass Sie sich keine Gedanken über Sticky-Sitzungen oder Anforderungen an verschiedene Load Balancer machen müssen. Alle Instanzen lesen aus demselben Cache, ähnlich wie der Redis / SQL Server-Sitzungsstatus Management funktioniert.

Es gibt eine Reihe guter Referenzen für die Verwendung von Redis als Cache:

• https://www.c-sharpcorner.com/article/five-best-ways-to-use-redis-with-asp-net-mvc/
• https://jakeydocs.readthedocs.io/en/latest/performance/caching/distributed.html
• https://docs.microsoft.com/en-us/azure/azure-cache-for-redis/cache-web-app-howto