Múltiples aplicaciones web: diseño de capas de caché

Múltiples aplicaciones web: diseño de capas de caché

Tengo varias aplicaciones web de comercio electrónico de clientes ejecutándose en una sola máquina virtual, cada aplicación web es una aplicación express de Node.js.

La aplicación web express se comunica con el back-end a través de API para recuperar el contenido de las páginas y la lista de productos, etc. Sin embargo, para agilizar las búsquedas de productos, actualmente utilizamos una base de datos en memoria (lokijs) para que se realicen todas las búsquedas, esto funciona bastante bien para nosotros en este momento, ya que el catálogo de productos promedio para cada cliente es de solo alrededor de 80 artículos, tenemos un cron simple ejecutándose dentro de la aplicación web de cada cliente para actualizar la base de datos en memoria con la lista de productos más reciente a través de una llamada API.

Algunas de las desventajas de esto son que, dado que usamos PM2 para ejecutar cada aplicación en un clúster de 2 nodos, la base de datos en memoria debe duplicarse ya que no se puede compartir memoria entre los nodos, para garantizar que las bases de datos en memoria permanezcan en sync utilizamos IPC para pasar mensajes a todos los procesos dentro del clúster.

A medida que incorporamos clientes más grandes con catálogos de productos más grandes, realmente no queremos mantener bases de datos en memoria duplicadas para cada proceso hijo.

La forma en que funciona nuestra oferta es que, aunque los catálogos de productos no son grandes por cliente, el volumen de búsqueda es bastante grande, por lo que un cliente con 80 artículos aún puede recibir miles de búsquedas por día.

Tenía un par de opciones en mente, pero no estaba seguro de cuál sería la mejor:

Opción 1: clúster de búsqueda elástica global único

He hablado y pensado en usar elasticsearch y luego señalar cada aplicación web cliente a un único clúster global de elasticsearch para realizar búsquedas de productos, de esta manera podemos usar eventos para mantener la base de datos de elasticsearch actualizada en tiempo real.

Sin embargo, no sé cómo funcionará esto a medida que crezcamos, no quiero que elasticsearch se convierta en un cuello de botella.

Opción 2: base de datos nosql local

La segunda opción era simplemente reemplazar el uso de lokijs como base de datos en memoria y tener una base de datos nosql compartida (como mongo) para cada VM, todas las aplicaciones web usan la base de datos local para consultas, cada aplicación web sigue siendo responsable. para actualizar el catálogo de productos de su propia tienda. Luego, a medida que agreguemos más máquinas virtuales, cada máquina virtual tendrá su propia base de datos local para que la use cualquier aplicación que se ejecute allí.

Somos grandes usuarios de búsqueda por facetas y agregaciones de facetas para obtener recuentos de las facetas.

información relacionada