Mehrere Webanwendungen - Cache-Layer-Design

Mehrere Webanwendungen - Cache-Layer-Design

Ich habe mehrere Client-E-Commerce-Webanwendungen, die auf einer einzigen VM laufen. Jede Webanwendung ist eine Node.js Express-Anwendung.

Die Express-Webanwendung kommuniziert über APIs mit dem Backend, um den Inhalt der Seiten und die Produktliste usw. abzurufen. Um die Produktsuche zu beschleunigen, verwenden wir derzeit jedoch eine In-Memory-Datenbank (Abonnieren), damit alle Suchvorgänge ausgeführt werden können. Das funktioniert für uns im Moment ziemlich gut, da der durchschnittliche Produktkatalog jedes Kunden nur etwa 80 Artikel umfasst. Wir lassen in der Webanwendung jedes Kunden einen einfachen Cron laufen, um die In-Memory-Datenbank über einen API-Aufruf mit der neuesten Produktliste zu aktualisieren.

Dies hat unter anderem folgende Nachteile: Da wir PM2 verwenden, um jede Anwendung in einem Cluster mit 2 Knoten auszuführen, muss die In-Memory-Datenbank dupliziert werden, da Sie den Speicher nicht zwischen den Knoten teilen können. Um sicherzustellen, dass die In-Memory-Datenbanken synchron bleiben, verwenden wir IPCs, um Nachrichten an alle Prozesse innerhalb des Clusters weiterzuleiten.

Da wir größere Kunden mit größeren Produktkatalogen an Bord holen, möchten wir nicht für jeden untergeordneten Prozess doppelte In-Memory-Datenbanken führen.

Unser Angebot funktioniert so: Obwohl die Produktkataloge pro Kunde nicht umfangreich sind, ist das Suchvolumen recht hoch. Ein Kunde mit 80 Artikeln kann also trotzdem Tausende von Suchanfragen pro Tag erhalten.

Mir sind mehrere Möglichkeiten in den Sinn gekommen, ich bin mir jedoch nicht sicher, welche die beste wäre:

Option 1 – Einzelner globaler Elasticsearch-Cluster

Ich habe darüber gesprochen und nachgedacht, Elasticsearch zu verwenden und dann jede einzelne Client-Webanwendung auf einen einzelnen globalen Elasticsearch-Cluster zu verweisen, um Produktsuchen dort durchzuführen. Auf diese Weise können wir Ereignisse verwenden, um die Elasticsearch-Datenbank in Echtzeit auf dem neuesten Stand zu halten.

Ich weiß jedoch nicht, wie sich das bei der Skalierung entwickeln wird, ich möchte nicht, dass Elasticsearch zum Engpass wird

Option 2 – Lokale NoSQL-Datenbank

Die zweite Möglichkeit bestand darin, die Verwendung von lokijs als In-Memory-Datenbank einfach zu ersetzen und für jede VM eine gemeinsame NoSQL-Datenbank (wie Mongo) zu verwenden. Alle Webanwendungen verwenden dann die lokale Datenbank für Abfragen. Jede Webanwendung ist weiterhin für die Aktualisierung des Produktkatalogs für ihren eigenen Shop verantwortlich. Wenn wir dann weitere VMs hinzufügen, verfügt jede VM über eine eigene lokale Datenbank für alle darauf ausgeführten Anwendungen.

Wir nutzen intensiv die Facettensuche und Aggregationen von Facetten, um Zählungen für die Facetten zu erhalten.

verwandte Informationen