Definitivamente no soy un experto en el asunto, pero mi conocimiento es que fcntl, como usted también indicó, no funcionará en su caso. Los bloqueos de aviso fcntl solo tienen sentido dentro de la misma máquina.
Así que, olvídame si esto fuera de tema. Usé File::NFSLock para resolver el problema de tormentas de caché/dogpile/stampeding. Había varios servidores de aplicaciones leyendo y escribiendo archivos de caché en un volumen NFS (idea no muy buena, pero eso fue con lo que comenzamos).
He subclassed/wrapped File :: NFSLock para modificar su comportamiento. En particular, lo que necesitaba:
- persistentes cerraduras, que no desaparecen cuando un objeto File :: nfslock sale del ámbito. Usando File :: NFSLock regular, su bloqueo se desvanecerá cuando el objeto se salga del alcance. Esto no era lo que necesitaba.
- que los archivos de bloqueo reales también contienen el nombre de la máquina que adquirió el bloqueo. La identificación del proceso claramente no es suficiente para decidir si un proceso finaliza, por lo que puedo robar el archivo de bloqueo sin peligro. Así que modifiqué el código para escribir archivos de bloqueo como
machine:pid en lugar de solo pid.
Esto ha funcionado maravillosamente durante un par de años.
Hasta que el volumen de solicitudes tuvo un aumento de 10x. Es decir, el mes pasado comencé a experimentar los primeros problemas en los que dos archivadores escribían un archivo de caché realmente ocupado en el mismo momento , dejando, dejando bloqueos inactivos. Esto me sucedió cuando alcanzamos alrededor de 9 a 10 millones de páginas vistas por día, solo para darle una idea.
El archivo de caché rota última parecía:
<!-- START OF CACHE FILE BY BACKEND b1 -->
... cache file contents ...
<!-- END OF CACHE FILE BY BACKEND b1 -->
... more cache file contents ... wtf ...
<!-- END OF CACHE FILE BY BACKEND b2 -->
Esto sólo puede ocurrir si dos backends escribir en el mismo archivo al mismo tiempo ... Es todavía no está claro si este problema es causado por File: : NFSLock + nuestros mods o algún error en la aplicación.
En conclusión, si su aplicación no está terriblemente ocupada y es objeto de tráfico, entonces vaya a File :: NFSLock, creo que es su mejor opción. ¿Seguro que todavía quieres usar NFS?
El bloqueo en NFS es difícil. Usar 'File :: NFSLock' probablemente le dará una solución que solo funciona sin que tenga que escribir ningún código. – rafl
File :: NFSLock tiene algunos agujeros propios.Intenta jugar algunos trucos con enlaces duros y demás, pero si su sistema de archivos está sobrecargado, puede tener fácilmente condiciones de carrera que produzcan dos procesos con el mismo bloqueo. – mmccoo
Tiene algunas deficiencias documentadas, incluida la tendencia a privar a los procesos de espera en una situación altamente polémica, sí. Sin embargo, para el problema que está tratando de resolver todavía podría ser la compensación correcta. Realmente no puedo decirlo porque no describiste tus circunstancias aún más. Sin embargo, puedo hablar por experiencia de uso de File :: NFSLock: nunca he visto su enfoque matar de hambre a ninguno de mis procesos, incluso en situaciones con mucha contención, en comparación con la mayoría de las otras cosas que estoy haciendo. El número de módulos que dependen de él también parece indicar que es lo suficientemente bueno para la mayoría de las personas – rafl