Interprozesskommunikation

Question

Welche Vor- und Nachteile hat die Verwendung einer Datei für die Interprozesskommunikation? Lassen Sie mich einige Hintergrundinformationen über den Kontext geben, in dem ich diese Frage stelle.

Das Problem ist das klassische Produzentenverbraucherproblem mit einigen Einschränkungen. Die Produzenten sind kooperative Prozesse, die auf einem Cluster von Maschinen laufen und über Broadcasts miteinander kommunizieren. Jeder Prozess hat lokale Benutzer, von denen er weiß, und informiert die anderen Prozesse durch den obigen Übertragungsmechanismus darüber. Bis jetzt wurde die Statusinformation, die gesendet/geteilt wurde, nicht beibehalten, aber jetzt muss es sein.

Dieses System läuft seit Jahren auf Produktion und unterstützt Tausende von Benutzern und Leute sind verständlicherweise sehr besorgt über das Hinzufügen von zusätzlichen Abhängigkeiten, um die Unterstützung für Persistenz hinzuzufügen. Der Pfad, den wir gewählt haben, war, einen neuen Thread im bestehenden Prozess zu erzeugen, der den lokalen Datenverkehr in eine Datei im Dateisystem schreibt, die dann von einem neuen Prozess gelesen wird (wir können ihn den Consumer nennen) und persistent bleiben. Die Vorteile, die wir mit diesem Ansatz sehen, sind:

1. Wir erhalten Persistenz kostenlos. Wenn der neue Prozess Probleme hat, verlieren wir keinen lokalen Datenverkehr, da wir ihn in das Dateisystem schreiben. Solange der Verbraucher weiß, wo er aufgehört hat, kann er mit der Verarbeitung von Daten beginnen.
2. Es gibt keine Lernkurve für die Verwendung von Warteschlangenbibliotheken ihre einfache alte Unix-Datei IO.
3. Der größte Vorteil ist, dass wir den aktuellen Produktionsprozess überhaupt nicht beeinflussen, außer dem neuen Thread für Dateischreibvorgänge.

Einige der Bedenken bei diesem Ansatz sind:

1. Sperren von Dateien und Streit und seine Auswirkungen auf die Leistung.
2. Sicherstellen, dass die Schreibpuffer geleert werden und der Hersteller die Dateisperre nur dann freigibt, wenn ein vollständiges Ereignis in die Datei geschrieben wurde. Der Verbraucher sollte unvollständige Datensätze lesen.

Gedanken? Ist diese Herangehensweise naiv und sollten wir nur die anfänglichen Kosten für die Anlaufzeit für die Verwendung einer ausdauernden Warteschlange-Bibliothek bezahlen? Der wichtigste Punkt hierbei ist, dass wir den minimalen möglichen Einfluss auf den aktuellen Prozess haben und keine Abhängigkeiten hinzufügen.

Answer 1

Ich war vor kurzem mit dieser Wahl konfrontiert und dachte darüber nach, genug über Berkeley DB zu lernen, um seinen Warteschlangenmechanismus zu benutzen. Aber letztlich entschied ich mich stattdessen, das Unix-Dateisystem zu verwenden und meine eigenen atomischen Queue Primitive mit Posix semaphores schreiben. Wenn alle Prozesse auf einer Maschine laufen, ist das ziemlich einfach. Die atomare Put-Funktion besteht aus etwa einem Dutzend Codezeilen; das atomare get, weil es warten muss, wenn die Warteschlange leer ist, ist etwa dreimal so groß.

Mein Rat ist, dass Sie eine Atom-Warteschlange API entwerfen, die diese Details verbergen wird. (Klassisches Beispiel für den Hinweis von Parnas, eine Schnittstelle zu verwenden, um Entwurfsdetails auszublenden, die sich wahrscheinlich ändern.) Sie können die erste Version der API mit einfachen Unix-Datei-E/A ausführen. Dann können Sie Variationen wie Locking, Berkeley DB oder Semaphore ausprobieren - alles mit der "minimalen Auswirkung auf den aktuellen Prozess".

Sie werden die Auswirkungen auf die Leistung erst kennen, wenn Sie etwas versuchen. Datei-Locking auf echten Dateisystemen ist ziemlich gut; Dateisperre auf NFS ist ein Bär.