Einführung vom Übersetzer
In diesem Artikel geht es um Erlang , aber alles, was gesagt wird, gilt auch für Elixir , eine funktionale Sprache, die auf derselben BEAM- virtuellen Maschine ausgeführt wird. Es erschien im Jahr 2012 und entwickelt sich jetzt aktiv weiter. Elixir hat die Syntax den meisten besser bekannt gemacht und verfügt über umfangreiche Metaprogrammierungsfunktionen , wobei die Vorteile von Erlang erhalten bleiben.
Mehr vom ÜbersetzerEin Artikel aus dem Jahr 2016, aber es geht um grundlegende Konzepte, die nicht ablaufen.
Verweise auf Konzepte und Kommentare von mir (dem Übersetzer) stehen in eckigen Klammern []
und sind mit einem „Übersetzernotiz“ gekennzeichnet.
Wenn Sie feststellen, dass einige Teile der Übersetzung nicht korrekt genug sind, insbesondere in Bezug auf die Begriffe, oder wenn Sie auf andere Fehler stoßen, lassen Sie es mich bitte wissen, ich werde sie gerne korrigieren.
Besonderer Dank geht an Jan Gravshin für seine Hilfe beim Korrekturlesen und Bearbeiten des Textes.
Dies ist eine kostenlose Abschrift (oder eine lange Paraphrase?) Meiner Präsentation auf der von Genetec organisierten ConnectDev'16-Konferenz.

Ich glaube, die meisten Leute hier haben noch nie in Erlang programmiert. Sie haben vielleicht davon gehört oder kennen den Namen. Daher wirkt sich meine Präsentation nur auf die übergeordneten Konzepte von Erlang aus und ist so nützlich, dass sie für Ihre Arbeit oder Nebenprojekte nützlich sind, auch wenn Sie nie auf diese Sprache stoßen.

Wenn Sie sich jemals für Erlang interessiert haben, dann haben Sie von dem Motto "Let it Crash" gehört [ "Let it fall" - ca. Übersetzer ]. Bei meinem ersten Treffen mit ihm fragte ich mich, worum es eigentlich ging. Erlang sollte für Multithread-Ausführung und Fehlertoleranz großartig sein, aber hier schlagen sie vor, dass ich alles fallen lasse: das genaue Gegenteil des Verhaltens des Systems, das ich wirklich will. Der Vorschlag ist überraschend, aber dennoch steht Erlangs Zen in direktem Zusammenhang damit.

In gewisser Hinsicht macht die Verwendung von "Let it Crash" für Erlang genauso viel Spaß wie "Blow it up" [ " Blow it !" - ca. Übersetzer ] für Raketenwissenschaft. "Sprengen" ist vielleicht das Letzte, was Sie in der Raketenwissenschaft wollen, und die Challenger-Katastrophe ist eine lebhafte Erinnerung daran. Wenn Sie die Situation jedoch anders betrachten, haben die Raketen und ihr gesamtes Antriebssystem mit gefährlichen Brennstoffen zu tun, die explodieren können und werden (und dies ist ein riskanter Moment), jedoch so kontrolliert, dass sie zur Organisation des Weltraums verwendet werden können Reisen oder Senden von Nutzlasten in den Orbit.
Und der Punkt hier ist wirklich unter Kontrolle; Sie können versuchen, die Raketenwissenschaft als einen Weg zu betrachten, um Explosionen - oder zumindest ihre Kraft - richtig zu zähmen, um mit ihnen das zu tun, was Sie wollen. Im Gegenzug können Sie "Let it abstürzen" aus demselben Blickwinkel betrachten: Es geht um Fehlertoleranz. Die Idee besteht nicht in weit verbreiteten unkontrollierten Fehlern, sondern darin, Fehler, Ausnahmen und Abstürze in Tools umzuwandeln, die verwendet werden können.

Gegensturz [Gegenherbst - ca. Übersetzer ] und kontrolliertes Tempern ist ein echtes Beispiel für die Bekämpfung von Feuer mit Feuer. In Saguenay-lac-Saint-Jean, der Region, aus der ich komme, werden Blaubeerfelder regelmäßig kontrolliert verbrannt, um ihr Wachstum zu stimulieren und wieder aufzunehmen. Sehr oft können Sie ungesunde Bereiche des Waldes sehen, die durch Feuer gerodet wurden, um Waldbrände zu verhindern, so dass dies unter angemessener Aufsicht und Kontrolle geschieht. Das Hauptziel ist es, brennbares Material zu entfernen, damit sich ein natürliches Feuer nicht weiter ausbreiten kann.
In all diesen Situationen wird die zerstörerische Kraft des Feuers, das durch Pflanzen oder Wälder fegt, genutzt, um Pflanzen zu heilen oder die viel größere, unkontrollierte Zerstörung von Wäldern zu verhindern.
Ich denke, die Bedeutung von "Let it Crash" ist genau das. Wenn wir Ausfälle, Abstürze und Ausnahmen ausnutzen und überschaubar gestalten können, werden sie nicht mehr das erschreckende Ereignis sein, das vermieden werden muss, und werden im Gegenzug zu einem leistungsstarken Bauelement für die Montage großer zuverlässiger Systeme.

Somit stellt sich die Frage, wie sichergestellt werden kann, dass Fehler eher konstruktiv als destruktiv sind. Der Hauptchip dafür in Erlang ist der Prozess. Erlang-Prozesse sind vollständig isoliert und haben eine untrennbare Architektur (nichts teilen). Kein Prozess kann in den Speicher eines anderen kriechen oder die Arbeit beeinträchtigen, indem er die verwendeten Daten verzerrt. Dies ist gut, da dies bedeutet, dass ein aussterbender Prozess mit einer 100% igen Garantie seine Probleme für sich behält und Ihrem System eine sehr starke Fehlerisolation bietet.
Die Prozesse in Erlang sind außerdem extrem leicht, sodass Tausende und Abertausende problemlos gleichzeitig arbeiten können. Die Idee ist, so viele Prozesse zu verwenden, wie Sie benötigen , anstatt so viele, wie Sie sich leisten können . Stellen Sie sich vor, es gibt eine objektorientierte Programmiersprache, in der zu einem bestimmten Zeitpunkt maximal 32 Objekte gleichzeitig arbeiten dürfen. Sie würden schnell zu dem Schluss kommen, dass die Einschränkungen zu streng und ziemlich lächerlich sind, um Programme darauf zu erstellen. Das Vorhandensein vieler kleiner Prozesse führt zu einer höheren Variabilität der Ausfälle. In einer Welt, in der wir die Kraft des Scheiterns in den Dienst stellen wollen, ist das gut!
Der Mechanismus der Prozesse in Erlang mag etwas seltsam erscheinen. Wenn Sie ein Programm in C schreiben, haben Sie eine große main()
Funktion, die eine Menge von allem erledigt. Dies ist der Einstiegspunkt in das Programm. In Erlang gibt es so etwas nicht. Keiner der Prozesse ist der Hauptprozess. Jeder Prozess startet eine Funktion, und diese Funktion spielt die Rolle von main()
dieses bestimmten Prozesses.
Jetzt haben wir einen Bienenschwarm, aber es muss sehr schwierig sein, sie zu schicken, um den Bienenstock zu stärken, wenn sie in keiner Weise kommunizieren können. Wo die Bienen tanzen [ Bienen tanzen - ca. Übersetzer ], Erlang verarbeitet Messaging.

Messaging ist die intuitivste Form der Kommunikation in einem Wettbewerbsumfeld. Sie ist eine der ältesten Personen, mit denen wir uns befassen müssen, von den Tagen, als wir Briefe schrieben und sie per Kurier auf Pferden schickten, bis hin zu bizarreren Mechanismen wie Napoleons Semaphoren [ optisches Semaphor - ca. Übersetzer ] in der Abbildung gezeigt. Im letzteren Fall schicken Sie einfach ein paar Leute zu den Türmen, geben ihnen eine Nachricht und sie schwenken Flaggen, um Daten über große Entfernungen auf eine Weise zu übertragen, die schneller war als müde Pferde. Allmählich wurde diese Methode durch einen Telegraphen ersetzt, der wiederum das Telefon und das Radio veränderte, und jetzt haben wir all diese modischen Technologien, um Nachrichten sehr weit und sehr schnell zu senden.
Ein äußerst wichtiger Aspekt all dieser Nachrichten, insbesondere in den alten Tagen, ist, dass alles asynchron war und die Nachrichten kopiert wurden. Den ganzen Tag stand niemand auf seiner Veranda und wartete auf die Rückkehr des Kuriers, und niemand (ich vermute) saß in der Nähe des Semaphors und wartete auf eine Antwort. Sie haben eine Nachricht gesendet und sind zu Ihrem Unternehmen zurückgekehrt. Im Laufe der Zeit hat Sie jemand darüber informiert, dass eine Antwort eingetroffen ist.
Das ist gut - wenn die andere Seite nicht reagiert, werden Sie nicht auf Ihrer Veranda stecken bleiben, bis Sie sterben. Umgekehrt wird der Empfänger hingegen nicht mit der Tatsache konfrontiert, dass eine kürzlich eingetroffene Nachricht plötzlich auf magische Weise verschwunden ist oder sich geändert hat, wenn Sie plötzlich gestorben sind. Daten müssen beim Senden von Nachrichten kopiert werden. Diese beiden Prinzipien stellen sicher, dass ein Ausfall während der Kommunikation nicht zu einem verzerrten oder irreparablen Zustand führt [ Zustand - ca. Übersetzer ]. Erlang implementiert beides.
Jeder Prozess verfügt über ein eigenes Postfach für alle eingehenden Nachrichten. Jeder kann in das Prozesspostfach schreiben, aber nur der Besitzer des Postfachs hat die Möglichkeit, es zu prüfen. Standardmäßig werden Nachrichten in der Reihenfolge ihres Empfangs verarbeitet, aber einige Funktionen wie der Mustervergleich [ Mustervergleich - ca. Übersetzer ] ermöglichen es Ihnen, Prioritäten zu ändern und sich ständig oder vorübergehend auf eine bestimmte Art von Nachricht zu konzentrieren.

Einige von Ihnen werden die Seltsamkeit in dem, was ich sage, bemerken. Ich wiederhole immer wieder, dass Isolation und Unabhängigkeit so wunderbar sind, dass Systemkomponenten sterben und fallen können, ohne den Rest zu beeinträchtigen. Ich erwähnte aber auch die Kommunikation zwischen vielen Prozessen oder Agenten.
Jedes Mal, wenn zu Beginn des Dialogs zweier Prozesse eine implizite Abhängigkeit zwischen ihnen auftritt. In dem System, das beide verbindet, entsteht ein impliziter Zustand. Wenn Prozess A eine Nachricht an Prozess B sendet und B ohne Antwort stirbt, kann A entweder für immer auf eine Antwort warten oder nach einiger Zeit die Kommunikation verweigern. Die zweite Strategie ist akzeptabel, aber sehr zweideutig: Es ist völlig unklar, ob die Gegenseite gestorben ist oder so lange beschäftigt ist, und Nachrichten ohne Kontext können in Ihrer Mailbox landen.
Im Gegenzug gibt Erlang zwei Mechanismen an, um dieses Problem zu lösen: Monitore und Verknüpfung [ Links - ca. Übersetzer ].
Bei Monitoren geht es darum, Beobachter zu sein. Sie beschließen, den Prozess im Auge zu behalten. Wenn er aus irgendeinem Grund stirbt, werden Sie in einer Nachricht darüber informiert, was in Ihrem Posteingang passiert ist. Sie können darauf reagieren und anhand der gefundenen Informationen Entscheidungen treffen. Der zweite Prozess wird nie erfahren, dass Sie dies alles getan haben. Daher sind Monitore ziemlich gut, wenn Sie ein Beobachter sind. Übersetzer ] oder kümmern sich um den Status des Partners.
Links [ Links - ca. Übersetzer ] - bidirektional, und die Schaffung eines verbindet das Schicksal beider verwandter Prozesse miteinander. Wenn ein Prozess stirbt, erhalten alle ihm zugeordneten Prozesse einen Befehl zum Beenden [ Ausgangssignal - ca. Übersetzer ]. Dieses Team tötet wiederum andere [ verwandt - ca. Übersetzer ] Prozesse.
All dies wird wirklich interessant, da Sie Monitore verwenden können, um Fehler schnell zu erkennen, und Sie können die Bindung als Architekturentwurf verwenden, mit dem Sie mehrere Prozesse kombinieren können, sodass sich der Fehler auf sie als Ganzes ausbreitet. Immer wenn meine unabhängigen Bausteine voneinander abhängig werden, kann ich dies dem Programm hinzufügen. Dies ist nützlich, da verhindert wird, dass das System versehentlich in instabile, teilweise veränderte Zustände stürzt. Verbindungen garantieren Entwicklern: Wenn etwas kaputt ging, brach es vollständig, hinterließ ein leeres Blatt und wirkte sich in keiner Weise auf die Komponenten aus, die nicht an der Übung teilgenommen hatten.
Für diese Illustration habe ich das Bild von Kletterern gewählt, die mit einem Sicherheitsseil gebunden sind. Wenn Kletterer nur miteinander verbunden sind, befinden sie sich in einer miserablen Position. Jedes Mal, wenn ein einzelner Kletterer rutscht, stirbt der Rest des Teams sofort. Keine gute Möglichkeit, Geschäfte zu machen.
Stattdessen können Sie in Erlang angeben, dass einige Prozesse speziell sind, und sie mit dem Parameter trap_exit
markieren. Dann können sie Exit-Befehle empfangen, die über die Kommunikation gesendet werden, und diese in Nachrichten umwandeln. Auf diese Weise können sie Fehler beheben und möglicherweise einen neuen Prozess herunterladen, um die Arbeit des Verstorbenen abzuschließen. Im Gegensatz zu Kletterern kann ein spezieller Prozess dieser Art nicht verhindern, dass der Partnerschaftsprozess abfällt. Dies liegt bereits in der Verantwortung des Partners selbst, der beispielsweise mithilfe von try ... catch
Konstrukten implementiert wird. Der Prozess, der die Ausgaben abfängt, hat immer noch nicht die Möglichkeit, im Gedächtnis eines anderen zu spielen und es zu speichern, kann aber den gemeinsamen Tod vermeiden.
Dies wird zu einer entscheidenden Gelegenheit, Vorgesetzte zu schaffen. Wir werden sie sehr bald erreichen.

Bevor wir zu den Vorgesetzten übergehen, werfen wir einen Blick auf die wenigen verbleibenden Zutaten, mit denen wir erfolgreich ein System vorbereiten können, das Tropfen zu unserem eigenen Vorteil verwendet. Eine davon hängt mit der Funktionsweise des Prozessplaners zusammen. Der eigentliche Fall, auf den ich mich beziehen möchte, ist die Mondlandung von Apollo 11 [ Apollo 11 - ca. Übersetzer ].
Apollo 11 ist eine Mission, die 1969 zum Mond ging. Auf dem Bild sehen wir das Mondmodul mit Buzz Aldrin und Neil Armstrong an Bord, und das Foto wurde, glaube ich, von Michael Collins aufgenommen, der im Kommandomodul verblieb.
Auf dem Weg zur Landung auf dem Mond wurde das Modul von Apollo PGNCS (Primäres Leit-, Navigations- und Kontrollsystem) gesteuert [ Apollo PGNCS - Ca. Übersetzer ]. Das Steuerungssystem führte mehrere Aufgaben mit einer sorgfältig berechneten Anzahl von Zyklen aus [ CPU - ca. Übersetzer ] jeweils. Die NASA stellte außerdem fest, dass der Prozessor nicht mehr als 85% seiner Kapazität nutzen sollte, wobei 15% auf Lager sind.
Da die Astronauten einen zuverlässigen Backup-Plan für den Fall haben wollten, dass sie die Mission unterbrechen mussten, ließen sie das Radar des Meetings mit eingeschaltetem Befehls- und Servicemodul - es wäre praktisch. Dadurch wurde die verbleibende CPU-Leistung anständig belastet. Sobald Buzz Aldrin begann, Befehle einzugeben, erschienen Meldungen über Überlastung und tatsächlich über die Überschreitung der verfügbaren Rechenleistung. Wenn das System davon abgekommen wäre, wäre es wahrscheinlich nicht in der Lage gewesen, seine Arbeit zu erledigen, und alles hätte mit zwei toten Astronauten geendet.
Zuallererst trat die Überlastung auf, weil das Radar ein bekanntes Hardwareproblem hatte, was dazu führte, dass seine Frequenz nicht mit der Frequenz des Steuercomputers übereinstimmte, was zu einem "Diebstahl" einer viel größeren Anzahl von Zyklen führte, als dies sonst verwendet würde. Die Leute bei der NASA waren keine Idioten, und anstatt neue Technologien zu verwenden, die im wirklichen Leben nicht für eine so wichtige Mission getestet wurden, verwendeten sie bewährte Komponenten, die sie über seltene Fehler wussten. Vor allem aber haben sie eine Prioritätsplanung entwickelt.
Dies bedeutet, dass wenn dieses Radar oder möglicherweise die eingegebenen Befehle den Prozessor zu stark belasten, ihre Aufgaben beendet wurden, um den wichtigen Dingen, die eine höhere Priorität haben und sie wirklich benötigen, CPU-Zyklen zu geben. Es war im Jahr 1969. Heute gibt es viel mehr Sprachen und Frameworks, die nur kooperatives Versenden und nichts mehr anbieten.
Erlang ist keine Sprache, die für wichtige Systeme verwendet werden sollte, sondern berücksichtigt nur weiche Echtzeitbeschränkungen - ca. Übersetzer ] und keine strengen Echtzeitbeschränkungen, und daher wäre es keine gute Idee, sie für solche Szenarien zu verwenden. Aber Erlang bietet proaktive Planung [ sie ist präventive Planung, ca. Übersetzer ] und Priorisierung von Prozessen. Dies bedeutet, dass Sie als Entwickler oder Systemarchitekt nicht darauf achten müssen, dass zur Vermeidung von Einfrierungen absolut jeder die für seine Komponenten (einschließlich der verwendeten Bibliotheken) erforderliche CPU-Auslastung sorgfältig berechnet. Sie können einfach keine solche Macht bekommen. Und wenn Sie möchten, dass eine wichtige Aufgabe bei Bedarf ausgeführt wird, können Sie sie auch bereitstellen.
Dies scheint keine ernsthafte oder häufige Forderung zu sein, und die Leute veröffentlichen immer noch wirklich erfolgreiche Projekte, die ausschließlich auf der kooperativen Planung paralleler Prozesse basieren, aber es ist sicherlich äußerst wertvoll, da es Sie sowohl vor den Fehlern anderer als auch vor Ihren eigenen schützt. Es öffnet auch die Tür zu Mechanismen wie dem automatischen Lastausgleich, dem „Bestrafen von schlechten“ oder „Ermutigen von guten“ Prozessen oder dem Zuweisen höherer Prioritäten zu Prozessen mit mehr Aufgaben. All dies macht Ihre Systeme letztendlich anpassungsfähig genug für Lasten und unvorhergesehene Ereignisse.

Die letzte Komponente, die ich im Rahmen der Gewährleistung einer angemessenen Ausfallsicherheit erörtern möchte, ist die Fähigkeit, im Netzwerk zu arbeiten. In jedem System, das im Hinblick auf langfristige Aktivitäten entwickelt wurde, wird die Fähigkeit, auf mehr als einem Computer ausgeführt zu werden, schnell zu einer obligatorischen Anforderung. Sie möchten nicht mit Ihrem goldenen Auto an einem verschlossenen Ort hinter Titantüren sitzen und können Fehler, die hauptsächlich Ihre Benutzer betreffen, nicht kompensieren.
Früher oder später benötigen Sie zwei Computer, damit einer den Ausfall des zweiten und möglicherweise des dritten überlebt, wenn Sie einen Teil Ihres Systems während eines Ausfalls bereitstellen möchten.
Das Flugzeug in der Abbildung - F-82 Twin Mustang [ F-82 Twin Mustang - ca. Übersetzer ], ein Flugzeug, das während des Zweiten Weltkriegs entwickelt wurde, um Bomber über Entfernungen zu eskortieren, die die meisten anderen Kämpfer einfach nicht zurücklegen konnten. Er hatte zwei Kabinen, damit die Piloten das Gerät im Schichtbetrieb steuern konnten; Zum richtigen Zeitpunkt war es möglich, die Verantwortlichkeiten so aufzuteilen, dass ein Pilot das Flugzeug fliegen konnte und der zweite - Radar in der Rolle des Abfangjägers steuern konnte. Moderne Flugzeuge haben immer noch ähnliche Fähigkeiten; Sie haben unzählige doppelte Systeme und oft schlafen die Besatzungsmitglieder während des Fluges, so dass immer jemand bereit ist, bei Bedarf sofort die Kontrolle über das Flugzeug zu übernehmen.
Programmiersprachen oder Entwicklungsumgebungen sind größtenteils ohne verteilte Arbeit konzipiert. Es ist jedoch klar, dass Sie bei der Entwicklung eines Server-Stacks mit mehr als einem Server arbeiten müssen. Wenn Sie jedoch mit Dateien arbeiten möchten, gibt es in der Standardbibliothek Tools dafür. Das Maximum, das Ihnen die meisten Sprachen bieten können, ist Socket-Unterstützung oder ein HTTP-Client.
Erlang würdigt die Realität verteilter Systeme und bietet eine Implementierung für deren Erstellung an, die dokumentiert und transparent ist. , , - [ pylyglot systems — . ].

" ". - , . "Let it crash" , , .
— .

[ supervision trees — . ] — , . — , — — , . , — "OTP", , "Erlang/OTP" [ OTP — Open Telecom Platform — . ].
— , , , , , "" . , : , , .
, , , , — .

. " , ". , . .
. " " [ one for one — . *]. . , .
— " " [ one for all — . *]. , . , , . , . , . , , . , , !
, , , . , . : , .
, . — " " [ rest for one — . ]. , , . .
[ , — — . ] . 1 , 150 .

, , " , !"
. , , , . "" [ — . ] "" [ — . ], Jim Gray 1985 ( Jim Gray, !)
-, — , , . . , , . , , , , .
— , , , . , , . , , .
, , .

, — .
, . , , .
, — , , . , — ; . , , . , , , .
, , .
. , , [ Property-Based Testing Basics , Property-based testing — . ] ( ), — - , . , , , .

( ). , , .
, . , , , , . - -.
. , , , , , , .
, . Jim Gray, , , 132 , , . 131 132 , , . , , , , ; , , , 100 000 , — 10 , - .
, , .

?
, . . , . , , . , "" Facebook ( ), , , Facebook .
, , , , . , , .
, . : , , , , .
, ( ), , . , .

, , . , , , .
, , .

() . , : . Tally () , Live Reports ( ) .
, . District (; ) , (Storage). (Cache) ( ) (Worker pool).
[ supervision strategies — . ], , , , . , " ", , , . ( ) " ". , (OCR) , , . , , , , .
OCR , C , . , C, , , .
, , , . 10 , , , .
, , . , . — , .
, , , . OCR C , . OCR . . , , ( ). , , — , .
OCR , . , , — . — . , , , , - , .
, . , — - , - ( ) , . , — , . — let it crash!
. , if/else
, switch
', try/catch
. , , , . [ , — . ], .

, , , , . : , .
, , , . (, SMS).
, , , , , .

OTP. OTP- — , . , , . , , , . , , , .
, OTP- . OTP-, . [: OTP-, , ]
:
- , ;
- , , , ;
- , ;
- , , , , ;
- ( , );
- .
. , . , , . , — , , .

, ? , . , Heroku .
. (vegur) , , , . , , .
- , . , : 500 000 1 000 000 ! , . ? , , , 100 000 , ? - 1:17000 1:7000. , , , .
, . , , , . , . , , .

. .
, - : " , . , , , . , , . , ."
. .
, , , 60 . ( United 734), , , , - . , , , , ABS, .
( ), . , . , , .

, . ( , ) Richard Cook. , YouTube, .
- . , , , .. — ( , , ..) , , - , .
, , , . , , - - .
, , , . , . , . - - , , , .

, . , , : , . . , , , .
, , , . .

, , . , , , .
. , , , - , , , , , . , .

, 'let it crash' — , , , , , — , , , . . fail-fast , , " ", .
, . , , . . , , . Let it crash.

: , , , — . , ( , !) .