DEV Community: Larissa Tavares

Conhecendo sobre o protocolo HTTP

Larissa Tavares — Sat, 14 Sep 2024 13:47:46 +0000

Primeiramente precisamos entender que o protocolo HTTP está presente na camada de aplicação do modelo OSI, ela é a única camada que interage diretamente com os dados do usuário

Modelo OSI (Open System Interconnection) : modelo que oferece um padrão para que diferentes sistemas de computadores possam se comunicar

O que é HTTP?

Bom, o HTTP é um protocolo ou seja, um conjunto de regras, estabelecido para organizar a maneira como os computadores trocam dados entre si
HTTP significa Hypertext Transfer Protocol (Protocolo de transferência de hipertexto). Um conjunto de regras que permite passar com todos os detalhes dados como texto, imagem, vídeos e áudios entre dispositivos
Suas versões rodam sobre o TCP, e a sua versão mais atual, o HTTP/3 também roda sobre UDP
Os cabeçalhos de solicitação e resposta são dados em ASCII

HTTP e HTTPS

Já ouvimos falar que existem esses dois protocolos, mas qual a diferença entre eles?

O HTTP e o HTTPS recuperam os dados da mesma maneira. A diferença é que o protocolo HTTP quando utiliza um protocolo de transporte seguro, chamado TLS (Transport Layer Security), constitui o que conhecemos como HTTPS

Como funciona?

A comunicação funciona em duas pontas, a partir da solicitação (requisição) no lado do usuário (cliente) para o lado o servidor web, e uma resposta se referindo à ação do servidor

Elementos da requisição

Compostos por:

Método HTTP
Caminho do recurso a ser buscado
Versão do protocolo HTTP
Cabeçalho (header)
Corpo (body)

Elementos das respostas

Compostos por:

Versão do protocolo HTTP
Código de status
Mensagem de status
Cabeçalho (header)
Corpo (body)

Cabeçalho / Header

Os cabeçalhos contém informações básicas como tipo de conteúdo, idioma, conjunto de caracteres, entre outros

Abaixo temos uma lista de alguns dos cabeçalhos de uma requisição HTTP

Accept-Language : Determina qual linguagem é entendida pelo cliente e qual a sua região de preferência
Allow : Lista quais métodos HTTP são aceitos pelo servidor para o recurso acessado
Content-Language : É a forma do servidor dizer ao cliente quais linguagens estão disponíveis para o recurso atual
Cookie : Contém o valor de um Cookie HTTP e é a forma do navegador enviar esse dado de volta ao servidor a cada requisição
Content-Type : Indica qual o tipo de mídia de um recurso
User-Agent : Contém uma string de identificação da aplicação, sistema operacional e distribuidor do software que fez a requisição

Corpo / Body

É a resposta àquela solicitação. No HTTP, pode ser desde um simples texto, a um hipertexto (HTML), um arquivo PDF, uma imagem, JSON, XML etc

Métodos HTTP

Os métodos indicam ações que a solicitação HTTP espera de um determinado servidor consultado
Cada método estipula uma operação diferente

Existem nove métodos HTTP, são eles

GET
Solicita o envio de um recurso específico. Requisições utilizando este método retornam apenas dados
HEAD
Solicita apenas o cabeçalho da mensagem, sem conter o corpo da mensagem
POST
Submete uma entidade a um recurso específico, geralmente causando uma mudança no estado do recurso. Faz o upload de dados para um servidor
PUT
Substitui a representação atual do destino pela carga de dados da requisição
DELETE
Exclui um recurso específico
TRACE
Serve para depuração, ele instrui o servidor a enviar de volta a solicitação. É útil quando a solicitação não está sendo processada corretamente, e o cliente deseja saber qual solicitação o servidor recebeu
CONNECT
Estabelece uma conexão com o servidor através de um dispositivo intermediário. Exemplo: cache web
OPTIONS
Fornece um meio para que o cliente consulte o servidor e obtenha os métodos e cabeçalhos que podem ser usados
PATCH
Utilizado para aplicar modificações parciais em um recurso

Códigos de status de resposta HTTP

Toda solicitação obtém uma resposta que contém uma linha de status e as informações adicionais da página
A linha de status possui um código de três dígitos informando se a solicitação foi atendida, se não e porque não
O primeiro dígito serve para dividir a resposta em cinco grupos importantes

Grupos

Código	Significado
1xx	Informação
2xx	Sucesso
3xx	Redirecionamento
4xx	Erro do cliente
5xx	Erro do servidor

Alguns exemplos de códigos de status

Código	Descrição
100 Continue	Indica que o cliente deve continuar a solicitação ou ignorar a resposta se a solicitação já estiver concluída
102 Processing	Indica que o servidor recebeu e está processando a requisição, mas nenhuma resposta está disponível ainda
200 Ok	Indica que a solicitação foi bem sucedida
201 Created	A requisição foi bem sucedida e um novo recurso foi criado como resultado. Normalmente utilizado após requisições POST ou PUT
202 Accepted	A solicitação foi recebida mas ainda não foi atendida, nesse caso não será enviado nenhuma resposta posteriormente de forma assíncrona. É utilizado em casos em que outro processo ou servidor manipula a solicitação
300 Multiple Choices	A solicitação tem mais de uma resposta possível, e o usuário deve escolher um deles
301 Moved Permanently	A URL do recurso solicitado foi movido permanentemente, a nova URL é enviada na resposta
302 Found	Significa que a URI do recurso foi alterada temporariamente, mas que essa mesma URI deve ser usada para requisições no futuro
400 Bad Request	O servidor não pode processar a requisição devido a um erro do cliente
401 Unauthorized	Significa que o cliente deve se autenticar para obter a resposta desejada
403 Forbidden	O cliente não tem direitos de acesso ao conteúdo, diferente do 401, aqui a identidade do cliente é conhecida
404 Not Found	Indica que o servidor não pode encontrar o recurso solicitado
418 I'm a Teapot	O servidor se recusa a preparar café com um bule de chá
429 Too Many Requests	O cliente enviou muitas requisições em um dado tempo
500 Internal Server Error	O servidor encontrou uma condição inesperada que o impediu de atender a solicitação
501 Not Implemented	O servidor não reconhece o método de solicitação e não é capaz de suportá-lo para nenhum recurso
502 Bad Gateway	Ao atuar como gateway ou proxy, o servidor recebeu uma resposta inválida de um servidor de entrada que ele acessou ao tentar atender à solicitação

Versões do HTTP

HTTP/1.0

A conexão entre um navegador e um servidor, habitualmente é feita através da conexão TCP
No HTTP/1.0 depois que a conexão era estabelecida, uma única solicitação era enviada e uma única resposta era devolvida, e a conexão TCP era encerrada
Porém como as páginas Web continham grandes números de links, imagens e ícones, o estabelecimento de uma única conexão TCP para transportar um único ícone se tornou muito custoso, com isso surgiu o HTTP/1.1

HTTP/1.1

Com essa versão foram admitidas conexões persistentes
Assim é possível estabelecer uma conexão TCP, enviar uma solicitação e obter uma resposta, e depois enviar solicitações adicionais e receber respostas adicionais
Também é chamado de reúso de conexão

HTTP/2.0

Melhorias de desempenhos
No HTTP/2, uma conexão TCP é estabelecida e muitas solicitações podem ser enviadas e o servidor pode responder a elas em qualquer ordem que desejar
Através de um mecanismo chamado server push, o HTTP/2 permite que o servidor envie arquivos que ele já sabe serem necessários, mas que o cliente pode não saber inicialmente
As respostas podem retornar em qualquer ordem
O HTTP/2 compacta os cabeçalhos e os envia em binário para reduzir o uso da largura de banda e a latência

HTTP/3.0

Sua principal diferença é o protocolo de transporte usado para dar suporte às mensagens HTTP: em vez de depender do TCP, ele depende de uma versão aumentada do UDP chamada QUIC, que conta com o controle de congestionamento do espaço do usuário executado em cima do UDP

Referências
Códigos de Status HTTP
TANENBAUM, A.S. Redes de Computadores. 1988.
Diving into the HTTP

Conceitos básicos de MongoDB utilizando C#/.NET | Fazendo seu primeiro CRUD

Larissa Tavares — Mon, 04 Dec 2023 01:45:45 +0000

O MongoDB é um banco de dados não relacional, também chamado de NoSQL. É orientado a documentos, os quais podem ser descritos com dados no formato chave-valor utilizando o formato JSON (JavaScript Object Notation).

Os bancos de dados NoSQL, diferente dos bancos relacionais, não utilizam os esquemas de organização por meio de tabelas, linhas e colunas. E apresentam algumas vantagens como escalabilidade, flexibilidade, bom desempenho e facilidade para consultas.

Driver MongoDB C#

Neste exemplo criaremos uma API Web que fará as operações de CRUD (criar, ler, atualizar e deletar) no banco de dados NoSQL MongoDB.

Modelo de configuração

[Estação de trabalho] Instalar o MongoDB utilizando Docker: MongoDb Docker
[Código] Adicionar a dependência do pacote NuGet do MongoDB: MongoDB.Driver.
[Código] Inicialmente adicionaremos os valores de conexão do banco de dados no arquivo de configurações denominando appsettings.json. Passando informações como a string de conexão (ConnectionString), o banco de dados (DatabaseName) e a coleção (CollectionName) que iremos acessar no MongoDB.

appsettings.json

{
    "MongoDatabase": {
        "ConnectionString": "mongodb://localhost:27017",
        "DatabaseName": "BookStore",
        "CollectionName": "Books"
    },
    "Logging": {
        "LogLevel": {
            "Default": "Information",
            "Microsoft.AspNetCore": "Warning"
        }
    },
    "AllowedHosts": "*"
}

[Código] Agora criaremos uma classe denominada DatabaseSettings que irá conter os parâmetros equivalentes aos que criamos no appsettings.json. Esta classe irá armazenar os valores de propriedade do appsettings.json.

public class DatabaseSettings
{
    public string ConnectionString { get; set; } = null!;

    public string DatabaseName { get; set; } = null!;

    public string CollectionName { get; set; } = null!;
}

[Código] No Program.cs adicionaremos a linha a seguir. A instância de configuração da seção MongoDatabase presente no arquivo appsettings.json é registrada no contêiner de injeção de dependência.

...
builder.Services.Configure<DatabaseSettings>(
    builder.Configuration.GetSection("MongoDatabase"));

Em outras palavras, a propriedade ConnectionString de um objeto do tipo DatabaseSettings será populada com a propriedade MongoDatabase:ConnectionString do appsettings.json.

Modelo de entidade

[Código] A seguir criaremos nosso modelo de entidade que utilizaremos em todas as operações do CRUD.

public class Book
{
    [BsonId]
    [BsonRepresentation(BsonType.ObjectId)]
    public string? Id { get; set; }

    [BsonElement("Name")]
    public string BookName { get; set; } = null!;

    public decimal Price { get; set; }

    public string Category { get; set; } = null!;

    public string Author { get; set; } = null!;
}

Descrição das annotations:
[BsonId]: Designa a propriedade Id como chave primária.
[BsonRepresentation(BsonType.ObjectId)]: Permite a passagem do parâmetro como tipo string em vez de uma estrutura ObjectId. O MongoDB processa a conversão de string para ObjectId.
[BsonElement("Name")]: O valor Namedo atributo [BsonElement] representa o nome da propriedade da coleção do MongoDB.

Adicionando o serviço de operações CRUD

[Código]: Criar uma classe de serviço denominada BooksService.

      public class BooksService
   {
       private readonly IMongoCollection<Book> _booksCollection;

       public BooksService(IOptions<DatabaseSettings> bookStoreDatabaseSettings)
       {
           var mongoClient = new MongoClient(
               bookStoreDatabaseSettings.Value.ConnectionString);

           var mongoDatabase = mongoClient.GetDatabase(
               bookStoreDatabaseSettings.Value.DatabaseName);

           _booksCollection = mongoDatabase.GetCollection<Book>(
               bookStoreDatabaseSettings.Value.CollectionName);
       }
   ...

No código acima temos nossa classe BooksService e seu construtor. Uma instância do DatabaseSettings é recuperada da injeção de dependência pela injeção do construtor. Utilizamos a interface IOptions pois já está registrado como Singleton e pode ser injetado em qualquer vida útil do serviço.

Em cenários onde as opções devem ser recalculadas a cada solicitação, podemos utilizar o IOptionsSnapshot. Sendo este registrado como Scoped.

Esta técnica fornece acesso para os valores de configuração do appsettings.json, que foi configurado no início deste artigo.

[Código]: Agora no Program adicionaremos a linha subsequente.

...
builder.Services.AddSingleton<BooksService>();

Neste trecho a classe BooksService é registrada com a injeção de dependência para dar suporte à injeção de construtor nas classes consumidoras.

O tempo de vida Singleton é o mais apropriado pois a classe BooksService utiliza uma dependência direta de MongoClient e de acordo com as diretrizes oficiais do MongoDB, recomenda-se armazenar uma instância do MongoClient com o tipo de vida útil Singleton.

Singleton significa que um objeto do serviço é criado e fornecido para todas as requisições. Assim, todas as requisições obtém o mesmo objeto.

Voltando à classe BooksService, utilizamos os seguintes membros do MongoDB.Driver.

var mongoClient = new MongoClient(
        bookStoreDatabaseSettings.Value.ConnectionString);

var mongoDatabase = mongoClient.GetDatabase(
    bookStoreDatabaseSettings.Value.DatabaseName);

_booksCollection = mongoDatabase.GetCollection<Book>(
    bookStoreDatabaseSettings.Value.CollectionName);

MongoClient lê a instância do servidor para executar operações de banco de dados e espera uma string de conexão como parâmetro.

Após o MongoClient se conectar a uma instância do MongoDB, o método GetDatabase é utilizado para acessar um banco de dados.

Já o método GetCollection é utilizado para acessar uma coleção. Na chamada para o GetCollection<TDocument>(collection) temos o TDocument sendo o tipo de objeto armazenado na coleção e o collection representando o nome da coleção.

[Código]: Adicionaremos os seguintes métodos na nossa classe BooksService.

public class BooksService
{
 ...
    public async Task<List<Book>> GetAsync() =>
    await _booksCollection.Find(_ => true).ToListAsync();

    public async Task<Book?> GetAsync(string id) =>
        await _booksCollection.Find(x => x.Id == id).FirstOrDefaultAsync();

    public async Task CreateAsync(Book newBook) =>
        await _booksCollection.InsertOneAsync(newBook);

    public async Task UpdateAsync(string id, Book updatedBook) =>
        await _booksCollection.ReplaceOneAsync(x => x.Id == id, updatedBook);

    public async Task RemoveAsync(string id) =>
        await _booksCollection.DeleteOneAsync(x => x.Id == id);
}

Os seguintes métodos são acessados nesta classe:
Find: retorna todos os documentos na coleção que correspondem aos critérios de pesquisa fornecidos.
InsertOneAsync: insere o objeto fornecido como um novo documento na coleção.
ReplaceOneAsync: substitui o único documento que corresponde aos critérios de pesquisa fornecidos com o objeto fornecido.
DeleteOneAsync: exclui um único documento que corresponde aos critérios de pesquisa fornecidos.

Outros métodos que podem ser utilizados estão listados no link IMongoCollectionExtensions Methods.

Adicionar um controller

[Código]: No nosso último passo iremos adicionar um controlador utilizando o seguinte código.

Neste trecho temos métodos de ação GET, POST, PUT e DELETE, que darão suporte às nossas solicitações.

 [ApiController]
 [Route("api/[controller]")]
 public class BooksController : ControllerBase
 {
     private readonly BooksService _booksService;

     public BooksController(BooksService booksService) =>
         _booksService = booksService;

     [ProducesResponseType(404)]
     [ProducesResponseType(200)]
     [HttpGet]
     public async Task<List<Book>> Get() =>
     await _booksService.GetAsync();

     [ProducesResponseType(404)]
     [ProducesResponseType(200)]
     [HttpGet("{id:length(24)}")]
     public async Task<ActionResult<Book>> Get(string id)
     {
         var book = await _booksService.GetAsync(id);

         if (book is null)
         {
             return NotFound();
         }

         return book;
     }

     [ProducesResponseType(404)]
     [ProducesResponseType(200)]
     [HttpPost]
     public async Task<IActionResult> Post(Book newBook)
     {
         await _booksService.CreateAsync(newBook);

         return CreatedAtAction(nameof(Get), new { id = newBook.Id }, newBook);
     }

     [ProducesResponseType(404)]
     [ProducesResponseType(200)]
     [HttpPut("{id:length(24)}")]
     public async Task<IActionResult> Update(string id, Book updatedBook)
     {
         var book = await _booksService.GetAsync(id);

         if (book is null)
         {
             return NotFound();
         }

         updatedBook.Id = book.Id;

         await _booksService.UpdateAsync(id, updatedBook);

         return NoContent();
     }

     [ProducesResponseType(404)]
     [ProducesResponseType(200)]
     [HttpDelete("{id:length(24)}")]
     public async Task<IActionResult> Delete(string id)
     {
         var book = await _booksService.GetAsync(id);

         if (book is null)
         {
             return NotFound();
         }

         await _booksService.RemoveAsync(id);

         return NoContent();
     }
 }

Após isso, iremos adicionar a chamada do método AddControllers e para o método MapControllers no nosso Program

...
builder.Services.AddControllers()
    .AddJsonOptions(
        options => options.JsonSerializerOptions.PropertyNamingPolicy = null);
...
app.MapControllers();

Com a alteração AddJsonOptions anterior, os nomes de propriedade na resposta JSON serializada da API Web correspondem aos respectivos nomes de propriedade no tipo de objeto.

Ferramentas utilizadas

Pacote Nuget: MongoDB.Driver
Linguagem: C# .NET 8.0

Código no GitHub

Larissa Tavares - MongoDBSolutions

Com isso finalizamos nossos entendimentos iniciais acerca de MongoDB e sobre como configurá-lo de maneira adequada. Além de termos bastante aparato teórico para entender muito sobre o nosso código. O código final está disponível no GitHub e seu link está disponível acima. Abraços!

Referências
Treinaweb - O que é MongoDB?
Microsoft Learn - Criar uma API Web com o ASP.NET Core e o MongoDB
MongoDB - Connection String
MongoDB - Databases and Collections
MongoDB - IMongoCollectionExtensions Methods

Trabalhando com Queues (Filas) no RabbitMQ utilizando C#/.NET

Larissa Tavares — Wed, 15 Nov 2023 18:33:56 +0000

Neste exemplo criaremos uma fila de trabalho responsável por distribuir tarefas demoradas entre seus consumidores. Um consumidor atarefado só irá receber outra mensagem após informar que está livre.

Caso você esteja começando agora com RabbitMQ, sugiro que inicie por este artigo: Conceitos iniciais sobre RabbitMQ utilizando C#/.NET

Despacho Round-Robin

Ao utilizar as filas de tarefas (Task Queues) pode-se facilmente balancear as cargas de trabalho. Se houver muito acúmulo de trabalho, podemos adicionar mais consumidores/trabalhadores e assim melhorar a escalabilidade e garantir a disponibilidade, especialmente em sistemas distribuídos e em cenários onde o processamento de tarefas pode ser demorado.

Por padrão o RabbitMQ enviará em sequência as mensagens para cada consumidor. Em média cada consumidor receberá a mesma quantidade de mensagens. Esta forma de distribuição de mensagens é denominada Round-Robin.

Problemática

Porém existe uma problemática em cima desta forma de distribuição de mensagens. Existem cenários em que um consumidor inicia uma tarefa longa e morre com ela, deixando a tarefa parcialmente concluída. Neste cenário, após enviar a mensagem para um consumidor, o RabbitMQ a marca imediatamente para exclusão, fazendo com que a mensagem seja perdida caso o consumidor/trabalhador seja encerrado.

Confirmação de mensagem

Para que uma mensagem não seja perdida, o RabbitMQ possui um reconhecimento/confirmação de mensagens. Caso um consumidor morra sem enviar uma confirmação, o RabbitMQ irá entender que a mensagem não foi totalmente processada e a colocará novamente na fila. Se houver outro consumidor online, ele enviará rapidamente ao outro consumidor. Dessa forma, nenhuma mensagem é perdida.

Para confirmar manualmente as mensagens, desativaremos o parâmetro de reconhecimento automático AutoAck.

Colocaremos o AutoAck como falso no BasicConsume e adicionaremos uma chamada para o BasicAck.

CONSUMIDOR:

...
channel.BasicAck(deliveryTag: ea.DeliveryTag, multiple: false);
                };

channel.BasicConsume(queue: "payments-queue",
                     autoAck: false,
                     consumer: consumer);

Com isso podemos garantir que mesmo encerrando um nó de trabalho enquanto ele processava uma mensagem, nada será perdido.

Durabilidade da mensagem

Mesmo garantindo que a mensagem não seja perdida caso o consumidor morra, se o servidor do RabbitMQ morrer as tarefas ainda serão perdidas.

Para que o RabbitMQ não esqueça as filas e mensagens caso seja parado, devemos marcar as filas e mensagens como duráveis.

Precisamos ter certeza que a fila sobreviverá à reinicialização do nó do RabbitMQ. Para isso a declaramos como durável (durable: true).

CONSUMIDOR E PRODUTOR:

...
channel.QueueDeclare(queue: "payments-queue",
                     durable: true,
                     exclusive: false,
                     autoDelete: false,
                     arguments: null);

Esta alteração deverá ser realizada tanto no consumidor (consumer) quanto no produtor (producer).

Agora, precisamos marcar nossas mensagens como persistentes. No produtor, após o GetBytes iremos definir o IBasicProperties.Persistent como true.

PRODUTOR:

...
 var body = Encoding.UTF8.GetBytes(message);

 var properties = channel.CreateBasicProperties();
 properties.Persistent = true;

Marcar as mensagens como persistentes irá informar ao RabbitMQ para gravar as mensagens no disco.

Despacho justo

Em uma situação onde temos dois consumidores, quando todas as mensagens pares são pesadas e as mensagens ímpares são leves, consequentemente um deles estará constantemente ocupado e o outro estará mais livre.

Normalmente o RabbitMQ não saberá sobre essa situação e continuará enviando as mensagens de forma uniforme. Ele não analisa o número de mensagens não confirmadas de um consumidor, ele apenas despacha a mensagem n para o conumidor n.

Para corrigir este problema, devemos utilizar do método BasicQos(Qos = Quality of Service) com a configuração prefetchCount = 1. Isso diz ao RabbitMQ para não fornecer mais de uma mensagem para um consumidor sem que antes este informe que já processou e confirmou a anterior. Ao invés disso ele irá despachar a mensagem para o próximo consumidor que esteja disponível.

Iremos adicionar o BasicQos após o QueueDeclare no código do consumidor.

CONSUMIDOR:

...
channel.QueueDeclare(queue: "payments-queue",
                     durable: true,
                     exclusive: false,
                     autoDelete: false,
                     arguments: null);

channel.BasicQos(prefetchSize: 0, prefetchCount: 1, global: false);

Na prática:

- SEM AS CONFIGURAÇÕES

Na imagem seguinte temos os consoles de um produtor e de dois consumidores, sendo que o código não está com nenhuma das configurações abordadas neste artigo.

Na imagem, podemos ver que o produtor envia sequencialmente as mensagens para os consumidores, que as recebem de forma uniforme, sendo que o consumidor 1 está recebendo as mensagens ímpares e o consumidor 2 as mensagens pares.

Neste cenário o consumidor 1 está com bastante disponibilidade e o consumidor 2 está bastante atarefado, logo vemos que o consumidor 2 está ainda na mensagem 36 e processando a 38, com dezenas de mensagens na sua fila aguardando para serem processadas. Enquanto que o consumidor 1 está equivalente com o produtor, sempre processando a última mensagem enviada.

- COM AS CONFIGURAÇÕES

A próxima imagem tem o mesmo consoles do produtor e dos consumidores, porém agora com todas as configurações abordadas neste artigo. Sendo elas o AutoAck, durable: true e BasicQos.

Neste cenário o consumidor 2 não está mais consumindo somente as mensagens pares, assim como o consumidor 1 não está mais consumindo somente as ímpares.

Os dois estão informando ao RabbitMQ quando estão disponíveis para consumir a próxima mensagem. E assim o RabbitMQ encaminha de forma equilibrada as mensagens para cada consumidor.

Vemos que o consumidor 2 continua atarefado, porém agora ele só recebe uma nova mensagem após processar a anterior.

Ferramentas utilizadas

Pacote Nuget: RabbitMQ.Client
Linguagem: C# .NET 6.0

Código no GitHub

Larissa Tavares - RabbitMQSolutions

Assim finalizamos nossos entendimentos acerca das queues e como podemos configurá-las de forma a manter a disponibilidade e persistência de nossas mensagens, de forma a não sobrecarregar nossos consumidores. O código final está disponível no GitHub e seu link está disponível acima.

Referências
RabbitMQ - Work Queues using the .NET Client
RabbitMQ - Consumer Prefetch

Conceitos iniciais sobre RabbitMQ utilizando C#/.NET

Larissa Tavares — Sat, 21 Oct 2023 23:04:47 +0000

O RabbitMQ é um message broker, pois aceita e encaminha mensagens.

Um message broker é um software que possibilita que aplicativos, sistemas e serviços se comuniquem e troquem informações.

Alguns termos a se compreender

Produtor (Producer): É um programa que envia mensagens.
Consumidor (Consumer): É um programa que espera por mensagens.
Fila (Queue): É a caixa postal do RabbitMQ. É um local de armazenamento, que recebe uma mensagem de uma central de troca e as envia aos consumidores.
Troca (Exchange): É quem recebe as mensagens do produtor e determina para onde elas devem ser encaminhadas.
Vinculação (Binding): É o relacionamento entre uma exchange e uma queue.

Protocolos de comunicação

São responsáveis pela operação do message broker e de como será feito o envio e recebimento de mensagens entre os clientes.

AMQP (Advanced Messaging Queue Protocol)

O modelo AMQP tem a seguinte proposta: Um produtor publica mensagens em uma exchange, que distribui cópias dessas mensagens para queues utilizando as regras denominadas bindings. Em seguida o broker entrega as mensagens aos consumidores inscritos na fila.

MQTT (Message Queue Telemetry Transport)

É um protocolo para troca de mensagens em ambientes onde existe alguma restrição de hardware, como pouca memória disponível, por exemplo, ou uma limitação de banda. Enfatiza mensagens leves de publicação/assinatura, direcionado a clientes em dispositivos restritos.

STOMP (Simple (or Streaming) Text Oriented Message Protocol)

É um protocolo baseado em texto, construído para trabalhar com middlewares orientados à mensagem. Possui uma estrutura similar ao AMQP, com cabeçalho, propriedades e corpo da mensagem, porém não lida com tópicos ou filas. Ele usa uma semântica de string de destino.

Persistência no RabbitMQ
No RabbitMQ existem dois tipos de fila: as duráveis e as não duráveis. As filas duráveis fazem com que as mensagens permaneçam no disco, enquanto uma fila não durável permanece apenas na memória. Portanto, após a reinicialização do servidor as mensagens nas filas duráveis ficam disponíveis, enquanto as mensagens nas filas não duráveis são perdidas.

Client .NET/C#

Neste exemplo será criado um produtor que envia uma mensagem e um consumidor que recebe as mensagens e as imprime no console.

Passos

[Estação de trabalho] Instalar o RabbitMQ: Downloading and Installing RabbitMQ
[Código] Adicionar a dependência do pacote NuGet do RabbitMQ: RabbitMQ .NET Client.
[Código] Criar uma conexão com o servidor. Esta conexão será usada tanto para o produtor quanto para o consumidor.

var factory = new ConnectionFactory { HostName = "localhost" };
using var connection = factory.CreateConnection();
using var channel = connection.CreateModel();

PRODUTOR

[Código] Declarar uma fila para enviar a mensagem com QueueDeclare e publicar uma mensagem na fila com BasicPublish.

using System.Text;
using RabbitMQ.Client;

var factory = new ConnectionFactory { HostName = "localhost" };
using var connection = factory.CreateConnection();
using var channel = connection.CreateModel();

channel.QueueDeclare(queue: "hello",
                     durable: false,
                     exclusive: false,
                     autoDelete: false,
                     arguments: null);

const string message = "Hello World!";
var body = Encoding.UTF8.GetBytes(message);

channel.BasicPublish(exchange: string.Empty,
                     routingKey: "hello",
                     basicProperties: null,
                     body: body);
Console.WriteLine($" [x] Sent {message}");

Console.WriteLine(" Press [enter] to exit.");
Console.ReadLine();

CONSUMIDOR

[Código] Declarar a fila da qual será consumida as mensagens com QueueDeclare, adicionar uma manipulador de eventos denominado EventingBasicConsumer e consumir a mensagem com BasicConsume.

using System.Text;
using RabbitMQ.Client;
using RabbitMQ.Client.Events;

var factory = new ConnectionFactory { HostName = "localhost" };
using var connection = factory.CreateConnection();
using var channel = connection.CreateModel();

channel.QueueDeclare(queue: "hello",
                     durable: false,
                     exclusive: false,
                     autoDelete: false,
                     arguments: null);

Console.WriteLine(" [*] Waiting for messages.");

var consumer = new EventingBasicConsumer(channel);
consumer.Received += (model, ea) =>
{
    var body = ea.Body.ToArray();
    var message = Encoding.UTF8.GetString(body);
    Console.WriteLine($" [x] Received {message}");
};
channel.BasicConsume(queue: "hello",
                     autoAck: true,
                     consumer: consumer);

Console.WriteLine(" Press [enter] to exit.");
Console.ReadLine();

Ferramentas utilizadas

Pacote Nuget: RabbitMQ.Client
Linguagem: C# .NET 6.0

Código no GitHub

Larissa Tavares - RabbitMQClient

Com isso finalizamos nossos entendimentos iniciais acerca do RabbitMQ. Para aqueles que estão começando agora no ramo da mensageria este post lhe dá um direcionamento inicial. Abaixo seguem as referências de artigos utilizados e cursos recomendados.

Referências
RabbitMQ - "Olá Mundo" usando o cliente .NET/C#
RabbitMQ - Modelo AMQP 0-9-1 explicado
InfoWorld - How to work with RabbitMQ in C#
AWS - Abordagem arquitetônica do RabbitMQ