Service Broker no SQL Server 2014

Este artigo apresenta o service broker do SQL Server, um serviço para implementar o processamento assíncrono de mensagens. Através dele é possível ter uma solução para garantir a entrega dos dados de maneira ágil e organizada.

Fique por dentro
A possibilidade de escalar aplicações implementando o processamento de mensagens assíncronas não é algo novo e, nesse cenário, desde o SQL Server 2005 a Microsoft trouxe mais uma alternativa para tornar esse processamento mais eficiente. As vantagens do SQL Broker, em relação aos produtos já existentes no mercado (inclusive produtos não Microsoft), estão relacionadas ao fato de todo o motor de troca de mensagens estar dentro da engine do SQL Server, o que proporciona uma série de ganhos de performance quando aplicado corretamente.

A ideia de um componente arquitetural que permita processar tarefas de forma assíncrona não é nova. Podemos notar esse tipo de solução sendo aplicada no envio de e-mail ou na negociação de ações na bolsa de valores, por exemplo. A Microsoft já possuía soluções de envio de mensagem estabilizadas no mercado quando o SQL Server Broker foi adicionado ao SQL Server 2005 como uma alternativa a ser usada para o processamento assíncrono, tendo como principal diferencial sua implementação dentro da camada de banco de dados.

O service broker proporciona uma troca de mensagens de maneira transacional, permitindo que desenvolvedores criem aplicações distribuídas sem adicionar grande complexidade em seus códigos atuais. Isso é possível devido à arquitetura SODA (Service-Oriented Database Architecture), que permite que a carga de trabalho de um sistema possa ser distribuída em outros servidores e, com isso, aumenta-se a escalabilidade de uma aplicação.

É possível fazer uso de tecnologias de broker em programação assíncrona, como processamentos massivos, limpeza de bases ou quando há a necessidade de executar uma tarefa que o tempo de execução não seja limitado ao período em que o cliente está mantendo uma conexão com o servidor. Isso melhora a percepção do usuário em relação à velocidade de processamento.

Um gerenciador de filas se faz necessário quando é preciso limitar o número de requisições atendidas para que não haja concorrência de recursos com solicitações que já estão em processamento. Nesse caso, a mensagem é enviada para um serviço que irá colocá-la em sua respectiva fila, uma thread disponível irá pegar essa mensagem, processá-la e devolverá o resultado.

Um equívoco comum é achar que vale a pena utilizar uma tabela comum como uma fila. Imagine um sistema com centenas de acessos simultâneos: se controlássemos as filas por uma tabela inevitavelmente esbarraríamos em locks. Já as filas do service broker, por fazerem parte da engine do SQL Server, conseguem resolver problemas de concorrência de maneira mais performática.

Novas terminologias

Configurar um service broker, para quem está fazendo pela primeira vez, pode ser um desafio. Um conjunto de novos termos serão adicionados ao dia a dia do DBA. Alguns desses termos são:

· Dialog Conversation: ponto de início para qualquer troca de mensagens do Service Broker. Antes que uma troca de mensagens possa acontecer, uma conversation precisa ser estabelecida. As mensagens são entregues de maneira EOIO (exacly once in order);

· Conversation Groups: geralmente usado para agrupar conversas relacionadas a uma mesma lógica de negócio. Normalmente é usado para que mensagens diferentes, que possam ser agrupadas por um mesmo grupo de negócio, sejam processadas em ordem;

· Message Types: utilizado para definir qual o tipo de dado a mensagem irá conter;

· Contratos: os contratos definem quais message types podem ser trocados dentro de uma dada conversation;

· " [...] continue lendo...

Artigos relacionados