Comunicación entre procesos

Question

¿Cuáles son los pros y los contras de usar un archivo para la comunicación entre procesos? Permítanme darles algunos antecedentes del contexto en el que hago esta pregunta.

El problema es el problema clásico del consumidor productor con algunas restricciones. Los productores son conjuntos de procesos cooperativos que se ejecutan en un grupo de máquinas y se comunican entre sí mediante difusiones. Cada proceso tiene usuarios locales que conoce y también permite que los otros procesos los conozcan a través del mecanismo de transmisión anterior. Hasta ahora, la información del estado que se está transmitiendo / compartiendo no se estaba conservando, pero ahora tiene que serlo.

Este sistema ha estado funcionando en producción durante años y ahora brinda soporte a miles de usuarios y, comprensiblemente, la gente está muy preocupada por agregar una dependencia adicional a esto para agregar soporte para la persistencia. La ruta que elegimos fue generar un nuevo subproceso en el proceso existente que escribe el tráfico local en un archivo en el sistema de archivos que luego se lee mediante un nuevo proceso (llamémoslo el consumidor) y persistió. Las ventajas que vemos con este enfoque son:

1. Obtenemos la persistencia de forma gratuita. En caso de que el nuevo proceso tenga problemas, no estamos perdiendo el tráfico local mientras lo escribimos en el sistema de archivos. Mientras el consumidor sepa dónde lo dejó, cada vez que lo haga podrá comenzar a procesar los datos.
2. No hay una curva de aprendizaje para usar las bibliotecas de colas, su antiguo y simple archivo unix IO.
3. El mayor profesional es que no afectamos el proceso actual del productor, excepto el nuevo hilo para la escritura de archivos.

Algunas de las preocupaciones con este enfoque son:

1. Bloqueo y contención de archivos y sus efectos en el rendimiento.
2. Asegurarse de que los búferes de escritura estén vaciados y el productor solo libere el bloqueo del archivo una vez que se haya escrito un evento completo en el archivo. El consumidor debe leer los registros incompletos.

Pensamientos? ¿Este enfoque es ingenuo y deberíamos pagar el costo inicial del tiempo de aceleración por el uso de una biblioteca de colas persistente lista para usar? El punto principal aquí es que queremos tener el mínimo impacto posible en el proceso actual y no agregarle dependencias.

Answer 1

Hace poco me enfrenté a esta elección y consideré tener suficiente información sobre Berkeley DB para usar su mecanismo de cola. Pero finalmente decidí usar el sistema de archivos Unix y escribir mis propias primitivas de cola atómica usando Posix semáforos . Si todos los procesos están en una máquina, esto es bastante fácil. La función put atómica es aproximadamente una docena de líneas de código; El atomic get, porque tiene que esperar si la cola está vacía, es aproximadamente tres veces el tamaño.

Mi consejo es que diseñe una API de cola atómica que oculte estos detalles. (Ejemplo clásico de seguir los consejos de Parnas de usar una interfaz para ocultar detalles de diseño que puedan cambiar). Puede hacer la primera versión de la API usando E / S de archivos Unix. Luego puede probar variaciones como bloqueo, Berkeley DB o semáforos, todo con el mínimo impacto en el proceso actual.

No conocerá los impactos en el rendimiento hasta que pruebe algo. El bloqueo de archivos en sistemas de archivos reales es bastante bueno; el bloqueo de archivos en NFS es un oso.