Ei, pessoal.
E bem-vindo de volta.
Agora, no vídeo de hoje, vamos discutir sobre o papel das filas de mensagens nas transações do banco de dados.
Portanto, vamos em frente e entender isto com um caso de uso.
Portanto, vamos assumir que você tenha um único banco de dados hospedado no RDF.
Agora, devido a uma promoção de vendas em andamento, o número de transações corretas que vem acontecendo no banco
de dados recentemente atingiu dez vezes a carga normal.
Portanto, você tem um grande número de transações corretas que estão acontecendo agora, já que você tem um único
banco de dados que está presente e há uma alta carga, muitos dos pedidos estão falhando regularmente.
E há um requisito mais importante aqui é que as novas promoções de vendas que estão em andamento por causa
das quais há 20 vezes a carga normal, estas promoções de vendas são programadas a cada mês alternado.
Portanto, estes não estão em andamento 24 sete ao longo do mês.
Está ocorrendo a cada mês alternado.
Agora, com base neste caso específico de uso, vamos em frente e analisar qual é a solução que você pode implementar.
Agora, uma das soluções mais simples que se pode assumir aqui é que você pode aumentar diretamente
o tamanho do banco de dados e também aumentar o número de IOPS de provisão para que ele possa lidar com a carga 20 vezes maior
que está atualmente em andamento devido à promoção de vendas, embora isso funcione, mas há certas limitações
aqui.
A primeira limitação é que haverá uma parada, portanto, se você quiser escalar verticalmente este banco de dados, você
terá que fechar o redimensionamento e então iniciar o banco de dados novamente.
Portanto, este é um desafio específico.
O segundo desafio é o aumento dos custos.
Por exemplo, digamos que agora você escalou o banco de dados anteriormente com dois GB de RAM, agora seu
banco de dados tem 16 GB de RAM e as coisas estão funcionando perfeitamente bem.
Mas o que acontece depois que a promoção de venda tiver sido concluída?
Seu banco de dados de 16 GB estará funcionando o tempo todo e isso aumentará significativamente seu custo.
Muito bem.
Portanto, esta é uma das arquiteturas que as organizações geralmente evitam ir principalmente por causa
destes desafios.
Assim, para superar isto, há uma abordagem melhor onde uma fila de mensagens é utilizada.
Assim, neste tipo de arquitetura, o que acontece é que ao invés de mensagens serem inseridas diretamente
no banco de dados, elas agora são inseridas como parte da fila ASCS e CE.
Duas instâncias retirarão a mensagem da fila e a inserirão no banco de dados, dependendo
da carga.
Portanto, digamos que o banco de dados já está passando por uma carga muito alta.
Então as mensagens podem ficar na fila dos EUA por um minuto ou dois, por exemplo, e quando a carga do banco de
dados aumenta o conjunto de CE, duas instâncias podem puxar a mensagem e inserir os dados de volta ao banco de dados.
E este tipo de arquitetura você verá em muitas das organizações.
Agora, uma coisa a se notar é que em tal tipo de arquitetura, haverá um pequeno atraso de tempo
entre a mensagem que foi enviada pelo cliente e a mensagem que é inserida no banco de dados.
Portanto, haverá um pequeno atraso de tempo.
Mas para a maioria dos casos de uso desta vez, o atraso não importa realmente.
Se você mudou seu nome de perfil em um fórum específico e se esse nome de perfil for atualizado, digamos
após 2 a 3 minutos, isso não importa realmente e assim por diante.
Portanto, há muitos dos casos de uso em que isso não importa.
Mas para casos de uso onde o atraso de tempo não é aceitável, então este tipo de arquitetura é algo que você pode
evitar.
Portanto, novamente, nos exames, dependendo do caso de uso que eles dão, você pode ir em frente e selecionar a resposta apropriada.
Assim, com isto, o vídeo de hoje será concluído.