Wawancara Backend: Bagaimana Anda merancang TTL field hash dengan Redis HEXPIRE?

Petunjuk dan konteks

Sistem menginginkan beberapa field dalam satu hash Redis, masing-masing dengan masa aktif yang berbeda. Jelaskan cara menggunakan HEXPIRE, menangani kondisi pembaruan, membaca status kedaluwarsa, mengklaim kembali memori, mendukung versi lama, dan memulihkan dari kegagalan. Jangan hanya berhenti pada sintaksis perintah.

Hal yang dievaluasi pewawancara

• Pemahaman bahwa Redis 7.4 memperluas granularitas kedaluwarsa dari tingkat key ke field hash.
• Penggunaan dan penjelasan yang tepat mengenai NX, XX, GT, LT, serta nilai kembalian perintah.
• Pertimbangan waktu kedaluwarsa, race condition baca/tulis, notifikasi, persistensi, dan anggaran memori.
• Rencana untuk deteksi versi, fallback, pemantauan, dan pemulihan.

Pertanyaan klarifikasi yang perlu diajukan

1. Apakah field dapat kedaluwarsa secara independen, atau beberapa field harus diperbarui secara atomik?
2. Apakah TTL bersifat relatif terhadap suatu peristiwa bisnis atau batas waktu tetap? Apakah penulisan berulang boleh memperpanjangnya?
3. Haruskah field yang kedaluwarsa mengembalikan nilai hilang (missing), nilai default, atau memicu komputasi ulang? Apakah event kedaluwarsa diperlukan?
4. Versi Redis, mode kluster, persistensi, dan dukungan klien apa yang tersedia?

Kerangka jawaban 30 detik

Saya akan memastikan bahwa masa aktif yang independen membenarkan penggunaan satu hash, lalu menentukan TTL, kondisi pembaruan, dan semantik nilai yang hilang untuk setiap field. HEXPIRE menetapkan detik relatif per field dan NX, XX, GT, serta LT mencegah pemendekan atau perpanjangan yang tidak disengaja; nilai kembalian harus dimasukkan ke dalam pemantauan. Sebelum peluncuran, saya akan menguji operasi baca, tulis ulang, notifikasi kedaluwarsa, pemulihan, dan fallback untuk versi lama. Kedaluwarsa field bukanlah jaminan penghapusan instan yang tepat pada detiknya.

Pembahasan mendalam langkah demi langkah

1. Memodelkan siklus hidup setiap field

Tentukan sumber, batas kesegaran maksimum, peristiwa pembaruan, dan nilai pasca-kedaluwarsa untuk setiap field. Field yang memerlukan pembaruan multi-field secara atomik masih dapat berbagi hash, tetapi perubahan TTL dan penulisan bisnis memerlukan protokol yang dapat dicoba ulang (retryable).

2. Memilih kondisi pembaruan

Gunakan NX untuk kedaluwarsa pertama, XX hanya jika kedaluwarsa sudah ada, GT hanya untuk TTL yang lebih panjang, dan LT hanya untuk yang lebih pendek. Catat setiap hasil perintah agar field yang hilang, kondisi gagal, pembaruan sukses, dan penghapusan langsung dapat dibedakan.

3. Menangani kedaluwarsa dan notifikasi

Kedaluwarsa field tidak berarti thread aplikasi menerima event pada detik yang tepat. Pembacaan harus dapat menerima field yang hilang, dan penulisan tidak boleh memulihkan snapshot lama. Jika kedaluwarsa memicu komputasi ulang, gabungkan notifikasi keyspace atau antrean bisnis dengan mekanisme kompensasi untuk event yang duplikat atau hilang.

4. Merencanakan kompatibilitas, pemantauan, dan pemulihan

Deteksi versi Redis dan kemampuan klien saat startup. Jika TTL field tidak tersedia, beralihlah ke key terpisah sambil mendokumentasikan perubahan memori dan atomisitas. Pantau sisa TTL, kegagalan kondisi, event kedaluwarsa, hit rate, dan memori; setelah pemulihan RDB/AOF, rekonsiliasi batas waktu field penting dan tugas komputasi ulang.

Contoh jawaban model

Saya akan mencatat siklus hidup setiap field, sumber pembaruan, dan perilaku saat kedaluwarsa sebelum memutuskan apakah pembacaan hash bersama dan pembaruan atomik penting. Saya akan menetapkan TTL field dengan HEXPIRE, menggunakan NX untuk penulisan pertama dan XX untuk TTL yang sudah ada, serta mempertimbangkan GT atau LT untuk mencegah perpanjangan atau pemendekan yang tidak disengaja sambil mencatat nilai kembalian. Operasi baca memperlakukan field yang kedaluwarsa sebagai hilang dan tidak bergantung pada notifikasi penghapusan yang tepat; komputasi ulang menggunakan notifikasi ditambah antrean bisnis yang idempoten. Saya akan menguji deteksi versi, pemulihan, pemantauan TTL/hit rate/memori, dan fallback key terpisah.

Kesalahan umum

• Menganggap HEXPIRE sebagai alias untuk EXPIRE tingkat key.
• Salah memahami NX, XX, GT, dan LT sehingga penulisan berulang mengubah TTL secara tidak sengaja.
• Mengasumsikan field dihapus tepat pada detiknya dan memancarkan satu event yang dijamin.
• Mengabaikan versi Redis lama, klien, atau kompatibilitas kluster.
• Menghilangkan semantik untuk field yang hilang, komputasi ulang, notifikasi duplikat, dan pemulihan.
• Memantau hit rate tetapi mengabaikan sisa TTL, kegagalan kondisi, atau reklamasi memori.

Pertanyaan lanjutan dan jawabannya

Kapan Anda sebaiknya tetap menggunakan key terpisah?

Gunakan key terpisah jika field memerlukan pembaruan atomik independen di berbagai layanan, klien tidak memiliki dukungan TTL field, atau kedaluwarsa tingkat key lebih cocok dengan pola akses. Hitung penambahan jumlah key, memori, dan biaya konsistensi.

Mengapa GT berguna untuk fitur rekomendasi?

Fitur rekomendasi biasanya hanya boleh memperpanjang masa berlaku jika ada peristiwa baru yang memberikan batas waktu lebih lama. GT menolak TTL yang lebih pendek sehingga peristiwa lama yang terlambat tidak menyebabkan data baru kedaluwarsa lebih cepat.

Bagaimana cara menangani notifikasi kedaluwarsa yang hilang?

Perlakukan notifikasi sebagai akselerasi, bukan satu-satunya sumber kebenaran (source of truth). Cache miss, pemindaian sisa TTL berkala, watermark bisnis, dan antrean komputasi ulang yang idempoten harus mencakup event yang hilang atau duplikat.