Ich bin definitiv kein Experte in der Sache, aber mein Wissen ist, dass fcntl, wie Sie auch gesagt haben, in Ihrem Fall nicht funktionieren wird. fcntl advisory locks machen nur innerhalb desselben Rechners Sinn.
Also vergiss mich, wenn das off-Thema ist. Ich habe File::NFSLock verwendet, um Cachestürme/dogpile/stampeding Problem zu lösen. Es gab mehrere Anwendungsserver, die Cachedateien auf einem NFS-Volume lesen und schreiben (keine sehr gute Idee, aber damit hatten wir angefangen).
ich Unterklasse/umzingelte Datei :: NFSLock sein Verhalten zu ändern. Insbesondere musste ich:
- persistent Schlösser, die nicht weggehen, wenn ein File :: nfslock Objekt den Gültigkeitsbereich verlässt. Wenn Sie reguläres File :: NFSLock verwenden, wird Ihre Sperre verschwinden, wenn das Objekt den Gültigkeitsbereich verlässt. Das war nicht was ich brauchte.
- , dass tatsächliche Sperrdateien auch den Namen der Maschine enthalten, die das Schloss erworben hat. Die Prozess-ID ist eindeutig nicht genug, um zu entscheiden, ob ein Prozess beendet ist, so dass ich die Sperrdatei sicher stehlen kann. Also habe ich den Code geändert, um Lockfiles wie
machine:pid anstatt nur pid zu schreiben.
Das hat wunderbar für ein paar Jahre gearbeitet.
Bis das Volumen der Anfragen einen 10x Anstieg hatte. Das heißt, letzten Monat begann ich, die ersten Probleme zu erleben, bei denen eine wirklich ausgelastete Cachedatei von zwei Back-Ends unter der gleichen Zeit geschrieben wurde, was tote Sperren zurückließ. Dies passierte für mich, als wir ungefähr 9-10 Millionen Seitenzugriffe pro Tag erreichten, nur um Ihnen eine Idee zu geben.
Die letzte gebrochene Cache-Datei sah aus wie:
<!-- 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 -->
Dies kann nur geschehen, wenn zwei Backends in die gleichen Datei zur gleichen Zeit zu schreiben ... Es ist noch nicht klar, ob dieses Problem durch Datei verursacht wird: : NFSLock + unsere Mods oder ein Bug in der Anwendung.
Abschließend, wenn Ihre App nicht schrecklich beschäftigt und gehandelt wird, dann gehen Sie für File :: NFSLock, ich denke, es ist Ihre beste Wette. Bist du sicher, dass du immer noch NFS benutzen willst?
Sperren auf NFS ist schwer. Die Verwendung von 'File :: NFSLock' würde Ihnen wahrscheinlich eine Lösung geben, die funktioniert, ohne dass Sie irgendeinen Code schreiben müssen. – rafl
Datei :: NFSLock hat einige eigene Löcher.Es versucht, Tricks mit Hardlinks und anderen Dingen zu spielen, aber wenn Ihr Dateisystem überlastet ist, können Sie leicht Race-Bedingungen haben, die zwei Prozesse mit der gleichen Sperre ergeben. – mmccoo
Es hat einige dokumentierte Fehlzusammenhänge, einschließlich der Tendenz, Warteprozesse in hoch strittigen Situation zu verhungern, ja. Für das Problem, das Sie versuchen zu lösen, könnte es jedoch immer noch der richtige Kompromiss sein. Ich kann es nicht genau sagen, da du deine Umstände nicht weiter beschrieben hast. Ich kann jedoch aus Erfahrung mit File :: NFSLock sprechen: Ich habe noch nie gesehen, dass mein Ansatz irgendwelche meiner Prozesse verhungern lässt, selbst in Situationen mit vielen Konflikten, verglichen mit den meisten anderen Dingen, die ich mache. Die Anzahl der Module hängt davon ab, dass es für die meisten Leute gut genug ist. – rafl