MSMQ vs vidage temporaire de la table

Question

Je sais que cette question a déjà été posée un peu plus tôt. Mais en regardant autour de moi, je ne peux toujours pas décider de la route à suivre. Voici mon scénario, j'espère que vous pourrez aider:

Nous aurons une série de services Web qui seront exploités de manière programmée par des centaines d'applications mobiles. Ces services vont transférer des données sur l'appareil avec de nouvelles informations à la fois pour les appareils et pour en revenir. Les données renvoyées par les périphériques devront mettre à jour une seule base de données SQL Server centrale qui alimente également plusieurs applications de bureau et un site Web.

Afin de réduire le temps de requête / réponse de ces services, nous avons décidé de traiter les données provenant des périphériques après coup, en les collant dans une instance MSMQ ou en stockant les objets sérialisés dans des données temporaires. stocker et avoir un service windows les traiter plus tard.

Voilà donc mes choix, mais à part cela, voici quelques autres choses qui pourraient vous aider, les gars, à me conseiller:

• Les données renvoyées par les périphériques ne seront pas renvoyées sous forme de paquets de messages plus petits devant être commandés côté serveur.
• Je ne connais rien à MSMQ, mais j’ai déjà écrit des services Windows. Bien que je n’aie aucun problème à prendre MSMQ si cela est nécessaire.
• Je souhaite conserver la réponse des périphériques quelque part dans le cas où le traitement échouerait pour une raison quelconque qui serait provoquée par les données. De cette façon, je peux interroger les données et voir s'il y a un problème, c'est-à-dire que le périphérique permet à un utilisateur d'ajouter des commentaires qui étendent la longueur du champ associé dans la base de données côté serveur.

Avec ces informations, pensez-vous que cela vaut la peine que je cherche à apprendre le MSMQ ou devrais-je m'en tenir à la solution plus simple?

Chris.

Answer 1

MSMQ n’est pas un mauvais choix et n’est certainement pas difficile à apprendre, mais gardez à l’esprit que vous devez être conscient de certaines contraintes.

Inconvénients:

• Chaque file d'attente ne peut être que de 2 Go.
• Chaque message de 4 Mo (la limite de 4 Mo peut être fixée à l'aide de MSMQ avec WCF).
• Uniquement pour Windows, vous ne pouvez donc l'utiliser qu'avec les bibliothèques .NET, C / C ++ ou COM pour les environnements activés.

Avantages:

• Prend en charge l'équilibreur de charge réseau Windows.
• Prend en charge le service de cluster Microsoft.
• Intégré à Active Directory.
• Livré avec Windows.
• Prend en charge les transactions.
• Les messages MSMQ peuvent être suivis par des messages d'audit dans le journal des événements Windows.
• Les messages peuvent être automatiquement authentifiés (signés) ou chiffrés lors de l'envoi, puis vérifiés et déchiffrés lors de leur réception.

Une autre approche que vous pouvez envisager consiste à écrire vos données dans une table intermédiaire. Cela peut être une bonne idée puisque vous souhaitez avoir un journal de message.

Il est difficile de donner des conseils quand je ne connais pas le reste de l'architecture du système, mais j'espère que cette réponse aidera un peu.

Liens utiles

Programmation de MSMQ dans .NET - Partie 1 . Utilisation de MSMQ avec WCF