Lo más vital para un funcionamiento fluido del comercio electrónico

¿Por qué usamos replicación en Spurtcommerce?

En Spurtcommerce, una solución de comercio electrónico de código abierto basada en NodeJS y Angular, utilizamos la mejor metodología para mejorar la carga de imágenes. Optimizamos todo el proceso para que sea rápido y sin demoras para los visitantes.

Primero, tus aplicaciones ya no dependen de un único servidor de base de datos. Si el servidor maestro falla, puedes cambiar temporalmente la conexión al servidor replicado para mantener la estabilidad durante una caída crítica, incluso ante fallos de red o hardware.

Segundo, el rendimiento en realidad mejora, aunque la complejidad haga pensar lo contrario. Al distribuir los datos entre varios servidores, puedes conectar diferentes aplicaciones a diferentes servidores y así mejorar el rendimiento. Así funcionan los centros de datos: conectan al usuario con el servidor más cercano para reducir la latencia.

La mayoría de las empresas usan tablas de bases de datos transaccionales, lo que significa que el motor de almacenamiento preferido es InnoDB. Con replicación, los commits se escriben primero a través de la red en lugar del disco duro como en un servidor único, lo que mejora notablemente el rendimiento.

La replicación también actúa como una copia de seguridad eficiente ante desastres, mejor que guardar datos en discos. Con replicación, puedes restaurar tu servidor maestro desde los datos replicados sin necesidad de buscar en archivos de respaldo.

La configuración básica es maestro-esclavo, donde el maestro maneja las escrituras y el esclavo solo lee datos en una base de datos espejo. También puedes configurar una solución maestro-maestro, adecuada para plataformas empresariales. Con maestro-maestro, puedes balancear la carga entre transacciones usando un balanceador de carga entre la aplicación y las bases de datos, enviando las solicitudes al servidor más adecuado.

Incluso con la red más rápida, existe latencia en la replicación, lo que debe tenerse en cuenta al configurar el entorno. No es preocupante si la base de datos replicada se usa como respaldo o para reportes. Es común tener una demora de 24 horas entre los datos productivos y las herramientas de reportes. Sin embargo, si el servidor replicado se usa para operaciones críticas, la latencia debe monitorearse cuidadosamente para evitar problemas de integridad de datos.

De este modo, el equipo de Spurtcommerce ha planificado perfectamente el balanceo de carga de base de datos en su solución de comercio electrónico de código abierto para admitir tres bases de datos -MySQL, PostgresSQL and SQL Server.

Configuración profunda

{
  replication: {
    master: {
      host: "server1",
      port: 3306,
      username: "test",
      password: "test",
      database: "test"
    },
    slaves: [{
      host: "server2",
      port: 3306,
      username: "test",
      password: "test",
      database: "test"
    }, {
      host: "server3",
      port: 3306,
      username: "test",
      password: "test",
      database: "test"
    }],

    /**
    * If true, PoolCluster will attempt to reconnect when connection fails. (Default: true)
    */
    canRetry: true,

    /**
     * If connection fails, node's errorCount increases.
     * When errorCount is greater than removeNodeErrorCount, remove a node in the PoolCluster. (Default: 5)
     */
    removeNodeErrorCount: 5,

    /**
     * If connection fails, specifies the number of milliseconds before another connection attempt will be made.
     * If set to 0, then node will be removed instead and never re-used. (Default: 0)
     */
     restoreNodeTimeout: 0,

    /**
     * Determines how slaves are selected:
     * RR: Select one alternately (Round-Robin).
     * RANDOM: Select the node by random function.
     * ORDER: Select the first node available unconditionally.
     */
    selector: "RR"
  }
}