Estoy trabajando en el diseño de una aplicación de múltiples niveles en Perl y me pregunto cuáles son los pros y los contras de los diversos mecanismos de IPC disponibles para mí. Estoy tratando de manejar datos de tamaño moderado, típicamente unas pocas docenas de kilobytes pero hasta un par de megabytes, y la carga es bastante ligera, a lo sumo un par de cientos de solicitudes por minuto.¿Cuál es el mejor mecanismo de IPC para datos de tamaño mediano en Perl?
Mi principal preocupación es el mantenimiento y el rendimiento (en ese orden). No creo que tenga que escalar a más de un servidor, o puerto fuera de nuestra plataforma principal (RHEL), pero supongo que es algo a considerar.
puedo pensar en las siguientes opciones:
- archivos temporales - simplista, probablemente la peor opción en términos de requisitos de velocidad y almacenamiento
- sockets de dominio UNIX - No es portátil, no escalable
- internet sockets - portátiles, escalables
- Tubos - (?) portátil, no escalable
Considérant Creo que necesito aprender más acerca de la escalabilidad y la portabilidad. ¿Cuál es la mejor opción y por qué? Por favor comente si necesita información adicional.
EDIT: Voy a tratar de dar más detalle en respuesta a ysth's questions(advertencia, muro de texto a continuación):
- son lectores/escritores en una relación uno a uno, o algo más complicado?
- ¿Qué le quiere pasar al escritor si el lector ya no está allí o no está ocupado?
- ¿Y viceversa?
- ¿Qué otra información tiene sobre su uso deseado?
En este punto, estoy contemplando un enfoque de tres niveles, pero no estoy seguro de cuántos procesos tendré en cada nivel. Creo que necesita tener más procesos hacia el lado izquierdo y menos hacia la derecha, pero tal vez debería tener el mismo número en todos los ámbitos:
.---------. .----------. .-------. | Request | -----> | Business | -----> | Data | | Manager | <----- | Logic | <----- | Layer | `---------' `----------' `-------'
Estos nombres siguen siendo genéricos y probablemente no lo hará en la implementación en estas formas.
El administrador de solicitud es responsable de escuchar solicitudes de diferentes interfaces, por ejemplo, solicitudes web y CLI (donde el tiempo de respuesta es importante) y correo electrónico (donde el tiempo de respuesta es menos importante). Realiza el registro y gestiona las respuestas a las solicitudes (que se procesan en un formato apropiado para el tipo de solicitud).
envía datos acerca de la solicitud a la lógica de negocio que realiza el registro, autorización, dependiendo de las reglas de negocio, etc.
la lógica de negocio (si es necesario) solicita a continuación datos de la capa de datos , que puede hablar con (la mayoría de las veces) la base de datos MySQL interna o alguna otra fuente de datos fuera del control de nuestro equipo (por ejemplo, los servidores LDAP principales de nuestra organización o nuestra base de datos de información de empleados de DB2, etc.). En su mayoría, se trata simplemente de un contenedor que formatea los datos de manera uniforme para que se pueda manejar con mayor facilidad en la lógica comercial.
La información vuelve al gestor de solicitudes para su presentación.
Si, cuando los datos fluyen hacia la derecha, el lector está ocupado, para las solicitudes interactivas me gustaría simplemente esperar un período de tiempo adecuado, y devolver un error de tiempo de espera si no obtengo acceso en ese cantidad de tiempo (por ejemplo, "Intente de nuevo más tarde"). Para las solicitudes no interactivas (por ejemplo, correo electrónico), el sistema de sondeo simplemente puede salir e intentar nuevamente en la siguiente invocación (que probablemente será una vez cada 1-3 minutos).
Cuando los datos fluyen en la otra dirección, no debe haber ninguna situación de espera. Si uno de los procesos ha muerto al intentar regresar a la izquierda, todo lo que puedo hacer es iniciar sesión y salir.
De todos modos, eso fue bastante detallado, y como todavía estoy en el diseño inicial, probablemente aún tenga algunas ideas confusas. Algo de lo que he mencionado probablemente sea tangencial al problema de cuyo sistema IPC usar. Estoy abierto a otras sugerencias sobre el diseño, pero estaba tratando de mantener la pregunta limitada en su alcance (Por ejemplo, tal vez debería considerar el colapso en dos niveles, que es mucho más simple para IPC). ¿Cuáles son tus pensamientos?
Muchas gracias! Estaba ho ping para conectarse con algunos recursos útiles de Perl. –