Belajar Redis - Arsitektur Internal & Persistence Model

#Pendahuluan

Di episode 1 kalian sudah tahu apa itu Redis. Sekarang waktunya membedah bagaimana dia bekerja di dalam. Episode 2 ini membahas dua fondasi arsitektur: model eksekusi single-threaded yang membuat Redis begitu cepat, dan model persistence yang menentukan ke mana data pergi saat server mati.

Dua hal ini sering diabaikan oleh pemula, padahal keduanya menjelaskan hampir semua perilaku aneh Redis di produksi — kenapa kadang latency naik mendadak, kenapa data hilang setelah restart, dan kenapa satu perintah mahal bisa menghentikan semuanya. Mari kita mulai.

#Arsitektur Single-Threaded Event Loop

#Satu Thread, Ribuan Koneksi

Inti Redis adalah event loop single-threaded: semua perintah dieksekusi oleh satu thread saja, secara berurutan. Ini terdengar seperti keterbatasan, tapi justru ini keunggulannya — tanpa konflik antar thread, Redis tidak pernah kena biaya locking dan context switching.

client A ─┐
client B ─┼──> event loop (epoll / kqueue) ──> eksekusi perintah
client C ─┘            │
                       └── satu command pada satu waktu

Bagaimana satu thread melayani ribuan koneksi sekaligus? Jawabannya adalah I/O multiplexing. Redis memakai epoll di Linux dan kqueue di BSD/macOS untuk memantau ribuan socket sekaligus dan hanya memproses socket yang benar-benar siap kirim-terima data. Ini efisien karena thread tidak pernah menunggu membabi buta.

#Kenapa Tetap Sangat Cepat

Kecepatan Redis berasal dari kombinasi: data di RAM (tanpa disk seek), event loop yang bebas locking, dan perintah yang didesain O(1) atau O(log N). Karena satu perintah dieksekusi penuh tanpa interupsi, operasi seperti INCR atau SADD bersifat atomik secara alami — tidak butuh transaction wrapper.

#Multi-Threaded I/O (Redis 6+)

Mulai Redis 6, proses network read/write dipindah ke thread terpisah. Perlu digarisbawahi: eksekusi command tetap single-threaded, hanya memindahkan data melewati socket yang dilakukan paralel. Ini menghilangkan bottleneck I/O jaringan tanpa mengorbankan kesederhanaan model eksekusi.

#Persistence Model: Menyimpan RAM ke Disk

Data Redis hidup di RAM — ketika proses mati atau server restart, semua hilang kecuali ada mekanisme persistence. Redis menyediakan empat model.

#RDB (Redis Database Backup)

RDB adalah point-in-time snapshot dari seluruh dataset, disimpan ke file .rdb secara berkala. Snapshot dibuat lewat mekanisme fork: proses anak mewarisi memori proses utama dan menulis snapshot tanpa memblokir server.

redis-cli BGSAVE

BGSAVE memicu snapshot di background. Konfigurasi otomatisnya ada di redis.conf — misalnya save 900 1 berarti snapshot jika ada minimal 1 perubahan dalam 900 detik. RDB unggul untuk restart cepat dan backup, tapi bisa kehilangan data perubahan terakhir sejak snapshot terakhir.

#AOF (Append-Only File)

AOF mencatat setiap operasi write ke file log. Ketika server restart, AOF di-replay untuk membangun kembali dataset — durabilitasnya jauh lebih tinggi dibanding RDB karena granularitasnya per-operasi.

redis-cli CONFIG GET appendonly
redis-cli INFO persistence

CONFIG GET appendonly menampilkan apakah AOF aktif. INFO persistence memberi detail lengkap status RDB dan AOF. AOF bisa diatur dengan appendfsync always|everysec|no — everysec adalah keseimbangan terbaik antara durabilitas dan performa.

#RDB + AOF Combined

Rekomendasi untuk produksi adalah mengaktifkan keduanya: RDB untuk restart cepat dan backup point-in-time, AOF untuk durabilitas per-operasi. Di Redis 7, AOF bawaan sudah memakai format multi-part yang mengatasi trade-off performa rewrite.

save 900 1
save 300 10
save 60 10000
appendonly yes
appendfsync everysec

Baca baris demi baris: tiga aturan save menentukan jadwal snapshot RDB, appendonly yes mengaktifkan AOF, dan appendfsync everysec menjamin durabilitas maksimal satu detik data yang hilang saat crash. Konfigurasi ini pola standar untuk Redis produksi.

#No Persistence

Untuk pure volatile cache, kalian bisa mematikan semua persistence: save "" dan appendonly no. Data hanya hidup di RAM dan hilang saat restart — sempurna untuk cache yang datanya bisa dibangun ulang dari database utama. Trade-off-nya jelas: tidak ada recovery sama sekali, jadi hanya untuk data yang tidak kritis.

#Cara Mengecek dan Mengubah Persistence

Semua keputusan di atas bisa diverifikasi dan diubah secara runtime tanpa restart:

redis-cli CONFIG GET save
redis-cli CONFIG GET appendfsync
redis-cli CONFIG GET dir

CONFIG GET save menampilkan aturan snapshot RDB yang aktif, appendfsync menunjukkan kebijakan AOF, dan dir memperlihatkan direktori tempat file .rdb dan AOF disimpan. Mengubah lewat CONFIG SET berlaku langsung tapi hilang saat restart — untuk permanen, tulis juga ke redis.conf.

#Trade-off Antar Model

Tidak ada jawaban tunggal. Keputusan persistence adalah keputusan bisnis: berapa detik data yang hilang masih bisa diterima, dan berapa cepat restart harus terjadi.

#Penutup

Episode 2 membedah internal Redis: event loop single-threaded dengan I/O multiplexing via epoll/kqueue, multi-threaded I/O sejak Redis 6 tanpa mengubah model eksekusi command, serta empat model persistence — RDB snapshot, AOF log, kombinasi keduanya, dan mode tanpa persistence.

Inti yang harus dibawa pulang:

• Semua perintah Redis dieksekusi satu thread; satu perintah mahal bisa memblokir seluruh server.
• I/O multiplexing dengan epoll/kqueue memungkinkan satu thread melayani ribuan koneksi.
• Redis 6+ memakai thread terpisah untuk network read/write, tapi eksekusi tetap single-threaded.
• RDB adalah snapshot point-in-time; cepat restart tapi bisa kehilangan data terakhir.
• AOF mencatat setiap write; durabilitas tinggi dengan granularitas per-operasi.
• Produksi ideal: RDB + AOF (appendonly yes + appendfsync everysec).
• Tanpa persistence, Redis murni volatile cache — data hilang saat restart.

Di episode 3 selanjutnya kita mulai mengeksplorasi data structures dengan Strings, Numbers & Key Management — tipe data paling dasar Redis dengan SET/GET, operasi atomic counter, pengelolaan key yang aman dengan SCAN, dan manajemen TTL. Saatnya mengetik!