Wawancara rekayasa data: bagaimana Anda memulihkan pesan Redis Stream yang macet tanpa efek samping duplikat?

Perintah dan konteks

Tugas pesanan ditulis ke Redis Stream dan dikonsumsi oleh beberapa worker dalam satu consumer group. Worker dapat mengalami crash setelah API eksternal berhasil tetapi sebelum XACK, meninggalkan pesan di Pending Entries List (PEL). Pewawancara meminta Anda untuk memulihkannya tanpa efek samping duplikat, percobaan ulang tanpa batas, atau kehilangan data secara diam-diam.

Hal ini menguji semantik pengiriman stream-processing dan desain pemulihan. XREADGROUP mencatat pesan yang sudah terkirim tetapi belum diakui di PEL; XACK hanya mengakui pemrosesan ke grup. XAUTOCLAIM mentransfer pesan tertunda yang idle ke konsumen, tetapi tidak membuat operasi bisnis menjadi idempoten.

Apa yang dievaluasi pewawancara

• Apakah Anda menjelaskan entri baru, entri tertunda, PEL, dan kepemilikan konsumen.
• Apakah Anda menetapkan peran yang tepat untuk XACK, XPENDING, XCLAIM, dan XAUTOCLAIM.
• Apakah klaim, efek samping, dan acknowledgment membentuk urutan yang dapat dicoba ulang (retryable).
• Apakah kunci idempotensi, jumlah percobaan ulang, dan dead-letter stream menangani pesan beracun.
• Apakah Anda memantau waktu idle, jumlah pengiriman, ukuran PEL, dan latensi pemulihan.

Pertanyaan untuk diklarifikasi terlebih dahulu

• Efek samping apa yang ditimbulkan oleh satu pesan? Penagihan, pemenuhan (fulfillment), dan notifikasi memiliki risiko duplikasi yang berbeda.
• Apakah ada kunci idempotensi dan penyimpanan status otoritatif? Tanpa hal tersebut, “at least once” tidak aman.
• Berapa lama worker boleh idle sebelum diklaim kembali? Ambang batas harus melebihi pemrosesan normal dan jitter jaringan.
• Bisakah Stream dipangkas (trimmed) atau dihapus? Payload yang hilang memerlukan metrik dan peringatan tersendiri.
• Apakah Anda menggunakan Redis 8.4 XREADGROUP CLAIM, atau alur scan-and-claim yang kompatibel untuk versi yang lebih lama?

Kerangka jawaban 30 detik

“Saya akan mendefinisikan pengiriman at-least-once dan menjaga idempotensi bisnis di luar Stream. Worker membaca dengan XREADGROUP, mengomit status bisnis yang idempoten, dan baru setelah itu melakukan XACK. Worker pemulihan memindai PEL dan menggunakan XAUTOCLAIM untuk entri yang idle melebihi ambang batas aman. Ini membatasi percobaan ulang berdasarkan jumlah pengiriman dan jenis kesalahan, mengirim pesan beracun ke dead-letter Stream, serta memantau PEL, waktu idle, jumlah klaim, latensi acknowledgment, dan supresi duplikat.”

Jawaban mendalam

Gambarkan siklus hidup pesan

XADD menambahkan entri ke Stream. XREADGROUP mengirimkannya dan mencatatnya di PEL konsumen tersebut. Setelah pemrosesan bisnis berhasil, XACK menghapusnya dari PEL grup. Jika worker mengalami crash terlebih dahulu, worker lain dapat mengklaimnya setelah kondisi idle terpenuhi.

Tetapkan ambang batas idle yang aman

min-idle-time untuk XAUTOCLAIM harus melebihi p99 pemrosesan normal, percobaan ulang dependensi yang wajar, dan jitter jaringan. Jika tidak, worker yang lambat namun sehat dapat diklaim kembali saat masih bekerja. Pindai dengan kursor yang dikembalikan hingga 0-0, lalu mulai siklus lain dari awal karena entri yang sebelumnya terlalu baru dapat menjadi memenuhi syarat nantinya. Ambang batas ini adalah parameter operasional, bukan default Redis yang universal.

Urutan klaim dan acknowledgment

Setelah worker pemulihan mengklaim sebuah entri, periksa status berdasarkan ID pesan atau kunci idempotensi bisnis sebelum memanggil efek samping eksternal. Tulis hasil yang berhasil dan status selesai, lalu jalankan XACK. Jika penulisan status dan panggilan eksternal tidak dapat berbagi satu transaksi, catat niat (intent), hasil, dan tugas kompensasi. Akui bahwa percobaan ulang dapat mengulangi panggilan; jangan jadikan XACK sebagai bukti bahwa commit bisnis telah terjadi.

Menangani duplikat dan klaim konkuren

Beberapa worker pemulihan dapat memindai secara bersamaan, dan percobaan ulang jaringan dapat bersaing dengan klaim. Terapkan idempotensi pada ID pesanan, ID permintaan pembayaran, atau kunci bisnis. Izinkan hanya transisi status yang valid seperti pending ke processing lalu ke completed. Duplikat yang membaca status completed dapat diakui dan dihitung sebagai tersupresi tanpa menagih kembali. Jumlah pengiriman saja tidak dapat mengidentifikasi duplikat bisnis.

Mengisolasi pesan beracun

Setiap pengiriman meningkatkan hitungan pengiriman (delivery count). Kegagalan persisten dapat berasal dari payload yang salah bentuk (malformed), aturan bisnis permanen, atau dependensi yang tidak tersedia. Klasifikasikan kesalahan: input yang salah bentuk dapat langsung masuk ke dead-letter; dependensi sementara menggunakan backoff; entri yang melebihi ambang batas percobaan ulang dipindahkan ke dead-letter Stream dengan ID asli, kesalahan terakhir, jumlah percobaan, dan kunci bisnis. Berikan pemilik dan prosedur kompensasi untuk alur dead-letter.

Menangani entri yang dipangkas atau dihapus

Jika payload Stream dari entri tertunda telah dipangkas atau dihapus dengan XDEL, XAUTOCLAIM dapat menghapus ID dari PEL tanpa mengirimkan kembali payload. Metrik pemulihan harus membedakan antara “dicoba ulang dan selesai” dengan “payload tidak lagi ada”. Untuk pesanan, rencanakan retensi, pengarsipan, atau penyimpanan payload eksternal agar ID yang dibersihkan tidak dilaporkan sebagai keberhasilan bisnis.

Memantau kualitas pemulihan

Pantau ukuran PEL, waktu idle maksimum, rasio klaim, distribusi jumlah pengiriman, latensi XACK, volume dead-letter, dan hitungan supresi idempotensi per grup. Peringatan harus mencakup stream, grup, konsumen, dan kunci bisnis. Matikan worker selama uji coba terkontrol dan verifikasi bahwa efek samping hanya selesai sekali dan entri pada akhirnya diakui atau masuk ke dead-letter; keberhasilan perintah saja tidak cukup.

Contoh jawaban berkualitas tinggi

“Saya akan menggunakan pengiriman at-least-once dan menyimpan status idempotensi pesanan di penyimpanan bisnis. Worker membaca dengan XREADGROUP, menandai pesanan sedang diproses, memanggil dependensi, menulis hasil dan status selesai, dan baru setelah itu mengirimkan XACK. Crash di antara langkah-langkah tersebut akan meninggalkan entri di PEL.

Worker pemulihan menggunakan XAUTOCLAIM untuk entri yang idle melebihi p99 normal ditambah jitter. Worker memeriksa kunci pesanan atau permintaan pembayaran: entri yang telah selesai diakui dan dihitung sebagai tersupresi; entri yang belum selesai melanjutkan alur kerja. Kesalahan format dan kesalahan permanen tidak akan berulang tanpa henti; kesalahan dependensi sementara melakukan backoff, dan entri yang melebihi ambang batas pengiriman masuk ke dead-letter Stream beserta ID asli dan konteks kesalahannya.

Saya akan memantau PEL, waktu idle, jumlah klaim, latensi acknowledgment, dead letter, dan supresi duplikat, lalu melakukan latihan pemangkasan, crash worker, dan batas waktu dependensi. Jika XAUTOCLAIM membersihkan ID yang payload-nya sudah hilang, Redis hanya menyatakan bahwa payload tidak tersedia; hal itu tidak membuktikan bahwa pesanan berhasil. Retensi atau pengarsipan harus mencakup kasus tersebut.”

Kesalahan umum

• Menyebut Redis Streams sebagai exactly-once: acknowledgment tidak mencakup efek samping eksternal → nyatakan at-least-once dan tambahkan idempotensi bisnis.
• Melakukan acknowledgment sebelum selesai: crash dapat menghilangkan pekerjaan secara diam-diam → lakukan acknowledgment setelah status bisnis berhasil dicatat.
• Mengatur waktu idle lebih pendek dari p99: worker yang sehat akan terambil alih → sesuaikan berdasarkan distribusi pemrosesan dan jitter.
• Memanggil XAUTOCLAIM tanpa henti: entri beracun menghabiskan sumber daya → klasifikasikan kesalahan dan gunakan kebijakan percobaan ulang serta dead-letter.
• Menggunakan hitungan pengiriman sebagai deteksi duplikat: satu tindakan bisnis dapat memiliki ID pesan yang berbeda → terapkan kunci bisnis dan state machine.
• Mengabaikan ID tertunda yang dipangkas: pembersihan dilaporkan sebagai keberhasilan → beri peringatan pada payload yang hilang dan pertahankan arsip eksternal.
• Menjalankan worker pemulihan tanpa rencana: klaim dan efek samping saling berpacu → gunakan status idempoten, lease, atau konkurensi terbatas.
• Hanya mengawasi panjang Stream: PEL yang terblokir tidak terlihat → pantau PEL, waktu idle, latensi acknowledgment, dan dead letter.

Pertanyaan lanjutan dan jawaban

Pertanyaan lanjutan 1: Mengapa tidak menggunakan XCLAIM secara langsung?

XCLAIM mewajibkan pemanggil mengetahui ID pesan mana yang akan diklaim. XAUTOCLAIM memindai PEL berdasarkan waktu idle minimum dan memajukan kursor, yang cocok untuk worker pemulihan. Keduanya tidak menggantikan idempotensi bisnis atau isolasi kesalahan.

Pertanyaan lanjutan 2: Apakah kursor 0-0 berarti tidak ada pesan lama atau baru?

Ini berarti pemindaian saat ini telah mencapai akhir rentang kursor PEL. Mulai siklus lain dari awal karena entri yang sebelumnya terlalu baru mungkin sekarang sudah idle, dan entri PEL baru mungkin telah muncul.

Pertanyaan lanjutan 3: Bagaimana jika penagihan berhasil tetapi XACK mengalami timeout?

Entri dapat dikirimkan kembali. Kunci idempotensi harus membuat percobaan kedua membaca status selesai dan menghindari penagihan kedua. Catat satu hasil bisnis ditambah percobaan ulang acknowledgment; jangan menafsirkan timeout acknowledgment sebagai kegagalan penagihan.

Pertanyaan lanjutan 4: Bagaimana cara memilih min-idle-time?

Gunakan pemrosesan p99 normal, percobaan ulang dependensi terlama yang diizinkan, dan jitter jaringan sebagai baseline, lalu tambahkan margin keamanan. Validasi dengan rasio klaim palsu, latensi pemulihan, dan pertumbuhan PEL. Satu angka tetap tidak cocok untuk semua tugas.

Pertanyaan lanjutan 5: Berapa kali input yang salah bentuk harus dicoba ulang?

Kegagalan penguraian (parse) dan pelanggaran aturan bisnis yang tidak dapat diubah biasanya langsung masuk ke dead-letter; kegagalan dependensi sementara menerapkan backoff dan dicoba ulang. Tetapkan ambang batas berdasarkan jenis kesalahan, biaya, dan kemampuan pemulihan, sambil tetap mempertahankan ID asli, ringkasan payload, dan kesalahan terakhir.

Pertanyaan lanjutan 6: Apa yang berubah dengan Redis 8.4 XREADGROUP CLAIM?

Fitur ini menggabungkan pembacaan entri baru dan pengklaiman entri tertunda yang idle dalam satu perintah, mengurangi perulangan multi-perintah yang diperlukan oleh versi yang lebih lama. Semantik PEL, urutan acknowledgment, idempotensi, kompensasi, dan penanganan pesan beracun tetap menjadi bagian dari desain konsumen.