Git in jedem Maßstab

kurz gesagt

Vicent Martí erklärt, wie Cursors Continuity Git-Hosting skaliert: Repositories liegen auf schnellen lokalen Platten, aber ein Write-Ahead-Log in S3 ist die Quelle der Wahrheit. Er beginnt damit, warum Hosting mit wachsendem Traffic und wachsender Repository-Zahl schwieriger wird. Continuity bestätigt einen Push erst, nachdem er im Log gelandet ist, und Compare-and-Swap-Updates halten diese Schreibvorgänge in Reihenfolge. Jeder Read prüft zuerst das Log, jeder Server kann ein Replikat daraus neu aufbauen, und nur der Primary kompaktiert. Ein ausgelastetes Monorepo kann auf Hunderten Replikaten laufen, während kleine von Agenten erstellte Repositories jeweils eines bekommen oder im Leerlauf keines.

ideen

• Packfiles bestimmen die Serverarchitektur. Git-Clients tauschen Packfiles aus, und lokale Git-Operationen führen verknüpfte logische und physische Walks durch sie hindurch; Speicherdesigns müssen ihr Zugriffsmuster respektieren.
• Die falsche Schicht zu verteilen verstärkt die Latenz. Objektspeicher verwandeln Graph-Traversal in sequenzielle Netzwerk-Roundtrips, während Netzwerk-Dateisysteme wahlfreien Packfile-Zugriff in Remote-I/O verwandeln.
• GitHubs Spokes erkauft Konsistenz mit einem festen Replikationspreis. Three-Phase-Commit hält jedes Replikat aktuell, aber mehr Replikate erhöhen die Tail-Latenz, und jedes kalte Repository braucht trotzdem ein Quorum.
• Verlagere die dauerhafte Wahrheit aus dem servierenden Replikat. Continuity zeichnet jeden Push in einem S3-gestützten Write-Ahead-Log auf und behandelt lokale NVMe-Repositories dann als materialisierte Caches, die sich überall neu aufbauen lassen.
• Mache unzuverlässige Beschleunigung sicher. Gossip beschleunigt die Replikation, bedingte S3-Reads beweisen Frische, und die WAL-Kompaktierung lässt Replikate vorbereitete Packs laden statt CPU-schwere Repacks zu wiederholen.

zitate aus der Quelle