Der wahre Grund, warum Fogo heraussticht
Ich achte aus einem Grund auf Fogo, der nichts mit TPS-Screenshots oder Ranglistenvergleichen zu tun hat. Was mich interessiert, ist, wie ein SVM-basierter Layer 1 Entwickler zur Reife zwingt. Wenn Sie auf diesem Ausführungsmodell aufbauen, erhalten Sie nicht nur Geschwindigkeit. Sie betreten eine Umgebung, in der gutes State-Design belohnt wird und schlampige Architektur sofort offengelegt wird.
Geschwindigkeit wird real, wenn Anwendungen wichtig sind
Fogo ist um eine einfache Idee herum gestaltet. Wenn die Laufzeit wirklich schnell ist und in der Lage ist, unabhängige Transaktionen gleichzeitig zu verarbeiten, wird die Anwendung zum Flaschenhals. Dort wird es ernst. Der SVM fragt nicht, ob Ihre Marketingansprüche gut klingen. Er fragt, ob Ihre Transaktionen tatsächlich unabhängig sind, wenn echte Benutzer ankommen.
Warum parallele Ausführung nicht einfach ist
Parallele Ausführung klingt in der Theorie einfach. Transaktionen laufen zusammen. Die Kapazität steigt. Alles fühlt sich reibungslos an. In der Praxis funktioniert es nur, wenn Transaktionen nicht um denselben Zustand kämpfen. Auf einer SVM-Kette ist der Zustand explizit. Jede Transaktion muss deklarieren, was sie liest und was sie schreibt. Wenn diese Deklarationen überlappen, kann die Laufzeit sie nicht sicher parallel ausführen. Sie muss sie serialisieren.
Dein eigenes Design kann die Geschwindigkeit einschränken
Das bedeutet, dass die Kette schlechte Designentscheidungen nicht verbergen kann. Wenn du deine Anwendung so strukturierst, dass jede Aktion in dasselbe gemeinsame Konto schreibt, hast du einen Stau innerhalb eines Systems geschaffen, das für mehrere Spuren gebaut wurde.
Leistung lebt auf der Anwendungsebene
Das ist der Teil, den die Leute übersehen. Sie sprechen über Leistung, als ob sie vollständig auf der Kettenebene lebt. Auf Fogo wird die Leistung zur Verantwortung auf der Anwendungsebene. Zwei Apps können auf derselben Kette sitzen. Eine bleibt unter Last reibungslos. Die andere fühlt sich festgefahren an. Der Unterschied ist nicht die Laufzeit. Es ist, wie der Zustand partitioniert wurde.
Sequentielle Gewohnheiten können den Parallelismus töten
Entwickler, die von sequentiellen Systemen kommen, tragen oft Gewohnheiten mit sich, die sicher erscheinen. Eine der häufigsten ist die Pflege eines einzigen zentralen Zustandobjekts, das jede Aktion aktualisiert. Es fühlt sich sauber an. Es fühlt sich organisiert an. Es gibt dir eine Quelle der Wahrheit. Auf einer SVM-Kette wird dasselbe Muster zu einem stillen Drosselventil. Jeder Benutzer konkurriert jetzt darum, an denselben Ort zu schreiben. Die Laufzeit ist bereit für Parallelismus, aber die Anwendung zwingt alles in eine Spur.
Zustandslayout als Parallelitätsrichtlinie
Auf Fogo wird das Zustand-Layout zu einer Parallelitätsrichtlinie. Jedes beschreibbare Konto verhält sich wie ein Schloss. Wenn zu viele Flüsse von demselben Schloss abhängen, brichst du den Parallelismus zusammen, auch wenn das Netzwerk nicht überlastet ist. Die Verlangsamung kommt nicht von der Kette. Sie kommt von deiner eigenen Architektur.
Denke an beschreibbaren Zustand als Entscheidungen
Ein besseres mentales Modell ist folgendes. Jedes Stück beschreibbaren Zustands definiert, wer zur gleichen Zeit bewegen kann. Das Ziel ist nicht, den gemeinsamen Zustand vollständig zu eliminieren. Einige gemeinsame Daten sind notwendig. Das Ziel ist Disziplin. Trenne, was geteilt werden muss, von dem, was aus Bequemlichkeit geteilt wurde. Bequemlichkeit ist oft der Ort, an dem die parallele Ausführung stirbt.
Muster, die Apps schnell halten
Die Muster, die Anwendungen auf Fogo schnell halten, sind nicht auffällig. Sie sind streng.
Trenne den Benutzerzustand aggressiv
Isoliere marktspezifischen Zustand, anstatt alles durch ein einzelnes globales Objekt zu leiten
Vermeide das Schreiben in gemeinsame Konten nur, um Metriken oder Sichtbarkeitsdaten zu aktualisieren
Diese abgeleiteten Werte können oft aus Ereignissen berechnet werden, anstatt in jeder Transaktion mutiert zu werden.
Erfolgreiche parallele Designs
Sieh dir Designs an, die Stress gut bewältigen.
Benutzeraktionen sind größtenteils lokal
Ein Benutzer aktualisiert seinen eigenen Zustand und einen engen Schnitt von gemeinsamem Zustand, der wirklich erforderlich ist
Geteilte Komponenten sind so strukturiert, dass nicht verwandte Benutzer nicht kollidieren
Die Trennung pro Benutzer ist nicht nur eine ordentliche Organisation. Es ist eine Durchsatzstrategie. Die Trennung pro Markt verhindert, dass ein heißer Markt alles andere nach unten zieht.
Globale Berichterstattungstraps
Die subtile Falle ist die globale Berichterstattung. Entwickler lieben sofortige globale Zähler.
Gesamtvolumen
Globale Gebühren
Aktivitäts-Tracker
Ranglisten
Die Metriken selbst sind in Ordnung. Das Problem tritt auf, wenn jede Transaktion diese globalen Konten aktualisiert. Jetzt umfasst jeder Pfad einen gemeinsamen Schreibvorgang. Konflikte vervielfachen sich. Du hast ein sequentielles System innerhalb einer parallelen Laufzeit aufgebaut. Egal wie schnell Fogo ist, dein Design zwingt es, sich sequentiell zu verhalten.
Trennung von Korrektheit und Berichterstattung
Parallele Ausführung drängt die Entwickler, Korrektheit von Berichterstattung zu trennen.
Kritische Zustandsänderungen geschehen an einem Ort
Berichterstattung kann in einem anderen Rhythmus aktualisiert, sharded oder aus Protokollen abgeleitet werden
Sobald du aufhörst, jede Transaktion zu zwingen, dasselbe Berichterstattungskonto zu ändern, wird wahre Parallelität möglich.
Handels- und interaktive Systeme
Handelsysteme heben den Punkt hervor.
Handel konzentriert die Aktivität
Konzentration schafft Konflikte
Ein einzelnes zentrales Orderbuchkonto serialisiert alle Operationen
Hochfrequenzumgebungen machen Fehler unmöglich zu verbergen. Jedes gemeinsame beschreibbare Konto wird zu einem Schlachtfeld. Anstatt dass unabhängige Flüsse parallel vorankommen, wartet jeder hinter demselben Schloss. Die Leistung verschlechtert sich, und das Marktverhalten ändert sich, weil Konflikte die Reihenfolge dominieren.
Datenintensive Anwendungen
Lesevorgänge sind selten das Problem
Schreibvorgänge sind
Vermeide das Aktualisieren gemeinsamer Caches oder das Stempeln von Werten in globale Konten aus Bequemlichkeit
Halte gemeinsame Schreibvorgänge auf dedizierte Flüsse beschränkt
Die Kosten der parallelen Architektur
Nichts davon ist kostenlos. Parallelfreundliche Architektur erfordert:
Mehr Komponenten
Sorgfältigere Tests
Bessere Beobachtbarkeit
Du baust echte Parallelität, nicht theoretische Parallelität. Aber die Belohnung ist eine Skalierung, die dem entspricht, was die SVM-Laufzeit zu liefern entworfen wurde.
Der kostspieligste Fehler
Der schädlichste Fehler ist einfach. Ein gemeinsames beschreibbares Konto, das jede Transaktion berührt. Auf einer Kette wie Fogo wird dieser Fehler schnell offensichtlich. Je schneller die Kette, desto klarer wird, dass dein Design die Einschränkung ist.
Fogo macht das Gespräch ehrlich
Was Fogo tut, ist, das Gespräch der Entwickler ehrlich zu machen.
Es reicht nicht aus zu sagen, die Kette ist schnell
Das Ausführungsmodell verlangt von Entwicklern, für Unabhängigkeit zu entwerfen
Partitioniere den Zustand intelligent
Behandle den Zustand als eine Parallelitätsoberfläche
Fazit: Disziplin über Marketing
Parallele Ausführung ist kein Marketingmerkmal. Es ist eine Disziplin. Auf einer SVM-basierten Layer 1 wie Fogo wird diese Disziplin durch Design durchgesetzt.