Cache invalidation su più server

Question

Cache invalidation su più server

#1 da (0 voti)

1

Ho 6 server web che mi danno problemi a causa dell'inconsistenza della cache. Sto pensando di creare un servizio di invalidazione della cache in modo tale che ci sia un argomento sul quale tutti i server possono pubblicare un messaggio per invalidare un oggetto. Sto pensando di utilizzare Amazon SNS per creare l'argomento.

Ora che i server ricevono i messaggi di invalidazione, sono confuso tra quanto segue:

Devo utilizzare le code SQS per i server per ricevere messaggi.
Dovrei utilizzare gli endpoint HTTP e quindi creare un'API su quella route che invalida la cache.

Potresti evidenziare i pro e i contro di entrambi questi approcci o qualsiasi altro approccio che potrebbe avvantaggiarmi.

---------- --------- UPDATE

Se utilizzo NGINX per reindirizzare qualsiasi richiesta a uno dei 6 server. Se sto usando l'endpoint HTTP, l'argomento finirà per colpire solo uno dei server. Inoltre non sono sicuro su quale porta verrà eseguita la mia applicazione. Potresti suggerirmi un modo per aggirare il server NGINX o trovare la porta al volo e poi colpire i server.

architecture caching message-queue nginx

posta tanvi 17.06.2016 - 08:54

fonte

1 risposta

Leggi altre domande sui tag architecture caching message-queue nginx

I casi d'uso scritti devono essere coerenti con il diagramma dei casi d'uso? Come convincere i compagni di squadra a iniziare a separare le query del database in un unico livello

score 0 · Accepted Answer

Secondo i commenti, hai un sistema di caching che si basa su:

Un comune servizio di cache Redis utilizzato da tutti i server,
Una cache in memoria su ogni server che in qualche modo duplica alcuni dei dati Redis. Le informazioni memorizzate in questa cache sono soggette a incoerenza e stai cercando un modo per prevenire questa incoerenza.

Prima di tutto, probabilmente avrai solo bisogno della cache Redis. Se configurato correttamente, è abbastanza veloce da servire tutti e sei i server. Se solo indovina che renderà le cose più veloci avendo un caching in-memory aggiuntivo, allora stai facendo un'ottimizzazione prematura. Invece, sbarazzati della cache in memoria e pensaci solo se e quando un profiler identificherà Redis come un collo di bottiglia .

Se hai già profilato la tua app e identificato Redis come collo di bottiglia, puoi scegliere:

Potrebbe essere possibile modificare la configurazione di Redis o modificare la rete o sostituire l'hardware, a seconda del problema che si sta verificando.
Puoi mettere Redis su diversi server e lasciare che i prodotti esistenti si occupino di argomenti come il failover, la cache distribuita invalidazione, ecc.
Puoi chiedere ad altri, come Amazon, di gestire il caching per te. Questo ti dà un'enorme flessibilità in termini di scale di cui hai bisogno in un dato momento.
Potresti finalmente usare le soluzioni di cache distribuita memcached o simili che verrebbero installate su ciascuno dei sei server. Assicurati di utilizzare un prodotto esistente e non reinventare il tuo, poiché creare il tuo potrebbe essere molto complicato; l'invalidazione della cache è una delle parti più difficili, come hai notato.