Gesaan dan persekitaran
Pengeluar menghantar CloudEvents dengan percubaan semula, muatan berversi dan trafik yang tidak sekata. Get laluan mesti mengesahkan sampul (envelope), mengasingkan penyewa, mengekalkan bukti penghantaran, dan menjadikan tingkah laku sekurang-kurangnya sekali (at-least-once) eksplisit kepada pengguna.
Perkara yang diuji oleh penemu duga
- Menukar sampul protokol kepada kontrak penyerapan dan penghantaran yang jelas.
- Memilih skop keidempotanan, keadaan percubaan semula dan sempadan serahan tahan lama (durable handoff).
- Mereka bentuk pengasingan penyewa, evolusi skema dan bukti operasi.
Soalan penjelasan sebelum menjawab
- Apakah peristiwa puncak sesaat dan saiz muatan yang mesti disokong oleh setiap penyewa?
- Adakah pengeluar dibenarkan mencuba semula tanpa had, dan adakah susunan diperlukan mengikut sumber (source) atau subjek (subject)?
- Pengguna manakah yang memerlukan penghantaran sekurang-kurangnya sekali, dan bolehkah mereka menyahduplikasi mengikut sumber serta ID?
- Adakah skema didaftarkan secara berpusat, dan berapa lamakah peristiwa mentah mesti disimpan untuk main semula (replay)?
Rangka kerja jawapan 30 saat
Saya akan menamatkan TLS pada pinggir yang disahkan, mengesahkan sampul CloudEvents dan kuota penyewa, kemudian menambah peristiwa mentah secara tahan lama sebelum membuat perakuan (acknowledgement). Baris gilir berpartition menyebarkan (fan-out) kepada pengguna menggunakan penghantaran sekurang-kurangnya sekali; (tenant, source, id) ialah kunci penyahduplikasian apabila pengeluar menjamin kestabilannya. Perakuan pengguna, jadual percubaan semula, surat mati (dead letters), versi skema dan had setiap penyewa menjadikan kehilangan dan penduaan kelihatan jelas dan bukannya tersirat.
Analisis mendalam langkah demi langkah
1. Serap dan sahkan
Terima pengikatan HTTP berstruktur atau binari, kuat kuasakan had saiz dan jenis kandungan, serta sahkan atribut yang diperlukan seperti specversion, type, source dan id. Sahkan penyewa dan tolak sampul yang tidak sah sebelum kerja tahan lama dilakukan. Kekalkan bait dan pengepala tepat yang diterima untuk audit dan main semula.
2. Pilih sempadan tahan lama
Tulis rekod peristiwa yang tidak boleh diubah (immutable) dan outbox atau ofset log dalam satu operasi tahan lama sebelum mengembalikan kejayaan. Perakuan baris gilir sahaja berisiko kehilangan peristiwa jika penerbitan baris gilir tidak dilakukan (committed); reka bentuk pangkalan data sahaja boleh menjadi hambatan (bottleneck) pada fan-out volum tinggi. Nyatakan pertukaran antara kependaman dan ketahanan.
3. Penyahduplikasian tanpa menyembunyikan percubaan semula
Gunakan kunci (source, id) berskopkan penyewa dengan tempoh pengekalan yang meliputi percubaan semula pengeluar. Simpan ringkasan (digest) muatan dan versi skema; kunci yang sama dengan bait berbeza merupakan konflik yang memerlukan kuarantin. Asingkan percubaan penghantaran daripada peristiwa logik supaya percubaan semula kekal boleh dicerap.
4. Hantar dan cuba semula
Pengguna menarik (pull) daripada partition atau menerima penghantaran yang ditolak (push) dengan pajakan (lease). Perakuan yang berjaya memajukan percubaan; tamat masa dan kegagalan sementara menjadualkan undur eksponen (exponential backoff) dengan jitter. Kegagalan kekal dipindahkan ke strim surat mati berskopkan penyewa dengan kawalan main semula dan rekod audit.
5. Evolusi dan operasi
Sahkan versi skema semasa masuk (ingress), halakan peristiwa yang tidak serasi ke kuarantin, dan sokong perisytiharan keupayaan pengguna. Ukur peristiwa yang diterima, ditolak, pendua, tertangguh, dicuba semula, dimasukkan ke surat mati dan dimainkan semula mengikut penyewa dan sumber. Kuat kuasakan kuota, penyulitan, pengekalan dan kawalan akses tanpa merekodkan rahsia atau muatan tanpa had ke dalam log.
Contoh jawapan berkualiti tinggi
“Saya akan mengesahkan setiap penyewa di pinggir, mengesahkan sampul CloudEvents, menguatkuasakan had saiz dan kuota, serta menambah peristiwa dan pengepala yang tepat secara tahan lama sebelum memperakui. Log berpartition kemudiannya menghantar sekurang-kurangnya sekali. Kunci penyahduplikasian ialah penyewa serta sumber serta ID apabila pengeluar menjamin kestabilan ID; digest yang diubah untuk kunci yang sama akan dikuarantin. Pengguna memperakui percubaan, kegagalan sementara berundur dengan jitter, dan kegagalan kekal pergi ke strim surat mati yang boleh dimainkan semula. Versi skema, metrik setiap penyewa, pengekalan dan log audit menjadikan semantik penghantaran eksplisit.”
Kesilapan lazim
- Membuat perakuan sebelum penambahan tahan lama → ranap sistem menyebabkan peristiwa hilang → buat ack selepas sempadan tahan lama yang dipilih.
- Penyahduplikasian mengikut ID secara global → penyewa atau sumber boleh bertembung → skopkan kunci dan sahkan digest.
- Menjanjikan tepat sekali (exactly-once) → percubaan semula dan kesan pengguna masih boleh berlaku → nyatakan sekurang-kurangnya sekali dan wajibkan pengguna idempoten.
- Menggugurkan skema yang tidak serasi → penyahpepijatan dan main semula menjadi mustahil → kuarantin dengan bukti berversi.
Soalan susulan dan respons
Bolehkah get laluan menjamin susunan?
Hanya dalam skop yang ditentukan, seperti partition sumber dan subjek. Kekalkan metadata jujukan, halakan kunci yang sama ke satu partition, dan dokumentasikan bahawa percubaan semula atau pengguna selari boleh menangguhkan peristiwa seterusnya.
Bagaimana jika pengeluar menggunakan semula ID untuk muatan yang berbeza?
Bandingkan digest yang disimpan dan tolak atau kuarantin konflik tersebut. Jangan sekali-kali menulis ganti peristiwa pertama secara senyap; maklumkan pengeluar kerana kontrak penyahduplikasian telah dilanggar.
Bagaimanakah anda menyokong main semula khusus penyewa?
Simpan rekod peristiwa yang tidak boleh diubah dengan token main semula terikat kebenaran, ID percubaan baharu, had kadar (rate limits) dan jejak audit. Main semula mesti melepasi pemeriksaan skema dan penyahduplikasian serta tidak boleh memintas pengasingan penyewa.