est-il une bonne idée d'utiliser des sockets pour envoyer des données entre deux serveurs ou devrais-je utiliser quelque chose comme MQ pour le déplacement de données?
Mes questions: Les sockets sont-ils fiables, si j'ai besoin d'une seule fois / assuré livraison des données?
Y a-t-il d'autres solutions?
Merci.
8 Réponses :
Les sockets sont aussi fiables que votre implémentation et basées sur le matériel sous-jacent. Si vous ne voulez pas que le problème de faire un service de livraison garanti (dans quelles conditions? 100% ne se produira jamais), un système de file d'attente de message est un bon pari. La file d'attente de messages aura mis en œuvre toutes les persistantes, la queue, les tentatives, etc. que vous auriez besoin de vous mettre en œuvre si vous êtes allé avec des prises standard.
Vous devriez probablement utiliser un MQ si vous avez besoin de livraison garantie, peu importe ce qui se passe (comme si l'autre partie passe hors ligne pour la maintenance) et vous ne voulez pas écrire toute la logique vous-même. Les sockets sont ce que vous utilisez pour vous connecter à une autre partie, peu importe si cette partie est le MQ ou le récepteur final du message.
Les sockets sont le mécanisme brut pour transférer des données. Tout le reste est mis en œuvre sur ceci. Dans le Modèle de réseau OSI Ils appartiennent à la couche 4. Bien qu'ils mettent en œuvre une fin de course fiable Connexion, ils sont rarement utilisés comme protocole final. Vous avez presque toujours besoin de mettre en œuvre une couche d'application. Ce que cela dépend de votre application (devez-vous transférer des fichiers ou simplement envoyer des messages) et votre infrastructure de réseau?
+1: pour l'utilisation de "sockets" est "pour dépiter des modosesReves. Bien sûr, cela pourrait être une coïncidence complète, mais c'est une drôle.
Les sockets ne sont pas liés au modèle réseau OSI. Une prise est une interface pour (potentiellement) communication bidirectionnelle et tamponnée qui tire la valeur qu'il peut être attachée à tout canal sous-jacent et prend en charge une grande variété de propriétés du canal de communication sous-jacent. Au-delà de RAW / TCP / UDP et d'autres communications de réseau Vous pouvez utiliser une prise pour communiquer localement à travers un tuyau ou quel que soit le canal que vous pouvez imaginer. Ne réduisez pas ce concept à OSI.
Si vous utilisez un Prise de flux , le protocole TCP garantit que les données ne sont pas perdues En transmission et qu'il est peu probable de se corrompre (bien que vous devez décider si ses checksums 16 bits sont suffisants ou si vous avez besoin d'un mécanisme de contrôle de couche d'application).
Qu'est-ce que les systèmes MQ fournissent, et ce que vous pouvez avoir besoin ou non est le niveau d'application Type de transaction < / a> la fiabilité, c'est-à-dire la capacité de garantir la livraison même face à des échecs matériels ou logiciels intermittents.
Selon le type de données, un service Web simple peut être la solution la plus rapide. Ils sont relativement faciles à mettre en place et à tester. Bien que pour certains exemples spécifiques, je devrais savoir quel type de données et d'environnement vous utilisez.
Cela dépend en largeusement sur le type d'application que vous développez. Vous écrivez un programme dans lequel vous avez besoin de réponse ou d'ACK du message envoyé, puis les sockets TCP sont bons. Mais si vous mettez en œuvre un peu de scénario de flux de travail, vous devez utiliser des files d'attente de messages.
Les sockets sont une API de niveau d'application pour effectuer une communication réseau. La fiabilité des sockets dépend du protocole réseau que vous sélectionnez lorsque vous créez la prise. Si vous sélectionnez TCP / IP, vous obtiendrez un transfert «fiable» ... jusqu'à une limite. Si vous sélectionnez UDP / IP, vous obtiendrez un transfert «non fiable».
Comme indiqué dans d'autres réponses, TCP garantit que vous ne perdez ni ne corrompre des données jusqu'à un point:
Pour des niveaux plus élevés de garanties de fiabilité que TCP / IP fournit, vous devez mettre en œuvre des mécanismes de contrôle plus sensibles et des mécanismes de livraison garantis sur le dessus de la couche de réseau à base de votre application. Ou utilisez un produit de file d'attente de message qui fait dure le travail pour vous.
La réponse à votre question est que cela dépend de la manière dont vous utilisez des sockets et sur quel niveau de fiabilité de votre système exige.
socket est fiable car chaque communication est effectuée sur le dessus, y compris MQ.
Mais vous voudrez peut-être ajouter une livraison de garantie avec MQ pour améliorer la fiabilité de votre application. Qu'est-ce que c'est? La livraison Garantie garantit que votre message est traité au moins une fois et au plus une fois, par le consommateur. Le consommateur est éteint? le producteur est éteint? Le serveur MQ est éteint? Le disque se bloque? Grâce à MQ, aucun message ne sera perdu, tout ce qui se passe (à condition que votre administrateur connaisse son travail). En plus de cela, si vous redémarrez le consommateur, aucun message ne sera traité deux fois. Ce qui peut être important si les messages contiennent des transferts de million de dollars. Mais cela ne garantit pas que votre message est traité dans une quantité de temps raisonnable. et le temps de traitement est parfois plus important que la livraison de garantie, en fonction de votre application.
Il vous appartient de choisir le meilleur moyen de communiquer entre vos serveurs en fonction de vos besoins. La livraison de la garantie à la livraison a à la fois des coûts financiers et de performance. Il ne doit donc être utilisé que s'il avait besoin (des millions de dollars de dollars par exemple).
Pour la plupart des applications, vous pouvez réaliser quelque chose de satisfaire uniquement en réessayant vos messages lorsque vous échouez. Mais ce n'est pas une réelle livraison de garantie unique. N'essayez pas de le mettre en œuvre par vous-même, c'est une chose très difficile que peu de peu de choses sont capables de réaliser. C'est USELES d'envisager de réaménager un logiciel aussi compliqué que MQ ou Apache Aq.
espère que cela aide.
@ModosansReves: Si des mots brouillés sont lisibles tant que les premières lettres sont en place, alors la grammaire incorrecte ne fera pas beaucoup de mal. Concentrez-vous sur le message et non les mots individuels.