Usando o SQL Server Service Broker para processamento assíncrono

Usando o SQL Server Service Broker para processamento assíncrono

cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br


Introdução

Na implementação real do SQL Server de um sistema corporativo, ele sempre precisa implementar dados em vários bancos de dados. Na maioria dos casos, uma única transação se estende por vários bancos de dados. Se houver vários bancos de dados, haverá problemas de desempenho e de implementação durante as transações entre bancos de dados. No entanto, com o uso do SQL Service Broker que foi introduzido no SQL Server 2005, você pode implementar transações assíncronas entre bancos de dados.

O que é o Service Broker

O Service Broker é semelhante a outras tecnologias de enfileiramento de mensagens, como o MSMQ. No intermediário de serviço, os dados podem ser processados ​​automaticamente ou sob demanda. Os dados no broker de serviço SQL são consumidos por SEND e RECEIVE, que geralmente é um formato XML.

Um cenário para o Service Broker

Embora existam algumas outras implementações do Service Broker, examinaremos o uso do Service Broker no Sistema de Transações Distribuídas.

Vamos assumir que existe um sistema de pedidos. Quando o pedido é recebido, o estoque deve ser processado. Para manter as questões de escalabilidade e segurança, elas são tratadas por dois processos.

Começaremos ativando o service broker a partir do código a seguir.

No intermediário de serviço, usaremos quatro conceitos principais: Tipo de mensagem, Contrato, Fila e Serviços. A figura a seguir mostra diferentes tipos de objetos no Object Explorer for SQL service broker.

Objetos do SQL Service Broker no SQL Server Management Studio,

No entanto, para criar objetos relevantes do broker de serviço, é necessário usar consultas T-SQL, pois não há interface com o usuário para essas criações de objetos.

Vamos criar um tipo de mensagem. Um tipo de mensagem definirá que tipo de dados você está enviando.

Tipo de mensagem criado acima ReceviedOrders são de propriedade do dbo e a validação é definida como nenhuma. No broker de serviço SQL, pode haver quatro tipos de validações, como NONE, EMPTY, WELL_FORMED_XML e VALID_XML WITH SCHEMA COLLECTION. Na opção NONE, nenhuma validação é feita e normalmente NONE é usado como validação deixada para o consumo.

Leia Também  Pode SELECT * fazer uma consulta ir ... mais rápido?!?

O próximo objeto do broker de serviço que criamos é o CONTRACT. O contrato criará um agrupamento lógico de um ou mais tipos de mensagens. Isso significa que existe uma relação de um para muitos entre o CONTRATO e o TIPO DE MENSAGEM.

No CONTRACT criado acima, ele especificou que as mensagens podem ser enviadas de qualquer terminal. No entanto, se você deseja restringir por motivos de segurança, ainda tem a opção de restringi-lo.

Em seguida, criaremos um objeto importante chamado QUEUE que conterá as mensagens que você está enviando.

Quando o status está definido como OFF, você não pode enviar ou receber mensagens da fila. Outra configuração importante é a opção RETENTION. Se a opção RETENTION estiver desativada, as mensagens serão excluídas da fila. Se você deseja manter as mensagens para fins de auditoria, pode configurá-lo como LIGADO. No entanto, definir RETENTION para ON afetará o desempenho do sistema. Portanto, é recomendável definir a RETENÇÃO em OFF.

O objeto final do SQL Service Broker a ser coberto para o nosso cenário é o SERVICE. O serviço garantirá que as mensagens sejam enviadas e recebidas.

O serviço conterá a fila e o contrato, conforme mostrado no código acima.

Agora vamos ver como você pode ver os objetos criados do SQL Service Broker no SQL Server Management Studio (SSMS).

Agora, configuramos a infraestrutura para filas de mensagens e vamos ver como podemos usá-las. Criaremos uma tabela chamada Pedidos, como mostrado abaixo.

Criaremos um Procedimento armazenado que irá inserir registros na tabela Pedido e enviar a mensagem para a fila definida anteriormente.

No procedimento armazenado acima, o comando SEND é usado para enviar uma mensagem formatada em XML para a fila ReceivedOrders.

Vamos executar esse procedimento armazenado com as seguintes consultas.

Quando a execução acima estiver concluída, você verá três registros na tabela Pedidos.

Tabela de pedidos após a inserção dos registros.

Como enviamos três mensagens para o OrderQueue, podemos verificar essas entradas na consulta a seguir.

O corpo da mensagem não pode ser visualizado, pois é criptografado como mostrado abaixo.

Fila de mensagens na tabela.

Agora vamos consumir a fila do código a seguir.

O código acima pode consumir os dados na fila e processá-los. Com essa abordagem, o processamento assíncrono pode ser feito.

Benefícios adicionais

Além do processamento assíncrono, outros benefícios podem ser alcançados no SQL service broker. Uma das características importantes é que as mensagens estão dentro do banco de dados. Se você fizer backup e restaurar o banco de dados, as mensagens das filas serão mantidas.

Além disso, no SQL Server, o correio do banco de dados usa o recurso SQL service broker.

Conclusão

O SQL Server Service Broker é um componente importante da família SQL Server que pode ser usado para várias atividades. Neste artigo, foi explicado como o SQL service broker foi usado para processamento assíncrono usando MESSAGE TYPE, CONTRACT, QUEUE e SERVICES.

Dinesh Asanka
Últimas mensagens de Dinesh Asanka (ver todos)

cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br