Temu Duga Backend: Bagaimanakah Timeout, Percubaan Semula (Retries), dan Circuit Breaker Sepatutnya Berfungsi Bersama?

Maklum Balas Segera dan Bila Soalan Ini Terpakai

Satu API daftar keluar memanggil perkhidmatan cukai pihak ketiga secara segerak. Kebergantungan ini biasanya mempunyai p50 80 ms dan p99 180 ms, tetapi ia sekali-sekala mengalami kegagalan sambungan, tindak balas perlahan, HTTP 429, 503, dan kes di mana permintaan mungkin telah sampai ke pelayan tetapi tindak balasnya hilang. API daftar keluar mempunyai sasaran hujung-ke-hujung 800 ms. Rantaian panggilan perkhidmatan mungkin sedalam lima lapisan, dan beberapa SDK mungkin sudah melakukan percubaan semula secara lalai.

Reka bentuk dasar panggilan tersebut. Terangkan cara membahagikan batas masa (deadline) kepada timeout bagi setiap percubaan, kegagalan mana yang boleh dicuba semula, cara menetapkan percubaan maksimum, exponential backoff, dan jitter, cara circuit breaker dibuka dan pulih, serta cara pengasingan, penurunan taraf (degradation), metrik, dan suntikan kegagalan (fault injection) membuktikan bahawa kegagalan setempat tidak akan menjadi kegagalan melata.

Kependaman (latency) dan kedalaman rantaian ialah andaian temu duga. Kemahiran teras adalah semantik kegagalan, perlindungan sumber, dan kawalan pemulihan untuk panggilan perkhidmatan-ke-perkhidmatan segerak, maka kategorinya ialah backend. Soalan pesanan idempoten yang sedia ada memfokuskan pada kontrak pangkalan data untuk satu operasi penulisan. Soalan ini menggunakan keidempotenan (idempotency) hanya untuk memutuskan sama ada mencuba semula selepas timeout adalah selamat; fokus utamanya ialah belanjawan masa dan beban merentasi rantaian panggilan.

Perkara yang Dinilai oleh Penemu Duga

Isyarat pertama ialah sama ada calon mencipta lejar masa. Batas masa hujung-ke-hujung 800 ms tidak bermaksud timeout kebergantungan adalah 800 ms. Pengesahan setempat, pembarisan gilir (queuing), pensirilan (serialization), dan kerja tindak balas semuanya memerlukan belanjawan masa. Setiap percubaan juga mesti mengambil kira fasa sambungan, TLS, dan tindak balas, dan percubaan semula yang lain hanya harus dimulakan jika masa yang mencukupi masih berbaki.

Isyarat kedua ialah mencuba semula mengikut semantik kegagalan. Kegagalan sebelum sambungan diwujudkan, 503 sementara, atau 429 dengan panduan percubaan semula mungkin boleh dicuba semula. Parameter yang salah, pengesahsahihan (authentication), dan kebenaran (authorization) tidak akan pulih dengan masa. Apabila operasi penulisan mengalami timeout selepas dihantar, hasilnya mungkin "telah dilakukan (committed) tetapi tindak balas tidak diketahui." Kunci keidempotenan yang stabil, carian status, atau proses penyesuaian (reconciliation) diperlukan sebelum percubaan semula selamat dilakukan.

Isyarat ketiga ialah penguatan percubaan semula (retry amplification). Jika setiap perkhidmatan dalam rantaian lima lapisan membuat sehingga tiga percubaan, kebergantungan paling bawah boleh menerima 3^5 = 243 panggilan. Percubaan semula harus berada pada satu lapisan yang memahami batas masa perniagaan, dengan had pada bilangan percubaan, jumlah masa yang berlalu, dan belanjawan percubaan semula berasaskan token.

Akhir sekali, penemu duga mahukan gelung pemulihan (recovery loop). Timeout mengehadkan tempoh satu penantian, percubaan semula mengendalikan kegagalan singkat, circuit breaker menolak panggilan semasa kegagalan berterusan, dan bulkhead mengehadkan keserentakan (concurrency) dan penghunian baris gilir. Jawapan yang mantap juga mengehadkan prob separuh terbuka (half-open probes), menolak fallback yang tidak jujur, dan memerhati panggilan logikal secara berasingan daripada percubaan fizikal.

Soalan untuk Dijelaskan Sebelum Menjawab

• Adakah panggilan kebergantungan itu operasi membaca atau menulis dengan kesan sampingan? Operasi membaca biasanya boleh diulang. Penulisan yang mengalami timeout mungkin mempunyai hasil yang tidak diketahui dan memerlukan kunci keidempotenan, carian status, atau penyesuaian.
• Adakah 800 ms merupakan batas masa tegar (hard deadline) atau sasaran pemerhatian? Di sini ia adalah titik masa selepas pemanggil tidak lagi menunggu. Pembatalan harus disebarkan ke hiliran (downstream) supaya kerja tidak diselesaikan untuk pemanggil yang sudah tiada.
• Ralat manakah yang diisytiharkan oleh kebergantungan sebagai boleh dicuba semula? Pengelasan mesti mengikut protokol dan kontrak vendor, terutamanya Retry-After pada 429, 503, kegagalan sambungan, dan ralat perniagaan. "Apa-apa selain 200" bukanlah satu dasar.
• Adakah SDK, proksi, atau service mesh sudah melakukan percubaan semula? Inventori nilai lalai dan had percubaan bagi setiap lapisan. Satu percubaan semula aplikasi yang kelihatan sebaliknya boleh berganda menjadi ribut percubaan semula (retry storm).
• Apakah taburan kependaman dan kapasiti kebergantungan? Dapatkan timeout daripada persentil, kadar timeout palsu yang dibenarkan, dan peruntukan rangkaian, kemudian sahkan sambungan baharu, trafik rentas rantau, dan beban puncak.
• Penurunan taraf (degradation) manakah yang boleh diterima? Jika pengiraan cukai mempunyai keperluan pematuhan, cukai lalai "berjaya" yang direka-reka adalah tidak selamat. Kegagalan eksplisit, semakan manual, atau daftar keluar tertangguh mesti mematuhi kontrak perniagaan.
• Apakah sempadan pengasingan circuit breaker? Gunakan vendor, rantau, titik akhir, atau operasi yang bebas. Satu shard yang gagal tidak sepatutnya memutuskan sambungan sumber yang sihat.

Rangka Kerja Jawapan 30 Saat

"Saya akan membahagikan batas masa hujung-ke-hujung 800 ms kepada belanjawan masa dan menyebarkan batas masa mutlak ke hiliran. Setiap panggilan mempunyai timeout sambungan dan permintaan, dan percubaan lain hanya dimulakan apabila ia muat dalam baki belanjawan masa. Saya mengelaskan kegagalan mengikut kebolehkelangsungan pemulihan dan sama ada kesan sampingan diketahui: patuhi panduan pelayan untuk 429, cuba semula hanya kegagalan sambungan singkat dan respons 5xx terpilih, serta perlukan keidempotenan atau penyesuaian status apabila hasil penulisan tidak diketahui. Percubaan semula diletakkan pada satu lapisan, menggunakan paling banyak dua percubaan dengan exponential backoff dan jitter yang dihadkan, serta menggunakan belanjawan token yang mengehadkan trafik tambahan semasa kegagalan. Kegagalan berterusan membuka litar dan gagal pantas (fail fast); selepas tempoh bertenang (cooldown), hanya beberapa prob separuh terbuka dibenarkan lalu. Had keserentakan berasingan dan baris gilir terhad melindungi sumber setempat. Suntikan kegagalan kemudian mengesahkan batas masa, kiraan percubaan, kesan duplikasi, dan laluan pemulihan."

Panduan Terperinci Langkah demi Langkah

Mulakan dengan menukar masa kepada belanjawan eksplisit. Dalam latihan ini, simpan 120 ms daripada 800 ms untuk kerja setempat sebelum panggilan kebergantungan dan 100 ms untuk memproses hasilnya. Ini meninggalkan belanjawan kebergantungan sebanyak 580 ms. Satu konfigurasi permulaan yang boleh diuji ialah percubaan pertama dihadkan pada 220 ms, backoff rawak dalam [0, 80) ms, dan percubaan kedua dihadkan pada 220 ms. Senario terburuk menggunakan 520 ms dan meninggalkan baki 60 ms dalam belanjawan kebergantungan. Ini bukan pemalar sejagat; nilai pengeluaran mesti ditentukur daripada persentil hiliran, timeout palsu yang dibenarkan, kelewatan rangkaian, dan ujian beban.

Sebarkan batas masa mutlak atau baki belanjawan yang berkurangan secara monotonik melalui rantaian panggilan. Sebelum mencuba semula, kira semula remaining. Jika ia lebih kecil daripada "had percubaan seterusnya + masa penyiapan minimum," pulangkan respons serta-merta daripada memulakan panggilan yang tidak dapat diselesaikan. Tentukan semantik timeout sambungan dan permintaan secara tepat, termasuk sama ada DNS, TLS, dan penantian kolam sambungan diliputi. Contoh baharu (new instance) boleh memanaskan sambungan sebelum menerima trafik supaya masa jabat tangan (handshake) tidak disalah anggap sebagai kebergantungan yang perlahan. Sebarkan pembatalan, sambil tetap menganggap ia boleh tiba selepas pihak jauh telah melakukan (committed) kerja tersebut.

Seterusnya, bina matriks semantik kegagalan:

Tiga pagar mengawal setiap percubaan semula: ralat boleh dicuba semula, masa mencukupi masih berbaki, dan belanjawan percubaan semula mempunyai token. Gunakan exponential backoff yang dihadkan dan jitter rawak untuk mengurangkan korelasi antara klien yang gagal secara serentak. Utamakan pemasaan percubaan semula arahan pelayan yang boleh digunakan apabila wujud. Kiraan percubaan maksimum merangkumi panggilan awal; reka bentuk ini bermula dengan dua jumlah percubaan. Baca perkataan SDK dengan teliti kerana maxAttempts = 2 dan "dua percubaan semula" masing-masing mungkin bermaksud dua jumlah panggilan dan tiga jumlah panggilan.

Lakukan percubaan semula pada satu lapisan yang paling memahami batas masa perniagaan. Jika kesemua lima lapisan membuat tiga percubaan, beban teori lapisan paling bawah akan meningkat sebanyak 243 kali ganda. Jejaki downstream_attempts / logical_requests sebagai faktor penguatan percubaan semula. Ia sepatutnya hampir kepada 1 dalam keadaan sihat dan dihadkan secara eksplisit semasa kerosakan. Baldi token (token bucket) atau kuota percubaan semula yang setara menyusut apabila kegagalan meningkat, kemudian menjeda percubaan semula atau membenarkannya pada kadar yang rendah, supaya klien berhenti menambah beban apabila kebergantungan berada dalam keadaan paling rentan.

Balut operasi kebergantungan khusus dalam circuit breaker. Keadaan tertutup (closed state) membenarkan panggilan dan mengukur kegagalan yang boleh diatribusikan serta panggilan perlahan melalui tetingkap gelongsor (sliding window) dengan saiz sampel minimum. Melepasi ambang akan membuka litar. Keadaan terbuka (open state) tidak memanggil kebergantungan dan serta-merta mengembalikan kegagalan yang boleh dikenal pasti atau penurunan taraf yang diluluskan oleh perniagaan. Selepas tempoh bertenang, keadaan separuh terbuka (half-open state) hanya membenarkan sebilangan kecil prob serentak. Kejayaan prob yang mencukupi akan menutup litar; kegagalan kritikal akan membukanya semula. Ambang diperoleh daripada ciri-ciri trafik dan pemulihan. "20 panggilan dan 50% kegagalan" hanyalah satu contoh, bukan pemalar sejagat.

Circuit breaker mempunyai kos. Keadaan mod (modal state) menjadikan ujian dan pemulihan lebih kompleks, tempoh bertenang yang panjang melambatkan pemulihan, dan sempadan yang terlalu umum boleh menyekat shard yang sihat. Rakam setiap peralihan keadaan, hadkan keserentakan prob separuh terbuka, dan skopkan breaker kepada domain kegagalan sebenar. Untuk kerosakan singkat dan berisiko rendah, timeout yang ketat, percubaan semula satu lapisan, dan kuota percubaan semula mungkin sudah mencukupi. Jangan tambah breaker semata-mata untuk menamakan corak (pattern) reka bentuk lain.

Sumber setempat masih memerlukan pengasingan. Berikan kebergantungan cukai had keserentakan, kolam sambungan, dan baris gilir terhadnya sendiri supaya panggilan perlahan tidak menggunakan setiap thread atau sambungan daftar keluar. Panggilan yang beratur juga menggunakan belanjawan batas masa; buang kerja yang tidak dapat diselesaikan apabila ia keluar dari baris gilir. Fallback mestilah jujur dan boleh diterangkan. "Cukai tidak tersedia buat sementara waktu" atau aliran kerja manual boleh diterima; menganggap cukai yang tidak diketahui sebagai sifar dan mengisytiharkan daftar keluar berjaya adalah tidak wajar.

Uji invarian di bawah keadaan kegagalan. Suntik penolakan sambungan, tindak balas perlahan 250 ms, 429 dengan nilai Retry-After berbeza, 503, ralat 400 yang tidak boleh dicuba semula, dan "penulisan dilakukan, tindak balas hilang." Pastikan bahawa satu permintaan logikal membuat paling banyak dua percubaan hiliran, jumlah kependaman tidak melebihi 800 ms, ralat kekal tidak dicuba semula, dan penulisan yang tidak diketahui tidak diduplikasi. Kemudian kekalkan kegagalan sehingga litar terbuka. Sahkan penolakan pantas, prob separuh terbuka yang terhad, penutupan berjaya selepas pemulihan, dan bulkhead yang tidak tepu.

Metrik pengeluaran mesti memisahkan panggilan daripada percubaan: kejayaan hujung-ke-hujung dan p95/p99, hasil dan kependaman setiap percubaan, timeout fasa sambungan berbanding fasa permintaan, penguatan percubaan semula, kadar pemulihan percubaan semula dan kependaman tambahan, baki belanjawan percubaan semula, keadaan breaker dan kiraan penolakan, hasil prob separuh terbuka, keserentakan kolam dan kedalaman baris gilir, serta konflik keidempotenan dan hasil penyesuaian. Kejayaan akhir semata-mata boleh menyembunyikan sistem yang membeli ketersediaan dengan tiga kali ganda trafik hiliran.

Contoh Jawapan Berkualiti Tinggi

"Pertama, saya akan mengesahkan bahawa ini adalah carian cukai segerak dan pemanggil berhenti menunggu selepas 800 ms. Jika saya memperuntukkan 120 ms untuk kerja sebelum panggilan dan 100 ms untuk pengendalian tindak balas, kebergantungan mendapat 580 ms. Dasar permulaan saya menggunakan dua jumlah percubaan: setiap satu boleh mengambil masa paling banyak 220 ms, dengan backoff berjitter sebanyak [0, 80) ms di antaranya. Sebelum setiap percubaan, saya menyemak baki batas masa yang disebarkan, supaya baris gilir yang panjang tidak mencetuskan panggilan kedua secara mekanikal.

Kegagalan memerlukan pengelasan. Kegagalan sebelum sambungan diwujudkan dan 503 sementara yang ditakrifkan oleh vendor boleh dicuba semula dalam belanjawan. Respons 429 mematuhi Retry-After, tetapi jika masa menunggu melebihi batas masa, saya gagalkannya serta-merta. Saya tidak mencuba semula 400, 401, atau 403. Jika operasi menulis keadaan, timeout selepas penghantaran bermaksud hasil tidak diketahui. Saya mesti menggunakan semula kunci keidempotenan atau membuat pertanyaan dan menyelaraskan status daripada mengeluarkan permintaan buta yang baharu.

Saya menyenaraikan percubaan semula dalam SDK, get laluan (gateway), dan service mesh, kemudian meletakkan percubaan semula pada satu lapisan yang boleh melihat batas masa perniagaan dan menguatkuasakan belanjawan percubaan semula token. Tiga percubaan pada setiap satu daripada lima lapisan boleh menguatkan panggilan paling bawah sebanyak 243 kali ganda, jadi saya memantau percubaan fizikal dibahagikan dengan permintaan logikal.

Untuk kegagalan berterusan, saya menskopkan circuit breaker mengikut vendor cukai dan operasi. Tertutup mengukur kadar kegagalan dengan sampel minimum, terbuka gagal dengan pantas, dan separuh terbuka hanya membenarkan beberapa prob sebelum pemulihan. Kebergantungan juga mendapat kolam keserentakan dan baris gilir terhad yang berasingan. Penurunan taraf hanya mengembalikan keadaan eksplisit yang diluluskan oleh perniagaan; ia tidak sekali-kali mereka-reka cukai sifar.

Akhir sekali, saya menyuntik kegagalan untuk mengesahkan had maksimum dua percubaan, sempadan 800 ms, tiada percubaan semula untuk ralat kekal, tiada penulisan pendua, dan pemulihan litar melalui prob terhad. Dalam pengeluaran, saya memerhatikan kejayaan logikal, hasil percubaan, penguatan percubaan semula, baki belanjawan, keadaan breaker, dan ketepuan bulkhead secara bersama-sama."

Kesilapan Lazim

• Menetapkan timeout kebergantungan kepada 800 ms penuh → Tiada masa berbaki untuk penyiapan setempat, dan kebergantungan terus memegang sumber selepas pemanggil berputus asa → Tolak belanjawan setempat dan rangkaian daripada batas masa serta sebarkan bakinya.
• Mencuba semula setiap tindak balas yang tidak berjaya → Ralat parameter dan kebenaran tidak akan pulih sendiri, jadi percubaan semula hanya menambah beban dan kependaman → Kelaskan mengikut protokol, kod ralat, dan hasil kesan sampingan.
• Membolehkan tiga percubaan pada setiap lapisan → Lima lapisan boleh menguatkan satu panggilan menjadi 243 percubaan lapisan bawah → Cuba semula pada satu lapisan yang sesuai dan ukur penguatan.
• Menghantar penulisan yang mengalami timeout sekali lagi dengan ID baharu → Percubaan pertama mungkin telah berjaya dilakukan, menyebabkan caj atau sumber pendua → Guna semula kunci keidempotenan atau buat pertanyaan dan selaraskan status.
• Menggunakan exponential backoff tanpa jitter atau had maksima (caps) → Klien masih boleh mencuba semula dalam gelombang yang disegerakkan → Hadkan percubaan dan masa yang berlalu, serta rawakkan kelewatan.
• Menganggap circuit breaker sebagai pengganti timeout → Panggilan yang sedang diproses masih menduduki thread, sambungan, dan baris gilir → Kekalkan timeout bagi setiap percubaan dan asingkan keserentakan.
• Memulihkan semua trafik sebaik sahaja separuh terbuka bermula → Kebergantungan yang baru pulih akan terbeban semula → Benarkan prob terhad dan perlukan kejayaan pemulihan yang eksplisit.
• Menggunakan satu breaker global untuk setiap vendor dan titik akhir → Satu kerosakan setempat menyekat sumber yang sihat → Skopkan keadaan breaker kepada domain kegagalan bebas.
• Sentiasa mengembalikan kejayaan daripada fallback → Data yang tidak diketahui dipersembahkan sebagai betul dan melanggar semantik perniagaan → Gunakan hanya penurunan taraf yang diluluskan dengan batasan yang jelas.
• Hanya memerhatikan kadar kejayaan akhir → Ribut percubaan semula boleh menyembunyikan kemerosotan hiliran buat sementara waktu → Perhatikan panggilan logikal, percubaan fizikal, kependaman tambahan, dan ketepuan.

Soalan Susulan dan Maklum Balas

Soalan susulan 1: Berapakah gandaan bagi p99 hiliran yang sepatutnya ditetapkan untuk timeout?

Tiada gandaan tetap. Pilih kadar timeout palsu yang boleh diterima, mulakan daripada persentil kependaman yang sepadan, dan tambah peruntukan untuk kelewatan rangkaian, panggilan rentas rantau, penetapan sambungan, dan anjakan kecil. Hasilnya mesti tetap muat dalam batas masa huluan (upstream). Apabila p99 hampir dengan p50, anjakan kependaman kecil boleh menyebabkan banyak timeout, jadi penimbal (padding) tambahan mungkin wajar. Sahkan sama ada DNS, TLS, dan penantian kolam sambungan disertakan dalam pemasa.

Soalan susulan 2: Adakah kedua-dua 429 dan 503 boleh dicuba semula?

Hanya secara bersyarat. Utamakan Retry-After untuk 429, tetapi masa menunggu dan percubaan lain mesti muat dalam baki belanjawan masa. Jika tidak, kembalikan kegagalan yang boleh dikenal pasti. Cuba semula 503 hanya apabila kontrak vendor menandakannya sebagai sementara. Kedua-duanya menggunakan belanjawan percubaan semula; kedua-duanya tidak sepatutnya mengubah isyarat pelayan yang terlebih beban menjadi lebih banyak trafik serta-merta.

Soalan susulan 3: Mengapakah kadar pemulihan percubaan semula yang tinggi masih boleh menunjukkan sistem yang tidak sihat?

Kejayaan akhir mungkin dibeli dengan beban dan kependaman tambahan. Jika 100 panggilan logikal menjana 180 percubaan hiliran, penguatan ialah 1.8. Apabila kebergantungan menghampiri kapasiti maksimum, 80% tambahan itu boleh melambatkan pemulihan. Nilaikan kadar pemulihan bersama-sama dengan penguatan, kependaman percubaan, kehabisan belanjawan, dan ketepuan hiliran.

Soalan susulan 4: Adakah anda masih memerlukan pengehadan kadar (rate limiting) atau bulkhead apabila litar dibuka?

Ya. Breaker menyekat panggilan baharu ke satu kebergantungan, tetapi permintaan setempat mungkin sudah berada dalam pemprosesan atau dalam baris gilir, dan kebergantungan lain masih boleh menggunakan sumber. Had keserentakan, kolam berasingan, dan baris gilir terhad mengawal kapasiti setempat; pengehadan kadar kemasukan mengawal beban baharu. Prob separuh terbuka juga memerlukan peruntukan bebas yang kecil berbanding kapasiti kongsi tanpa had.

Soalan susulan 5: Adakah menjadi masalah jika setiap contoh (instance) mengekalkan keadaan breaker sendiri?

Keadaan boleh menyimpang, tetapi keadaan kongsi yang kukuh menambah satu lagi kebergantungan segerak dan lebih banyak kependaman. Reka bentuk biasa memberikan setiap contoh konfigurasi dan keadaan setempat yang sama; pada trafik tinggi, setiap satu melihat sampel yang mencukupi dan isyarat kegagalan tersebar secara semula jadi. Contoh bervolum rendah atau domain kegagalan yang diselaraskan secara global mungkin mewajarkan penggunaan service mesh atau lapisan berpusat. Dalam mana-mana kes, nyatakan skop, saiz sampel, dan trafik tambahan maksimum semasa kegagalan.

Soalan susulan 6: Bilakah ini patut ditukar menjadi baris gilir tak segerak (asynchronous queue)?

Jika tindak balas HTTP tidak memerlukan hasil cukai, atau pemulihan boleh mengambil masa yang jauh lebih lama daripada batas masa pengguna, pemprosesan tak segerak adalah lebih sesuai. Kekalkan tugasan, kembalikan status yang boleh ditanya, dan biarkan pengguna (consumer) menggunakan dasar percubaan semula dan dead-letter sendiri. Baris gilir tidak menghapuskan kebimbangan mengenai keidempotenan, tamat tempoh, atau penurunan taraf, tetapi ia memindahkan pemulihan yang panjang keluar daripada sambungan segerak dan belanjawan 800 ms.

Soalan susulan 7: Bagaimanakah anda akan melancarkan ini tanpa insiden konfigurasi?

Mulakan dengan merakam keputusan timeout, percubaan semula, dan litar yang sepatutnya dibuat, tanpa menambah percubaan semula sebenar atau menolak trafik. Sahkan bahawa SDK tidak menyembunyikan percubaan tambahan. Kemudian buat peluncuran kenari (canary) mengikut vendor atau beberapa contoh, hadkan belanjawan percubaan semula global, dan sediakan suis penyahdayaan pantas. Perhatikan volum percubaan, kependaman ekor (tail latency) hujung-ke-hujung, tempoh terbuka, kegagalan separuh terbuka, dan kapasiti kebergantungan sebelum mengembangkannya.