Implementa una cache simile a una sessione personalizzata in Sitecore

Question

A causa di limitazioni al di fuori del mio controllo, dovrò archiviare oggetti personalizzati per ogni utente che ha effettuato l'accesso al mio sito Sitecore. Attualmente questo viene memorizzato nello stato della sessione. C'è molta pressione sull'archivio dello stato della sessione a carico elevato a causa dell'archivio exclusive locksdella sessione come descritto in questo articolo di Sitecore. In base a questo articolo, la memorizzazione di oggetti personalizzati nella sessione dovrebbe essere evitata e dovrebbe essere archiviata custom cacheinvece in un file.

Qualcuno ha implementato una tale cache personalizzata e, in caso affermativo, come è stato fatto? Sto cercando lo stesso comportamento per questa cache personalizzata come stato della sessione, ad esempio univoco per la sessione del browser dell'utente corrente, termina al termine della sessione, disponibile solo per tutte le richieste nella sessione ecc.

Cordiali saluti, i miei problemi sono legati al exclusive locksnegozio di sessioni. Il più recente Microsoft.AspNet.SessionState.SessionStateModuleAsync consente più richieste per sessione attraverso aspnet:AllowConcurrentRequestsPerSessionl'impostazione. AFAIK questo modulo di stato della sessione non è supportato da Sitecore. Se qualcuno ha risolto questo problema in questo modo, sarei molto interessato anche all'approccio.

Answer 1

Ho fatto qualcosa di simile, anche se non esattamente una cache personalizzata che è l'equivalente di uno stato della sessione.

Nel mio progetto abbiamo utilizzato couchbase anche se i principi potrebbero essere facilmente applicati anche a Redis.

Abbiamo scritto un semplice ICacheProviderche ci ha fornito tutte le proprietà/metodi di cui avevamo bisogno e lo abbiamo registrato con il contenitore come Scoped, quindi otteniamo un singleton per richiesta. Ciò ha funzionato meglio con la creazione e la distruzione di connessioni, ecc ... YMMV se usi Redis, segui le migliori pratiche lì.

Quindi puoi semplicemente utilizzare quel provider di cache in modo simile a come utilizzeresti Session. Basta aggiungere gli oggetti nella cache, fornire una chiave univoca: nel tuo caso potresti facilmente utilizzare l'ID di sessione e quindi fornire un modo per far scadere la cache.

Se stai usando il Session Id come chiave univoca, potresti semplicemente avere una lunga durata per la cache, forse 24-48 ore prima che scada. È improbabile che una sessione duri più a lungo, la prossima volta che l'utente accede al sito, otterrebbe comunque un nuovo ID di sessione. È complicato, ma dovrebbe funzionare.

In alternativa, puoi collegarti session_endall'evento e invalidare la cache direttamente in questo modo.

Dopo aver creato tutto, devi semplicemente scambiare le chiamate allo stato della sessione esistenti e sostituirle con le chiamate del provider di cache Redis/Couchbase personalizzate.

Il grande vantaggio dell'utilizzo di un provider distribuito per la tua cache è che non devi preoccuparti di sessioni permanenti o richieste che vanno a diversi bilanciatori del carico, tutte le istanze leggeranno dalla stessa cache, in modo simile allo stato della sessione Redis/SQL Server lavori di gestione.

Esistono numerosi buoni riferimenti su come utilizzare Redis come 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