Je crée une application de mailer de masse, dans laquelle une application Web définit un modèle de messagerie, puis files d'attente un tas d'adresse électronique pour l'envoi. L'autre côté sera un service Windows (ou EXE) qui sondera cette file d'attente, ramassant les messages à envoyer.
Ma question est que l'avantage serait d'utiliser SQL Service Broker (ou MSMQ) sur la création de ma propre table de file d'attente personnalisée?
Tout ce que je lis, c'est suggérant que j'utilise le courtier de service, mais je ne vois vraiment pas ce que l'énorme avantage sur une table plate (ce serait beaucoup plus simple à travailler avec pour moi). Pour référence, l'application sera utilisée pour envoyer 50 000-100 000 courriels presque tous les jours.
4 Réponses :
Pour avantages du courtier de service, voir ce lien:
http://msdn.microsoft.com/en-us/library /ms166063.cox
En général, nous essayons d'utiliser un outil ou une fonctionnalité standard plutôt que de créer des choses nous-mêmes. Cela abaisse le coût et peut faciliter la mise à niveau.
Merci, j'ai déjà lu cet article. Ma question est que, dans mon cas, ces avantages sont suffisamment énumérés de la courbe d'apprentissage et de la complexité supplémentaires. Ma table personnalisée serait très simple et cela viendrait fondamentalement à 3 déclarations. Pseudocode: Insert dans la file d'attente Sélectionnez * à partir de la file d'attente où terminé = False Update File d'attente Terminé = True
Sans courtier de service, vous devez faire attention au filetage. Basé sur votre code Que se passera-t-il si de nouvelles lignes sont ajoutées après la sélection mais avant la mise à jour. Si votre code s'écrase des courriels sera envoyé deux fois?
Est-ce que vous savez Comment implémenter une file d'attente sur une table plate? Ce n'est pas une question idiote, mettant en œuvre une file d'attente sur une table correctement est beaucoup plus difficile qu'elle ne sonne. Les tables d'attente de la file d'attente sont notoirement sujets à impasse et vous devez considérer avec soin la conception de la table et les opérations Enqueue et Dequue. Aussi, savez-vous comment augmenter votre communication de la table? Et comment allez-vous gérer les tentatives et les délais d'attente (c'est-à-dire que minuterie sont utilisés pour)?
Je ne dis pas que vous devriez utiliser SSB. La courbe au-delà est très raide et est principalement une plate-forme applicaire distribuée, pas un produit de file d'attente local, de sorte que certaines fonctionnalités, telles que des dialogues, seront effectivement des obstacles pour vous plutôt que des avantages. Je dis simplement que vous devez également considérer les difficultés de files d'attente de table à plat. Si vous n'avez jamais mis en place une file d'attente à plat, alors soyez avertis, de nombreux dragons sont sous ce pont.
messages de 50k-100k par jour n'est rien, c'est un seul message par seconde. Si vous voulez 100k par minute , nous avons quelque chose à parler.
Merci pour la réponse. Je savais que j'aurais beaucoup pour faire face à la route que j'ai prise. Avez-vous des articles ou des échantillons d'applications qui pourraient me faire pointer dans la bonne direction? Partout où je cherche, je continue à avoir plus de questions et moins sûre de ce que je fais.
Malheureusement je ne le fais pas. Je m'étais recherché de tels articles dans le passé aux sources les plus fiables (blogs MVP, SQLServerPedia, SQLMAG, etc.), mais je n'ai pas trouvé d'article de résumé. Quelques conseils que j'ai de ma propre expérience: Dirigez-vous de quelque chose de fantaisie (comme des priorités comme des priorités), essayez d'obtenir la FIFO Enqueue / Dequeue Droite (pas de blocage et sans correspondage). Assurez-vous également d'utiliser la file d'attente pour événements , pas pour l'état. C'est à dire. EnQUEUE La 'Demande d'envoi de cet email', pas l'e-mail lui-même.
Les bus de service tels que Rebus ou Nservicebus ont SQLTRANSPORT qui est la mise en œuvre de la file d'attente sur une table
@RemusRUSANU Considérez-vous cette réponse à être toujours valable compte tenu de votre message Tables comme files d'attente
Je serais plus intéressé à souligner que si vous voulez simplement utiliser une file d'attente SSB comme une simple file d'attente, vous pouvez simplement réutiliser la même conversation pour chaque message et ne jamais émettre une conversation finale. Cela fonctionnera à trouver, soyez assez rapide et il est toujours intégré à votre base de données. (Et l'activation interne / externe est géniale.)
Comme vous semblez avoir un seul lecteur et une écriture de votre file d'attente, j'aurais tendance à utiliser une table standard jusqu'à ce que vous touchiez problème. Toutefois, si vous commencez à ressentir la nécessité d'utiliser des "allembles de verrouillage", etc., que le temps de passer aux files d'attente de courtiers de service.
Je n'utiliserais pas MSMQ, si l'expéditeur et le lecteur ont besoin d'une connexion de base de données au travail. MSMQ serait bon si l'expéditeur ne parlait pas du tout à la base de données, car elle permet à l'expéditeur continuer à fonctionner lorsque la base de données est en panne. Cependant, avoir à configurer et à maintenir à la fois le MSMQ et la base de données est susceptible d'être plus de travail que cela vaut la plupart des systèmes.
Merci. Je pense que je vais (très soigneusement) d'essai avec une table à plat et de voir comment cela fonctionne comme ce sera le plus rapide à mettre en œuvre. Si je trouve que ce n'est pas à la hauteur, je vais passer au courtier en service.
Je sais que c'est une question ancienne, mais est suffisamment résumé pour être pertinente pour suffisamment longtemps.
Après avoir utilisé les deux paradigmes, je suggérerais une table à plat. Il est étonnamment évolutif et astucieux. Les astuces correctes doivent être utilisées.
Une fois que l'application est distribuée ou commence à utiliser SteiTle Allways sur des groupes avec différents serveurs RW et RO, le courtier de service (ou toute autre méthode de communication distribuée) devient une nécessité.