2009-07-21 11 views
6

¿Es una buena idea usar sockets para enviar datos entre dos servidores, o debería usar algo como MQ para mover datos?¿Son confiables los enchufes?

Mis preguntas: ¿son confiables los enchufes, si necesito una entrega única/segura de los datos?

¿Hay alguna otra solución?

Gracias.

+1

... SON tomas fiable? –

+2

@modosansreves: Si las palabras codificadas son legibles, siempre y cuando la primera y la última letra estén en su lugar, la gramática incorrecta no dolerá mucho. Concéntrese en el mensaje y no en las palabras individuales. –

Respuesta

12

Los sockets son API de nivel de aplicación para realizar comunicaciones de red. La confiabilidad de los sockets depende del protocolo de red que seleccione cuando cree el socket. Si selecciona TCP/IP, obtendrá una transferencia "confiable" ... hasta un límite. Si selecciona UDP/IP obtendrá una transferencia "no confiable".

Como se ha dicho en otras respuestas, TCP garantiza que no se pierde o corromper los datos hasta un punto:

  1. si hay una interrupción de la red el tiempo suficiente , o el emisor o el receptor muere una La conexión TCP/IP romperá y perderá datos a menos que tome medidas para reiniciar la conexión .
  2. si hay una corrupción de datos de nivel de red , existe una probabilidad pequeña de que no sea detectado por las sumas de comprobación.

Para mayores niveles de garantías de fiabilidad que TCP/IP proporciona, es necesario implementar la suma de comprobación más sensible y mecanismos de entrega garantizados sobre la parte superior de la capa de red basada en el zócalo de la aplicación. O use un producto de cola de mensajes que hace el trabajo difícil para usted.

Así que la respuesta a su pregunta es que depende de cómo use los Sockets y del nivel de confiabilidad que su sistema requiera.

2

Los sockets son tan confiables como la implementación y se basan en el hardware subyacente. Si no quiere la molestia de hacer un servicio de entrega garantizado (¿en qué condiciones? El 100% nunca va a suceder), un sistema de cola de mensajes es una buena apuesta. La cola de mensajes habrá implementado toda la persistencia, las colas, los reintentos, etc. que necesitaría implementar usted mismo si fuera con los sockets estándar.

2

Probablemente debería usar un MQ si necesita una entrega garantizada sin importar lo que pase (como si la otra parte se desconectara para el mantenimiento) y usted no quiere escribir toda la lógica usted mismo. Sockets es lo que usa para conectarse con un tercero, sin importar si esa parte es el MQ o el receptor final del mensaje.

1

Enchufes es el mecanismo en bruto para la transferencia de datos. Todo lo demás se implementa en la parte superior de esto. En el OSI network model, pertenecen a la capa 4. Aunque implementan una conexión fiable de extremo a extremo, rara vez se utilizan como protocolo final. Casi siempre es necesario implementar una capa de aplicación. Lo que esto depende depende de su aplicación (¿necesita transferir archivos o simplemente enviar mensajes?) Y su infraestructura de red.

+0

+1: Para el uso de "sockets IS" para molestar a los dispositivos. Por supuesto, podría ser una coincidencia completa, pero es una graciosa. –

+2

Los sockets no están relacionados con el modelo de red OSI. Un zócalo es una interfaz para (potencialmente) comunicación binaria bidireccional que deriva su valor del hecho de que se puede conectar a cualquier canal subyacente y admite una gran variedad de propiedades del canal de comunicación subyacente. Más allá de raw/tcp/udp y otras comunicaciones de red, puede usar un zócalo para comunicarse localmente a través de un conducto, o cualquier canal que pueda imaginar. No reduzca este concepto a OSI. –

0

Si utiliza un stream socket, el protocolo TCP garantiza que los datos no se pierdan en la transmisión y es poco probable que se corrompan (aunque debe decidir si sus sumas de comprobación de 16 bits son suficientes o si necesita un mecanismo de suma de comprobación de capa de aplicación) .

Lo que los sistemas MQ ofrecen, y lo que puede o no necesitar es confiabilidad a nivel de aplicación transaction-type, es decir, la capacidad de garantizar la entrega incluso ante fallas intermitentes de hardware o software.

0

Dependiendo del tipo de datos, un servicio web simple puede ser la solución más rápida. Son relativamente fáciles de configurar y probar. Aunque para algunos ejemplos específicos, necesitaría saber qué tipo de datos y entorno está ejecutando.

0

Depende mucho del tipo de aplicación que esté desarrollando. Si está escribiendo un programa donde necesita respuesta o una copia del mensaje enviado, los conectores TCP son buenos. Pero, si está implementando algún tipo de escenario de flujo de trabajo, debería usar Message Queues.

2

El zócalo es confiable ya que cada comunicación se hace encima, incluyendo MQ.

Pero es posible que desee agregar alguna entrega garantizada con MQ para mejorar la confiabilidad de su aplicación. ¿Qué es? la entrega garantizada garantiza que su mensaje sea procesado al menos una vez, y no más de una vez, por el consumidor. el consumidor está apagado? el productor está fuera? el servidor MQ está apagado? el disco se cuelga? gracias a MQ, no se perderá ningún mensaje, pase lo que pase (siempre que su administrador conozca su trabajo). Además de eso, si reinicia el consumidor, ningún mensaje se procesará dos veces. Lo que puede ser importante si los mensajes contienen transferencias de millones de dólares. Pero no garantiza que su mensaje se procese en un tiempo razonable. y el tiempo de procesamiento es en algún momento más importante que garantiza la entrega, dependiendo de su aplicación.

Depende de usted elegir la mejor manera de comunicarse entre sus servidores según sus necesidades. La entrega garantizada de entrega tiene un costo tanto financiero como de rendimiento, por lo que debe usarse solo si realmente se necesita (millones de transferencias, por ejemplo).

Para la mayoría de las aplicaciones puede lograr algo satisfactorio solo reintentando sus mensajes cuando fallan. Pero eso no es real una vez garantizada la entrega. no intente implementarlo usted mismo, es una tarea muy difícil que solo unos pocos logran. Es útil considerar la posibilidad de volver a desarrollar un software tan complicado como MQ o Apache AQ.

Espero que ayude.

  • Jeb
Cuestiones relacionadas