Topik temu duga representatif

Temuduga Backend: Bagaimanakah Anda Akan Mereka Bentuk Request Hedging yang Selamat?

BackendSukar
Pasukan Editorial Offer.ccDiterbitkan Dikemas kini

Soalan

Satu API bacaan idempoten mempunyai pendam p99 yang tinggi manakala p50 adalah sihat. Reka bentuk request hedging: terangkan ambang pencetus, pemilihan replika, pembatalan, perlindungan beban, kebolehcerapan, dan bila untuk melumpuhkannya.

Gesaan dan konteks

Satu API bacaan idempoten mempunyai p99 yang tinggi manakala p50 adalah sihat; panggilan perlahan nampaknya berpunca daripada barisan gilir sekali-sekala atau gangguan kecil pada hos. Reka bentuk request hedging: hantar permintaan utama, keluarkan salinan ke replika lain selepas kelewatan, kembalikan hasil pertama yang boleh diterima, dan batalkan yang satu lagi. Terangkan sempadan kos dan amplifikasi kegagalan.

Perkara yang diuji oleh penemuduga

Fahami matlamat

Hedging menyasarkan pendam ekor; ia tidak menjadikan setiap permintaan lebih pantas. Ia sesuai untuk bacaan yang boleh diulang secara selamat dan tidak seharusnya menduplikasi operasi tulis dengan kesan sampingan secara membuta tuli.

Kawal kos

Menduplikasi setiap permintaan boleh menggandakan beban bahagian belakang hampir dua kali ganda. Reka bentuk yang kukuh menggunakan pencetus tertangguh, kiraan percubaan maksimum, pendikit (throttling), pembatalan, dan metrik berdasarkan permintaan asal.

Kendalikan kegagalan berkorelasi

Menghantar kedua-dua percubaan ke satu hos yang terlebih beban mempunyai sedikit nilai. Penghalaan rentas tika, zon, atau domain kegagalan ditambah perlindungan barisan gilir dan ralat menentukan sama ada hedging selamat.

Soalan untuk dijelaskan terlebih dahulu

  • Adakah API idempoten, dan bolehkah beberapa bacaan serentak diterima?
  • Apakah garis dasar p50, p95, p99, p99.9 dan SLO?
  • Adakah panggilan perlahan merupakan straggler yang terpencil atau masalah barisan gilir yang dikongsi oleh setiap replika?
  • Bagaimanakah replika dipilih merentas tika, zon, dan versi?
  • Adakah pembatalan benar-benar melepaskan benang, sambungan, dan pengiraan hiliran?
  • Kadar ralat, kedalaman barisan gilir, atau kadar pencetusan hedge manakah yang melumpuhkan dasar?

Jawapan 30 saat

"Saya akan mendayakan hedging hanya untuk bacaan idempoten. Hantar yang utama dahulu; gunakan ambang dinamik gaya p95 bagi setiap kelas permintaan, kemudian hantar satu hedge ke replika sihat dalam domain kegagalan lain hanya apabila ambang tamat dan belanjawan membenarkannya. Kongsi satu tarikh akhir, kembalikan kejayaan pertama, dan batalkan yang kalah. Hadkan percubaan, gunakan pendikit dan pengawal barisan gilir/ralat, serta pantau p99, kadar pencetusan, permintaan tambahan, kejayaan pembatalan, dan kependaman asal. Lumpuhkan dasar apabila ia menguatkan beban."

Jawapan mendalam langkah demi langkah

Tentukan mesin keadaan permintaan

Keadaan adalah primary_sent, hedge_waiting, hedge_sent, winner_selected, dan deadline_exceeded. Hantar yang utama dahulu; selesai jika ia kembali dalam ambang, jika tidak cipta satu hedge. Respons pertama yang berjaya menang dan semua percubaan lain menerima pembatalan.

Pilih ambang dan skop

Kekalkan histogram kependaman yang dikumpulkan mengikut kaedah, penyewa, saiz permintaan, atau panjang gesaan. Gunakan ambang dinamik gaya p95 dengan batas dan sandaran permulaan sejuk (cold-start). Jangan hanya gunakan min global atau menduplikasi setiap permintaan serta-merta.

Hala ke replika bebas

Elakkan hos, zon, atau domain kegagalan yang utama. Utamakan nod yang sihat dengan barisan gilir yang pendek. Jika setiap calon terlebih beban, hedging menambah kesesakan; sebaliknya tunggu, turunkan taraf (degrade), atau gagal dengan cepat (fail fast).

Kendalikan pembatalan dan tarikh akhir

Klien dan proksi mesti menyebarkan token pembatalan. Kerja hiliran mesti berhenti dan melepaskan sambungan, benang, GPU, atau cache. Kedua-dua percubaan berkongsi jumlah tarikh akhir supaya penduaan tidak memanjangkan masa menunggu yang dilihat oleh pengguna.

Lindungi kapasiti hiliran

Tetapkan maxAttempts, kelewatan hedge minimum, belanjawan dalam penerbangan (in-flight), dan token bucket bagi setiap perkhidmatan. gRPC mengehadkan maxAttempts kepada 5 dan menawarkan pendikit percubaan semula; reka bentuk pengeluaran masih memerlukan kapasiti dan belanjawan ralatnya sendiri.

Kendalikan ralat dan panggilan bukan idempoten

Teruskan hanya untuk kes yang boleh dicuba semula dan idempoten. Kembalikan ralat pengesahan atau pengesahan identiti deterministik dengan segera. Operasi tulis memerlukan kunci idempotensi dan penyahduplikasian, atau harus menggunakan satu permintaan ditambah pampasan.

Kod pseudo

~~~text send(primary) timer = hedgeThreshold(request_class) if primary unfinished at timer and budget_allows(): send(hedge, differentfailuredomain) winner = firstsuccessbefore_deadline() cancel(allotherattempts) record(primarylatency, hedgefired, winner, cancel_result) ~~~

Kerumitan, kebolehcerapan, dan pembalikan (rollback)

Kiraan percubaan terburuk dihadkan oleh maxAttempts; volum permintaan tambahan bergantung pada kadar pencetusan dan kependaman pembatalan. Jejaki p50/p95/p99, kadar pencetusan hedge, QPS tambahan, barisan gilir hiliran, ralat, kejayaan pembatalan, dan kependaman utama asal. Matikan dasar mengikut perkhidmatan, penyewa, atau wilayah apabila kesesakan atau ralat meningkat.

KawalanTujuanMod kegagalan jika salah dikonfigurasi
hedge delayDuplikasi hanya panggilan perlahanTerlalu pendek menguatkan QPS
maxAttemptsHadkan salinan serentakTerlalu tinggi mencipta ribut permintaan
cancellationBebaskan sumber yang kalahKegagalan terus menggunakan kapasiti
throttle budgetKetatkan semasa kesesakanMetrik yang hilang menyembunyikan beban berlebihan

Jawapan model

"Saya akan mengesahkan terlebih dahulu bahawa ini adalah bacaan idempoten dan membina histogram kependaman bagi setiap kelas permintaan. Selepas menghantar yang utama, saya akan menghantar satu hedge hanya selepas ambang gaya p95, replika bebas yang sihat, dan belanjawan keserentakan semuanya membenarkannya. Kedua-dua percubaan berkongsi satu tarikh akhir; kejayaan pertama menang dan proksi menyebarkan pembatalan sambil merekodkan sama ada sumber benar-benar dibebaskan. Percubaan maksimum, pendikit token, kedalaman barisan gilir, dan kadar ralat melindungi bahagian belakang, manakala ralat deterministik tidak pernah diduplikasi. Saya akan menggunakan pendekatan canary bagi dasar ini dan membandingkan p99, kadar pencetusan, QPS tambahan, kependaman pembatalan, dan kependaman utama tanpa hedging; ribut hedge akan melumpuhkannya secara automatik."

Kesilapan biasa

Menduplikasi setiap permintaan serta-merta

Itu mengubah hedging menjadi replikasi tanpa syarat, meningkatkan beban normal dan kos tanpa membuktikan bahawa straggler yang menyebabkan ekor kependaman.

Melakukan hedging pada operasi tulis yang mempunyai kesan sampingan

Dua percubaan boleh mencipta dua rekod atau mengenakan caj dua kali. Tanpa kunci idempotensi, penyahduplikasian, dan semantik transaksi, jangan lakukan hedging.

Menggunakan domain kegagalan yang sama

Kegagalan hos, rak, atau zon yang dikongsi memperlahankan kedua-dua percubaan dan menambah beban ke lokasi yang terlebih beban.

Hanya melihat p99 yang dilihat oleh pengguna

Hedging boleh menyembunyikan laluan utama yang semakin merosot dan melambatkan isyarat penskalaan. Rekod juga kependaman utama tanpa hedging dan kedalaman barisan gilir.

Mengabaikan pembatalan

Menghentikan penantian bukanlah menghentikan kerja hiliran. Sahkan penyebaran, pelepasan sumber, dan kependaman pembatalan.

Tiada suis pemati (kill switch)

Ralat yang tinggi, pembentukan barisan gilir, atau kadar pencetusan hedge yang tidak normal memerlukan suis pelumpuhan pantas di peringkat perkhidmatan, penyewa, atau wilayah.

Soalan susulan dan respons

Bagaimanakah hedging berbeza daripada retry?

Retry biasanya menunggu kegagalan sebelum menghantar semula. Hedging menghantar salinan selepas ambang kependaman sementara percubaan pertama masih berjalan. Kedua-duanya memerlukan keidempotenan, tarikh akhir, dan pendikit.

Mengapa bermula dengan p95?

Ia membiarkan sebahagian besar permintaan normal tidak disentuh sambil meliputi sebahagian kecil ekor kependaman. Ambang harus dilaraskan bagi setiap kelas permintaan, belanjawan, dan hasil eksperimen.

Bagaimana jika setiap replika mengalami kesesakan?

Hentikan hedging dan gunakan had kadar, barisan gilir, penurunan taraf (degradation), atau kegagalan pantas. Hedging tidak dapat membaiki kapasiti yang tidak mencukupi.

Bagaimanakah anda membuktikan pembatalan berfungsi?

Rekodkan pembatalan hiliran, penyelesaian kerja, penghunian sambungan, dan kependaman pelepasan. Suntik percubaan perlahan yang kalah dan sahkan ia berhenti selepas pemenang dipilih.

Bagaimanakah penstriman mengubah reka bentuk?

Gunakan masa untuk bait atau token pertama sebagai pencetus, tetapi menduplikasi selepas output bermula boleh mencipta data pendua. Tentukan penggabungan strim, pembatalan, dan keterlihatan klien terlebih dahulu.

Apakah tombol utama gRPC?

maxAttempts, hedgingDelay, dan kod status bukan maut mengawal bila salinan dihantar. gRPC mengehadkan percubaan kepada 5 dan menyediakan pendikit percubaan semula serta pushback pelayan; perkhidmatan ini masih memerlukan belanjawan kapasitinya sendiri.

Sumber awam

Soalan berkaitan