Modul 10Penggal 3 · Kebolehpercayaan dan skala12 item poster

Ketepatan Sistem Teragih

Log masuk untuk menyimpan kemajuan anda merentas peranti. Sehingga itu, ia disimpan dalam pelayar ini.

Mengapa ini penting

Bug concurrency tidak muncul semasa demo. Ia muncul sebagai pelanggan yang dicaj dua kali, baucar yang ditebus tiga kali, satu tempat duduk dijual kepada dua orang, atau baki yang tidak sepadan pada hujung bulan. Dalam fintech, ini ialah peristiwa kawal selia, bukan sekadar bug.

Hasil pembelajaran

  1. Kenal pasti race condition dan baikinya dengan operasi atomik, constraint dan lock.
  2. Fahami replication, CAP dan eventual consistency dengan cukup baik untuk mereka UX di sekelilingnya.
  3. Ketahui bila distributed lock dan leader election diperlukan, serta perangkapnya.
  4. Elakkan deadlock.
  5. Kendalikan masa dengan betul walaupun ada clock skew.
  6. Diagnosis memory leak dan jeda garbage collection.

Pelajaran

10.1 Race condition (39, 43)

Bentuk klasiknya ialah check-then-act: baca nilai, buat keputusan, tulis. Di antara baca dan tulis, orang lain sudah bertindak. Pembaikan, mengikut keutamaan:

  1. Pernyataan atomik: UPDATE accounts SET balance = balance - 100 WHERE id = $1 AND balance >= 100 dan semak bilangan baris yang terjejas.
  2. Constraint pangkalan data: unique index menyebabkan insert kedua gagal.
  3. Optimistic locking (lajur versi) untuk persaingan rendah.
  4. Pessimistic lock (SELECT ... FOR UPDATE) untuk persaingan tinggi. Dalam kod aplikasi: state boleh ubah yang dikongsi dalam proses Node yang hidup lama dikongsi merentas request; pemboleh ubah peringkat modul bukan per pengguna. Thread safety (43) juga penting dalam Go, Java, Python async dan worker.

10.2 Deadlock (40)

Dua transaksi masing-masing memegang lock yang diperlukan oleh yang satu lagi. Elakkan dengan sentiasa mengunci sumber mengikut tertib yang konsisten (cth. mengikut ID menaik), memastikan transaksi pendek, dan menetapkan lock timeout. Postgres mengesan deadlock dan membatalkan salah satu; kod anda mesti retry.

10.3 Replication, CAP dan eventual consistency (32, 34, 35, 95)

  • Replication (32): salinan pada berbilang nod untuk ketahanan data dan skala bacaan. Replica async akan ketinggalan.
  • Network partition (95) memang berlaku. Semasa ia berlaku, CAP menyatakan sistem mesti memilih: menolak sesetengah request (consistency) atau menjawab dengan data yang mungkin basi (availability).
  • Eventual consistency (35): replica akan menumpu dari semasa ke semasa. Implikasi reka bentuk: read-your-own-writes (halakan bacaan pengguna ke primary sejurus selepas mereka menulis), tunjukkan keadaan "sedang diproses", jangan sekali-kali membuat keputusan melibatkan wang berdasarkan replica yang ketinggalan.
  • Lejar dan baki: strongly consistent, satu sumber kebenaran, rekod double-entry yang append-only.

10.4 Distributed lock dan leader election (33, 38)

  • Diperlukan apabila berbilang instance tidak boleh melakukan perkara yang sama serentak (satu pelari cron, satu consumer bagi satu partition).
  • Utamakan pilihan asli DB dahulu: Postgres advisory lock, queue job dengan SKIP LOCKED.
  • Lock Redis memerlukan tempoh luput (TTL) dan fencing token: proses yang terjeda mungkin bangun selepas lock-nya luput dan masih menulis. Lapisan storage mesti menolak token yang basi.
  • Leader election (Raft, etcd, ZooKeeper, Kubernetes lease) kebanyakannya sesuatu yang anda gunakan daripada infrastruktur, bukan yang anda bina sendiri.

10.5 Masa dan clock skew (96)

  • Jam mesin akan hanyut; jangan sekali-kali gunakan masa jam dinding daripada server berbeza untuk menyusun event.
  • Gunakan timestamp yang dijana DB atau nombor jujukan untuk penyusunan; jam monotonik untuk mengukur tempoh.
  • Semakan tempoh luput token dan timestamp webhook memerlukan toleransi skew yang kecil.

10.6 Memory leak dan garbage collection (41, 42)

  • Leak dalam bahasa terurus biasanya ialah rujukan yang anda simpan: cache yang membesar tanpa had, event listener yang tidak pernah dibuang, array global, stream yang tidak ditutup.
  • Simptom: memori meningkat secara berterusan, kemudian restart kerana OOM; lonjakan latency akibat jeda GC yang panjang.
  • Alat: heap snapshot (Chrome DevTools untuk Node), --inspect, metrik memori per instance, cache LRU yang terhad.

Makmal 10: Cabaran double-spend

  1. Bina dompet: tambah nilai, pindahan, pengeluaran. Tulis ujian yang melancarkan 200 pindahan serentak. Perhatikan versi AI yang naif kehilangan atau mencipta wang.
  2. Baiki dengan kemas kini atomik dan constraint; laksanakan sebagai lejar double-entry di mana jumlah semua entri sentiasa sifar.
  3. Cetuskan deadlock dengan dua pindahan bertentangan tertib; baiki dengan tertib penguncian.
  4. Baca daripada replica yang ketinggalan (kelewatan disimulasi) dan tunjukkan bug read-your-writes; baiki.
  5. Cari memory leak yang ditanam menggunakan heap snapshot.

Definition of Done

Pek prompt AI

  • "Cari setiap jujukan check-then-act dalam codebase ini. Untuk setiap satu, tunjukkan race-nya dan pembaikan atomiknya."
  • "Tulis semula logik baki ini sebagai lejar double-entry bersama ujian invarian."