Hola a todos.
Y bienvenidos de nuevo.
Ahora, en el video de hoy, vamos a discutir sobre el papel de las colas de mensajes en las transacciones de base de datos.
Así que vamos a seguir adelante y entender esto con un caso de uso.
Supongamos que tiene una única base de datos alojada en RDF.
Ahora, debido a una promoción de ventas en curso, el número de transacciones correctas que se han producido últimamente
en la base de datos ha alcanzado diez veces la carga normal.
Así que usted tiene un gran número de transacciones correctas que están sucediendo ahora ya que tiene una sola base
de datos que está presente y hay una alta carga, muchas de las peticiones están fallando con regularidad.
Y hay un requisito más importante aquí es que las nuevas promociones de venta que están en curso
debido a que hay 20 veces la carga normal, estas promociones de venta se programan cada mes alterno.
Por lo tanto, no se trata de 24 horas al día durante todo el mes.
Se celebra cada dos meses.
Ahora, basándonos en este caso de uso específico, vamos a ver cuál es la solución que puedes implementar.
Ahora, una de las soluciones más simples que uno podría suponer aquí es que se puede aumentar
directamente el tamaño de la base de datos y también aumentar el número de IOPS de provisión para que pueda manejar la carga 20 veces
mayor que está actualmente en curso debido a la promoción de ventas, aunque esto funcionaría, pero hay ciertas
limitaciones aquí.
La primera limitación es que habrá un tiempo de inactividad, por lo que si desea escalar verticalmente esta base de datos,
tendrá que apagar el redimensionamiento y luego iniciar la base de datos de nuevo.
Así que este es un reto específico.
El segundo reto es el aumento de los costes.
Por ejemplo, digamos que ahora ha escalado la base de datos anterior Base de datos tenía dos GB de RAM, ahora
su base de datos tiene 16 GB de RAM y las cosas están funcionando perfectamente bien.
Pero, ¿qué ocurre una vez finalizada la promoción de venta?
Su base de datos de 16 GB estará funcionando todo el tiempo y eso aumentará su coste significativamente.
De acuerdo.
Así que esta es una de las arquitecturas a las que las organizaciones suelen evitar acudir principalmente por
estos problemas.
Así que para superar esto, hay un enfoque mejor en el que se utiliza una cola de mensajes.
Así pues, en este tipo de arquitectura, lo que ocurre es que en lugar de que los mensajes se inserten directamente
en la base de datos, ahora se insertan como parte de la cola ASCS y EC.
Dos instancias extraerán el mensaje de la cola y lo insertarán en la base de datos en función de
la carga.
Digamos que la base de datos ya está soportando una carga muy elevada.
A continuación, los mensajes pueden permanecer en la cola de EE.UU. durante un minuto o dos, por ejemplo, y cuando la carga
de la base de datos aumenta el conjunto de CE, dos instancias pueden tirar del mensaje e insertar los datos de nuevo a la base de datos.
Y este tipo de arquitectura la verás en muchas de las organizaciones.
Ahora, una cosa a tener en cuenta es que en este tipo de arquitectura, habrá un poco de retraso
entre el mensaje que ha sido enviado por el cliente y el mensaje que se inserta en la base de datos.
Así que habrá un pequeño retraso.
Pero para la mayoría de los casos de uso esta vez, el retraso no importa realmente.
Si usted ha cambiado su nombre de perfil en un foro específico y si ese nombre de perfil se actualiza, digamos
después de 2 a 3 minutos, en realidad no importa y así sucesivamente.
Así que hay muchos de los casos de uso en los que no importa.
Pero para los casos de uso en los que el retardo no es aceptable, este tipo de arquitectura es algo que se puede
evitar.
Así que, de nuevo, en los exámenes, dependiendo del caso de uso que te den, puedes seguir adelante y seleccionar la respuesta
adecuada.
Con esto concluiremos el vídeo de hoy.