🌐 Diese Lektion ist derzeit nur auf Chinesisch verfügbar. Englische und deutsche Übersetzungen sind für Woche 46 geplant.

365 Tage zum Full-Stack · PHASE 1 · WEEK 1

Tag 1 - Wie bedient ein Backend-Server viele Personen gleichzeitig?

Zeit: 3 Stunden (Lernen 50 min + Praktisch 100 min + Notizen 30 min) · Thema: Concurrency-Modelle — das erste Fundament der Backend-Welt · Sprache: Node.js (nur ein Werkzeug; Konzepte sind das Wichtige)

🍜 Die Nudelsuppen-Analogie: Warum Backend Concurrency braucht

Du eröffnest eine Nudelsuppen-Bar. Stoßzeit: 100 Kunden strömen gleichzeitig herein. Du hast einen Herd. Was machst du?

Das ist das Kernproblem der Backend-Concurrency: Wie viele Anfragen mit begrenzten Ressourcen bedienen?

📇 Konzeptkarte: Concurrency ≠ Parallelismus

Concurrency: Eine Person (Server) jongliert viele Aufgaben, indem sie zwischen ihnen wechselt. Sieht aus wie Multitasking.
Parallelismus: Viele Menschen arbeiten exakt gleichzeitig. Braucht mehrere Kerne.

Node.js nutzt Concurrency (eine Person, viele Aufgaben). Java/C# nutzen Parallelismus (viele Threads). Go nutzt leichte Concurrency (Goroutines).

👥 Drei Personalpläne = Drei Concurrency-Modelle

Plan A: Viele Mitarbeiter einstellen (Multithreading)

Ein Thread pro Anfrage. Java/C#-Tradition. Problem: teuer, skaliert nicht über tausend Anfragen hinaus.

Plan B: Ein intelligenter Kellner (Event Loop)

Eine Person. Nie untätig. Nimmt Bestellungen auf, gibt sie an die Küche (Callbacks), kommt zurück wenn fertig. Node.js-Art. Skaliert zu Millionen.

Plan C: Leichte Coroutines

Tausende billige "Fibers". Goroutines von Go. Wechseln Kontext blitzschnell.

Fazit: Concurrency ist eine Runtime-Strategie, keine Sprachwahl. Du kannst es in jeder Sprache so machen. Node.js wählt Event Loop, weil es das Billigste für I/O-lastige Arbeit ist.