Redis Adalah: Pengertian, Cara Kerja & Kapan Dipakai

Setiap kali sebuah halaman web dibuka, aplikasi di belakangnya menanyakan hal yang kurang lebih sama ke database. Siapa pengguna yang sedang login, produk apa yang tampil di beranda, berapa jumlah komentar di artikel ini. Pertanyaannya berulang dan jawabannya jarang berubah, tetapi biayanya dibayar penuh setiap kali. Database harus mengurai perintah SQL, membaca data dari disk, menggabungkan beberapa tabel, lalu mengirim hasilnya kembali. Untuk satu pengunjung hal ini tidak terasa. Untuk seribu pengunjung dalam semenit, inilah yang membuat server terengah-engah.

Solusi paling masuk akal adalah menyimpan jawaban yang sudah pernah dihitung di tempat yang jauh lebih cepat diakses. Di sinilah Redis masuk. Redis adalah penyimpan struktur data di memori yang bekerja sebagai cache, database, sekaligus perantara pesan antar-aplikasi, dan ia sudah menjadi komponen standar di hampir semua aplikasi web berskala menengah ke atas.

Apa Itu Redis?

Redis adalah sistem penyimpanan data in-memory (menyimpan data di RAM, bukan di hard disk) yang menyimpan informasi dalam bentuk pasangan key-value (kunci dan nilai). Nama Redis merupakan singkatan dari REmote DIctionary Server — server kamus jarak jauh. Penamaan ini cukup menjelaskan cara kerjanya: Anda menyebut sebuah kunci, Redis mengembalikan nilai yang tersimpan di bawah kunci tersebut, persis seperti mencari kata di kamus.

Redis pertama kali dikembangkan Salvatore Sanfilippo pada tahun 2009. Ia membangunnya karena database relasional yang ia pakai tidak sanggup melayani kebutuhan analitik real-time pada produk yang sedang ia kerjakan. Sejak itu Redis tumbuh menjadi salah satu perangkat lunak infrastruktur paling banyak dipakai di dunia, berjalan pada port default 6379.

Satu hal yang perlu Anda pegang sejak awal: Redis menyimpan seluruh data aktifnya di RAM. Bukan sebagian, bukan hanya yang sering diakses — seluruhnya. Keputusan desain inilah yang memberi Redis kecepatannya, dan sekaligus menjadi sumber dari hampir semua keterbatasannya yang akan kita bahas nanti.

Cara Kerja Redis: Kenapa Bisa Secepat Itu

Kecepatan Redis bukan hasil satu trik ajaib, melainkan gabungan tiga keputusan desain yang saling menguatkan.

Pertama, data berada di memori. Membaca data dari RAM memakan waktu dalam orde nanodetik, sementara membaca dari SSD berada di orde mikrodetik — selisihnya sekitar seribu kali lipat. Database konvensional memang punya cache internal, tetapi tetap harus menyiapkan diri untuk kemungkinan data ada di disk. Redis tidak punya kemungkinan itu, sehingga seluruh jalur kodenya dirancang untuk satu skenario saja. Kalau Anda ingin memahami dasar perbedaan kecepatan ini, pembahasan RAM sebagai memori kerja komputer menjelaskan latar belakangnya.

Kedua, model datanya sederhana. Redis tidak mengurai perintah SQL, tidak menyusun rencana eksekusi, dan tidak menggabungkan tabel. Perintah GET user:1024 hanya berarti satu hal dan langsung dieksekusi. Beban kerja yang dihilangkan di sini jauh lebih besar daripada yang biasanya orang kira.

Ketiga, Redis memproses perintah dalam satu alur tunggal. Perintah masuk ke antrian dan dikerjakan satu per satu oleh sebuah event loop (putaran yang terus memeriksa dan menangani permintaan masuk). Terdengar seperti kelemahan, padahal justru sebaliknya: tanpa banyak thread yang berebut data, tidak ada penguncian dan tidak ada biaya pergantian konteks antar-thread. Karena setiap perintah selesai dalam hitungan mikrodetik, antrian itu praktis tidak pernah menumpuk. Satu instance Redis pada perangkat keras yang memadai mampu melayani lebih dari 100.000 operasi per detik.

Efek sampingnya perlu Anda ingat: karena semua perintah berbagi satu alur, sebuah perintah berat — misalnya mengambil isi seluruh key berukuran besar — akan menahan semua perintah lain di belakangnya.

Posisi Redis dalam Alur Aplikasi Anda

Bagian ini yang paling sering disalahpahami. Redis bukan pengganti database utama Anda, melainkan lapisan cepat yang duduk di depannya.

Alurnya seperti ini. Saat aplikasi membutuhkan sebuah data, ia bertanya dulu ke Redis. Kalau datanya ada — kondisi yang disebut cache hit — jawabannya langsung dikirim ke pengguna dan database tidak pernah tersentuh. Kalau tidak ada — cache miss — barulah aplikasi menjalankan query ke database, mengirim hasilnya ke pengguna, sekaligus menitipkan salinan hasil itu ke Redis dengan masa berlaku tertentu. Permintaan yang sama berikutnya akan berhenti di Redis.

Diagram alur cache Redis: saat cache hit jawaban dikirim langsung, saat cache miss query berlanjut ke database utama.

Pola inilah yang membuat pertanyaan "kalau Redis lebih cepat, kenapa tidak semua data disimpan di sana saja?" terjawab dengan sendirinya. Data di RAM hilang saat server mati, dan kapasitas RAM jauh lebih terbatas sekaligus lebih mahal. Redis juga tidak sanggup menjawab pertanyaan rumit seperti "tampilkan semua transaksi bulan lalu di atas satu juta rupiah, diurutkan menurut nama pelanggan". MySQL dan database relasional lain tetap memegang kebenaran datanya. Redis memegang salinan yang sering ditanyakan.

Kalau konsep hit dan miss ini masih terasa asing, penjelasan umum tentang cara kerja cache bisa Anda baca lebih dulu.

Struktur Data yang Didukung Redis

Inilah yang memisahkan Redis dari penyimpan key-value biasa. Nilai yang disimpan di bawah sebuah kunci tidak harus berupa teks — ia bisa berupa struktur data utuh yang punya perintah operasinya sendiri.

• String: nilai paling dasar, dipakai untuk menyimpan hasil query, potongan HTML, atau angka penghitung.
• Hash: kumpulan pasangan field dan nilai dalam satu kunci, cocok untuk menyimpan objek seperti profil pengguna tanpa perlu mengurai ulang seluruh data hanya untuk mengubah satu field.
• List: deretan berurutan yang bisa ditambah dari kedua ujungnya, fondasi untuk antrian pekerjaan.
• Set: kumpulan nilai unik tanpa urutan, berguna untuk menyimpan daftar tanpa duplikat dan mencari irisan antar-daftar.
• Sorted set: seperti set, tetapi setiap anggota punya skor, sehingga urutan peringkat selalu terjaga. Papan peringkat permainan hampir selalu memakai struktur ini.
• Bitmap dan HyperLogLog: dua struktur hemat memori untuk menghitung, misalnya menaksir jumlah pengunjung unik harian tanpa menyimpan satu per satu identitasnya.
• Geospatial index: menyimpan koordinat dan mencari objek terdekat dari suatu titik.
• Stream: catatan peristiwa yang hanya bisa ditambahkan di ujung, dipakai untuk aliran data seperti log aktivitas.

Sejak Redis 8 dirilis pada Mei 2025, dua kemampuan yang sebelumnya berada di paket terpisah masuk ke inti Redis. Yang pertama penyimpanan dokumen JSON, yang kedua vector set — tipe data untuk pencarian kemiripan vektor yang banyak dipakai aplikasi berbasis AI.

Diagram Redis menampilkan enam kartu berlabel String, Hash, List, Set, Sorted Set, dan Stream.

Fungsi Redis dalam Praktik

Dari struktur data di atas, muncul lima peran yang paling sering Anda temui di lapangan.

1. Cache hasil query dan halaman: peran paling umum. Hasil query yang mahal atau potongan halaman yang jarang berubah disimpan dengan masa berlaku, misalnya lima menit. Perintahnya sesederhana SET beranda:produk "..." EX 300 lewat redis-cli.
2. Penyimpanan session: saat aplikasi Anda berjalan di beberapa server sekaligus, data login tidak bisa disimpan di file lokal masing-masing server. Redis menjadi tempat bersama yang bisa dibaca semuanya.
3. Antrian pekerjaan latar: pengiriman email, pembuatan laporan, dan pemrosesan gambar tidak perlu membuat pengguna menunggu. Pekerjaan dititipkan ke list di Redis, lalu diambil proses lain di belakang layar. Framework seperti Laravel menyediakan dukungan queue berbasis Redis secara bawaan.
4. Penghitung dan papan peringkat real-time: jumlah tayangan artikel, stok yang berkurang, atau peringkat pemain. Operasi penambahan angka di Redis bersifat atomic (tidak bisa disela perintah lain di tengah jalan), sehingga aman meskipun ribuan permintaan datang bersamaan.
5. Pub/sub dan notifikasi: satu bagian aplikasi mengirim pesan ke sebuah kanal, bagian lain yang berlangganan kanal itu menerimanya seketika. Pola ini menopang fitur seperti notifikasi langsung dan pesan instan.

Data di RAM Bisa Hilang: Persistence dan Replikasi

Pertanyaan yang wajar muncul: kalau semuanya di RAM, apa yang terjadi saat server mati? Redis menyediakan dua mekanisme penyimpanan ke disk yang bisa dipakai sendiri-sendiri atau bersamaan.

RDB (snapshot) memotret seluruh isi memori secara berkala lalu menuliskannya sebagai satu file. Mekanisme ini murah dan file hasilnya ringkas, tetapi Redis perlu menggandakan proses untuk menulisnya. Pada dataset besar, penggandaan itu bisa menahan layanan selama beberapa milidetik hingga sekitar satu detik. Risiko lainnya jelas: data yang masuk setelah snapshot terakhir akan hilang jika server mati mendadak.

AOF (Append Only File) mencatat setiap perintah yang mengubah data ke sebuah berkas log. Pemulihannya lebih lengkap, tetapi tingkat keamanannya bergantung pada seberapa sering catatan itu ditulis ke disk. Pengaturan appendfsync everysec menulis sekali per detik dan masih sangat cepat, sedangkan appendfsync always menulis setiap perintah dan menekan latensi secara nyata.

Untuk ketersediaan, Redis mendukung replikasi ke satu atau beberapa node salinan. Di atasnya ada Redis Sentinel, yang memantau kesehatan node utama dan mempromosikan salinan menjadi node utama secara otomatis saat terjadi kegagalan. Kalau data Anda tidak lagi muat di memori satu server, Redis Cluster membagi data ke banyak node sekaligus menyediakan failover di setiap kelompok node.

Diagram perbandingan RDB dan AOF pada Redis dengan ikon memori, daftar perintah, dan berkas log.

Kelemahan dan Hal yang Perlu Anda Pertimbangkan

Redis memberi kecepatan besar, tetapi ada harga yang menyertainya. Berikut yang perlu Anda perhitungkan sebelum memasangnya.

1. RAM jauh lebih mahal daripada disk: menyimpan 50 GB data di SSD hampir tidak berbiaya, menyimpan jumlah yang sama di RAM berarti menyewa server kelas berbeda. Karena itu Redis dipakai untuk data yang sering diakses, bukan untuk seluruh isi database.
2. Batas memori tidak aktif secara default: pada sistem 64-bit, nilai bawaan maxmemory adalah 0, yang berarti tanpa batas. Redis akan terus tumbuh sampai memori server habis dan sistem operasi menghentikan prosesnya secara paksa. Tetapkan maxmemory secara eksplisit, dan sisakan sekitar 20–25 persen RAM server untuk sistem operasi serta buffer replikasi.
3. Kebijakan pembuangan data bawaannya sering keliru untuk cache: saat batas memori tercapai, Redis memakai kebijakan noeviction — ia menolak penulisan baru dan mengembalikan error, bukan membuang data lama. Untuk pemakaian sebagai cache, dokumentasi resmi merekomendasikan allkeys-lru, yang membuang kunci yang paling lama tidak diakses. Total ada sepuluh kebijakan yang bisa dipilih, termasuk allkeys-lrm yang baru hadir di Redis 8.6 dan hanya memperhitungkan waktu perubahan data, bukan waktu pembacaan.
4. Kemampuan query sangat terbatas: Redis tidak mengenal join, agregasi lintas tabel, maupun pencarian berdasarkan isi nilai seperti yang biasa Anda lakukan lewat SQL. Semua akses dirancang lewat kunci, sehingga penamaan kunci menjadi keputusan arsitektur yang serius sejak hari pertama.
5. Membutuhkan kontrol penuh atas server: Redis berjalan sebagai service tersendiri dan perlu akses root untuk dipasang serta dikonfigurasi. Shared hosting umumnya tidak menyediakannya, sehingga pemakaian Redis praktis mengharuskan Anda berada di VPS Indonesia atau server yang Anda kelola sendiri.
6. Konfigurasi bawaannya terbuka: Redis versi lama tidak meminta kata sandi. Instance yang terekspos ke internet tanpa autentikasi adalah salah satu penyebab kebocoran data yang paling sering ditemukan. Aktifkan autentikasi dan ikat Redis ke alamat lokal atau jaringan privat.

Untuk memastikan cache Anda benar-benar bekerja, periksa rasio keberhasilannya lewat perintah INFO stats. Bagi keyspace_hits dengan jumlah keyspace_hits dan keyspace_misses, lalu kalikan seratus. Angka di bawah 80 persen untuk cache yang sudah berjalan stabil menandakan masa berlaku terlalu pendek atau kebijakan pembuangan datanya tidak cocok.

Redis, Lisensi, dan Munculnya Valkey

Ada satu perkembangan penting yang perlu Anda ketahui sebelum memilih, karena berdampak langsung pada apa yang sebenarnya Anda jalankan.

Selama belasan tahun Redis dirilis dengan lisensi BSD yang sangat permisif. Pada Maret 2024, perusahaan di baliknya berpindah ke SSPL — lisensi yang tidak diakui Open Source Initiative sebagai lisensi open source. Tujuannya menahan penyedia cloud besar yang menjual Redis sebagai layanan tanpa berkontribusi balik. Reaksinya cepat: komunitas bersama Linux Foundation membuat Valkey, cabang dari kode Redis terakhir yang masih berlisensi BSD.

Perusahaan Redis kemudian mengubah arah. Salvatore Sanfilippo kembali bergabung pada November 2024, dan mulai Redis 8 pada Mei 2025 AGPLv3 — lisensi yang diakui OSI — ditambahkan sebagai pilihan. Redis hari ini beredar dengan tiga pilihan lisensi sekaligus: AGPLv3, RSALv2, atau SSPL. Kalau istilah ini terasa membingungkan, pembahasan tentang lisensi open source menjelaskan perbedaan mendasarnya.

Diagram kronologi lisensi Redis dari BSD ke SSPL pada Maret 2024, lalu bercabang menjadi Valkey dan AGPLv3 di Redis 8.

Konsekuensi praktisnya begini. Valkey terus berkembang di bawah Linux Foundation dengan lisensi BSD-3-Clause, dan sudah menjadi pilihan bawaan pada layanan cache terkelola di penyedia cloud besar seperti AWS dan Google. Artinya, kalau Anda menyewa layanan cache terkelola hari ini, yang berjalan kemungkinan besar adalah Valkey. Kabar baiknya, keduanya masih wire-compatible — berbicara dengan protokol yang sama — sehingga pustaka klien dan perintah yang Anda pakai tetap berjalan tanpa perubahan. Perbedaan hanya terasa pada fitur terbaru yang dikembangkan masing-masing pihak setelah perpisahan.

Redis atau Memcached: Kapan Memilih yang Mana

Memcached adalah alternatif klasik yang sering disandingkan. Ia lebih sederhana, hanya menyimpan string, dan tidak menulis apa pun ke disk.

Pilih Memcached jika kebutuhan Anda benar-benar hanya menyimpan potongan teks yang boleh hilang kapan saja, dan Anda menghargai kesederhanaan konfigurasi di atas segalanya. Pilih Redis untuk semua kondisi lain: begitu Anda butuh antrian, papan peringkat, pub/sub, penyimpanan yang bertahan setelah restart, atau replikasi, Memcached tidak lagi mencukupi. Untuk aplikasi web baru pada 2026, Redis atau Valkey adalah titik awal yang lebih masuk akal — kemampuan tambahannya hampir pasti akan Anda butuhkan seiring aplikasi bertumbuh.

Pertanyaan yang Sering Muncul

Apakah Redis menggantikan MySQL atau PostgreSQL? Tidak. Redis melengkapi, bukan menggantikan. Database relasional tetap menjadi sumber kebenaran data, sementara Redis menyimpan salinan yang sering diakses.

Berapa RAM yang dibutuhkan untuk memulai? Untuk cache pada situs berukuran kecil sampai menengah, alokasi 256 MB sampai 512 MB umumnya sudah memadai. Naikkan bertahap sambil memantau angka evicted_keys pada INFO stats.

Apakah Redis gratis? Ya untuk pemakaian umum. Redis 8 ke atas tersedia di bawah AGPLv3 yang diakui OSI. Valkey memakai lisensi BSD-3-Clause yang lebih permisif.

Apa bedanya Redis dan Valkey? Valkey adalah cabang dari Redis yang dibuat setelah perubahan lisensi 2024, dikelola Linux Foundation. Keduanya kompatibel di tingkat protokol, sehingga perintah dan klien yang sama tetap berjalan.

Bisakah Redis berjalan di Windows? Tidak secara resmi. Cara yang lazim adalah menjalankannya lewat WSL atau container Docker.

Kesimpulan

Redis adalah penyimpan data di memori yang berperan sebagai lapisan cepat di depan database utama, bukan penggantinya. Kekuatannya datang dari data yang berada di RAM dan model key-value yang ringkas. Struktur data siap pakai seperti list, hash, dan sorted set membuatnya sanggup menangani cache, session, antrian, hingga papan peringkat sekaligus.

Anda mulai membutuhkannya ketika query yang sama berulang kali membebani database, ketika aplikasi berjalan di lebih dari satu server, atau ketika ada pekerjaan berat yang sebaiknya tidak ditunggu pengguna. Sebaliknya, situs berlalu lintas ringan yang berjalan mulus belum perlu menambah komponen ini. Kalau Anda memutuskan memakainya, tetapkan maxmemory sejak awal, pilih kebijakan allkeys-lru untuk cache, dan aktifkan autentikasi sebelum instance-nya menyentuh jaringan.

Semoga artikel ini membantu.