Soalan dan bila ia diguna pakai
Reka bentuk aliran mesej tak segerak di mana mesej memasuki dead-letter queue (DLQ) selepas percubaan semula yang terhad dan pengendali boleh memainkan semula mesej terpilih selepas membetulkan puncanya. Terangkan pengasingan, penyiasatan, pemilihan kelompok, kesan sampingan pendua dan perlindungan untuk trafik normal.
Topik temu duga pembangunan perisian Amazon menekankan penggunaan pengetahuan untuk menyelesaikan masalah. AWS mendokumenkan DLQ sebagai pengasingan untuk mesej yang tidak digunakan dengan had percubaan semula dan penggera; Google Pub/Sub mendokumenkan dead-letter topics dan semantik main semula atau carian (seek). Kuncinya ialah gelung pemulihan operasi, bukan rajah barisan giliran semata-mata.
Perkara yang dinilai oleh penemu duga
- Pengelasan ralat fana, mesej racun (poison messages), penolakan perniagaan dan luput.
- Metadata untuk versi, penyewa (tenant), sekatan (partition), surihan (trace), percubaan dan sebab kegagalan.
- Kawalan main semula: keidempotensian, skop, kadar, kelulusan dan syarat henti.
- Penyusunan tertib, pengekalan, penghantaran pendua dan semantik at-least-once.
- Metrik yang membuktikan pemulihan dan bukannya sekadar memindahkan mesej kembali.
Soalan untuk dijelaskan sebelum menjawab
- Adakah penghantaran adalah at-least-once, at-most-once atau exactly-once pada peringkat perniagaan?
- Kegagalan yang manakah boleh dicuba semula?
- Berapa lamakah mesej dikekalkan dan bilakah ia kehilangan nilai?
- Adakah susunan tertib diperlukan untuk kunci agregat?
- Bolehkah pengguna menghasilkan kesan sampingan yang idempoten?
- Siapakah yang boleh memeriksa, memainkan semula atau memadam mesej?
- Apakah SLO normal, kapasiti barisan giliran dan kapasiti main semula?
- Adakah main semula yang gagal memasuki DLQ yang sama atau replay-DLQ?
Rangka kerja jawapan 30 saat
"Saya mentakrifkan semantik penghantaran, pengekalan dan kunci penyusunan tertib terlebih dahulu. Ralat yang boleh dicuba semula menggunakan backoff terhad; mesej racun dan penolakan perniagaan dihantar ke DLQ dengan sebab, percubaan, versi dan ID surihan. Selepas pembetulan, pengendali mencipta kelompok main semula yang diskopkan, mengesahkan sampel secara berasingan dan memainkan semula pada kadar terhad. Pengguna melindungi kesan sampingan dengan kunci keidempotensian. Saya memantau usia DLQ, kegagalan main semula, pendua dan kependaman hiliran, serta menjeda apabila ambang dilangkaui."
Jawapan mendalam, langkah demi langkah
Langkah 1: Takrifkan mesin keadaan kegagalan
Asingkan keadaan normal, cuba semula, DLQ, pembetulan manual dan replay-DLQ. Kegagalan perniagaan kekal tidak boleh dicuba semula selama-lamanya.
Langkah 2: Takrifkan metadata mesej
Kekalkan ID peristiwa, kunci keidempotensian perniagaan, masa penciptaan, penyewa atau sekatan, versi skema, percubaan, ID surihan asal dan kelas ralat. Kekalkan muatan asal secara tidak boleh diubah (immutably).
Langkah 3: Tetapkan peraturan cuba semula dan DLQ
Pilih penerimaan maksimum, backoff dan pengekalan. AWS SQS mendokumenkan kekangan barisan giliran sumber dan Region serta mengesyorkan penggera DLQ. Mesej yang luput atau dibatalkan memerlukan pelupusan yang diaudit.
Langkah 4: Jadikan main semula selamat
Permintaan main semula merangkumi penapis, versi pengguna sasaran, had kadar, saiz kelompok, pelulus dan tempoh luput. Sahkan sampel terlebih dahulu, kemudian mainkan semula secara berkelompok. Asingkan kapasiti main semula daripada trafik normal.
| Kawalan | Tujuan | Tindakan kegagalan |
|---|---|---|
| Kunci keidempotensian | Mengelakkan kesan sampingan pendua | Tolak atau kembalikan hasil terdahulu |
| Had kadar | Melindungi pengguna dan kebergantungan | Jeda main semula |
| Skop kelompok | Mengehadkan radius impak | Sempitkan penapis |
| Kelulusan dan audit | Menetapkan kebertanggungjawaban | Sekat tindakan yang tidak dibenarkan |
| Replay-DLQ | Mengasingkan kegagalan berulang | Cipta kelompok diagnosis baharu |
Langkah 5: Kendalikan penyusunan tertib dan keserentakan
Apabila susunan tertib penting, lakukan sekatan mengikut kunci agregat dan halang pengguna normal dan pengguna main semula daripada memproses kunci yang sama secara serentak. Jangan mendakwa penghantaran exactly-once hujung ke hujung daripada barisan giliran sahaja.
Langkah 6: Lindungi kesan sampingan
Gunakan ID peristiwa atau kunci keidempotensian perniagaan untuk penulisan bersyarat. Pembayaran dan e-mel memerlukan kunci permintaan idempoten dan carian hasil; memadam mesej bukanlah satu rollback.
Langkah 7: Beroperasi dengan kebolehcerapan
Pantau kedalaman DLQ, usia tertua, kelas ralat, daya pemprosesan main semula, kegagalan main semula, kesan pendua dan kependaman hiliran. Rekodkan pengendali, sebab, skop, pemasaan, hasil dan peristiwa henti bagi setiap kelompok.
Langkah 8: Peruntukkan kapasiti dan henti dengan selamat
Anggarkan kapasiti main semula dan pastikan pengguna baharu serasi dengan skema lama. Jeda apabila punca belum dibetulkan, kebergantungan terbeban atau kadar pendua meningkat; kekalkan bukti.
Contoh jawapan berkualiti tinggi
"Ini ialah aliran peristiwa pesanan at-least-once. Had masa tamat rangkaian dicuba semula sehingga lima kali dengan backoff; ralat skema, kegagalan kebenaran dan peristiwa luput memasuki DLQ. Setiap mesej mengekalkan ID peristiwa, ID pesanan, penyewa, versi skema, masa mula dimasukkan ke barisan giliran, percubaan, kelas ralat dan ID surihan.
Selepas pembetulan, pengendali memilih penyewa dan tetingkap masa, versi sasaran, had kadar, pelulus dan tempoh luput. Lima puluh mesej disahkan dalam pengguna yang diasingkan, kemudian main semula dijalankan pada kadar sepuluh peratus daripada trafik normal. Keadaan pesanan menggunakan penulisan bersyarat berkunci ID peristiwa, dan permintaan pembayaran menggunakan semula kunci keidempotensian perniagaan. Pemprosesan normal dan main semula untuk satu pesanan tidak boleh dijalankan secara serentak.
Makluman merangkumi usia tertua, kegagalan main semula, penulisan pendua dan kependaman kebergantungan. Sebarang ambang akan menjeda kelompok dan menghalakan kegagalan berulang ke replay-DLQ. Rekod kelompok mengandungi penapis, versi, pengendali, hasil dan sebab berhenti."
Kesilapan biasa
- Menganggap DLQ sebagai tong sampah tanpa bukti.
- Mencuba semula mesej racun selama-lamanya.
- Memasukkan semula ke barisan giliran tanpa skop, kelulusan atau kawalan kadar.
- Menganggap barisan giliran menyediakan exactly-once hujung ke hujung.
- Mengabaikan keidempotensian dan menghasilkan caj atau e-mel pendua.
- Mengabaikan kunci penyusunan tertib.
- Memantau panjang barisan giliran sahaja.
- Berkongsi kapasiti antara main semula dan trafik normal tanpa perlindungan.
Soalan susulan dan cara menjawab
Susulan 1: Mengapa tidak menambah percubaan semula?
Percubaan semula sesuai untuk ralat fana; mesej racun dan kegagalan perniagaan kekal memakan kapasiti. Tetapkan had berdasarkan jenis kerosakan, pengekalan dan kos menunggu perniagaan.
Susulan 2: Bagaimanakah anda mengekalkan susunan untuk satu pesanan?
Lakukan sekatan mengikut kunci pesanan, sekat pemprosesan normal dan main semula yang serentak, serta terangkan cara peralihan keadaan menolak peristiwa lapuk.
Susulan 3: Bagaimana jika kebergantungan tidak idempoten?
Gunakan penyahduplikasian tempatan dan carian hasil; jika tidak, perlukan penyesuaian manual, pampasan atau mekanisme keidempotensian penyedia.
Susulan 4: Bagaimana jika main semula gagal lagi?
Hantarkannya ke replay-DLQ yang berasingan, kekalkan kelompok asal dan ralat baharu, jeda penapis yang terjejas dan maklumkan kepada pemilik.
Susulan 5: Bagaimanakah anda memilih kadar main semula?
Gunakan kapasiti pengguna, kuota kebergantungan, ruang simpanan (headroom) normal dan masa pemulihan. Lakukan ujian beban pada kelompok kecil sebelum meningkatkan kadar.
Susulan 6: Bilakah anda boleh membuang mesej?
Hanya selepas keputusan perniagaan yang jelas bahawa ia telah luput, dibatalkan atau tidak bernilai, dengan bukti audit dan sebab yang dikekalkan.