Apa itu distributed cache dan bagaimana menangani kegagalannya?

Question

IT Interview Practice · Accepted Answer

**Cache terdistribusi memungkinkan beberapa instance aplikasi menggunakan kembali data melalui jaringan.** Tujuannya adalah menghindari pengulangan pekerjaan mahal, dengan aturan yang jelas mengenai kesegaran data dan kegagalan.

Bayangkan tiga instance backend membaca katalog produk yang sama. Jika cache berada di dalam masing-masing proses, setiap instance mengelola salinannya sendiri. Dengan layanan cache bersama, satu instance dapat mengisi nilai yang digunakan kembali oleh instance lain. Layanan cache itu sendiri dapat memakai beberapa node.

## 1. Tentukan data yang aman disimpan dalam cache

Mulai dari biaya menghasilkan data dan seberapa lama keterlambatan pembaruan dapat diterima. Deskripsi produk mungkin boleh sedikit terlambat; pemeriksaan stok akhir saat pembelian mungkin membutuhkan data dari sumber resmi.

Tentukan key yang mengidentifikasi hasil secara lengkap, termasuk tenant, bahasa, atau input relevan lainnya. Jika tidak, cache yang cepat dapat mengembalikan data pelanggan yang salah. Jadikan database sumber resmi record bisnis yang harus bertahan, karena nilai cache dapat hilang.

## 2. Ikuti alur baca sebelum merancang pembaruan

Pendekatan umum adalah cache-aside: aplikasi memeriksa cache, membaca database jika data tidak ditemukan, lalu menyimpan hasil dengan waktu kedaluwarsa yang disebut TTL.

```text
Request -> Cache -> hit  -> Return value
                 -> miss -> Database -> Fill cache -> Return value
```

Ini mengurangi pembacaan database berulang ketika banyak request membutuhkan nilai yang sama. Namun, ada tambahan panggilan jaringan dan dependensi, sehingga cache berguna hanya ketika pekerjaan yang dihindari lebih besar daripada biaya tambahannya. Lihat [cache-aside Redis](https://redis.io/docs/latest/develop/use-cases/cache-aside/).

## 3. Tentukan bagaimana pembaruan mulai terlihat

Untuk katalog, titik awal yang praktis adalah melakukan commit pembaruan database lalu menghapus nilai produk dari cache. Pembaca berikutnya memuat ulang data. Namun, urutan ini masih memiliki kondisi balapan: pembaca dapat mengambil nilai database lama sebelum commit, lalu memasukkannya ke cache setelah penghapusan.

TTL membatasi masa hidup salinan yang baru dimasukkan itu; TTL tidak menjamin setiap pembacaan langsung melihat penulisan terbaru. Jika hak akses, harga, atau saldo yang kedaluwarsa melanggar aturan operasi, validasikan terhadap sumber resmi atau rancang pembaruan yang memperhatikan versi dengan jaminan jelas. Pilih konsistensi berdasarkan operasi bisnis, bukan beranggapan bahwa penggunaan Redis menyelesaikannya.

## 4. Cegah cache miss berubah menjadi gangguan layanan

Jika entri populer kedaluwarsa, banyak pemanggil dapat membaca database bersamaan. Ini disebut cache stampede. Gangguan cache dapat menimbulkan masalah yang sama pada banyak entri sekaligus.

- Gabungkan pemuatan bersamaan untuk key yang sama agar lebih sedikit pemanggil membangunnya ulang; tentukan apakah koordinasi mencakup satu proses atau seluruh instance.
- Variasikan waktu kedaluwarsa agar banyak entri tidak habis bersamaan. Ini menyebarkan pekerjaan pembaruan, tetapi tidak menyelesaikan setiap masalah hot key.
- Sajikan nilai cache sebelumnya selama pembaruan hanya jika bisnis mengizinkan data lama.
- Gunakan timeout cache singkat dan batasi trafik pengganti ke database. Menolak sebagian pekerjaan mungkin lebih aman daripada membuat database kewalahan dan menggagalkan seluruh request.

Uji alur ini secara sengaja. Rasio hit tinggi saat operasi normal tidak banyak menjelaskan perilaku layanan ketika cache hilang.

## 5. Tambah kapasitas sesuai hambatan sebenarnya

Sharding membagi key ke beberapa node cache; replikasi menyimpan salinan untuk ketersediaan atau pembacaan. Keduanya menyelesaikan masalah berbeda. Redis Cluster menggunakan hash slot untuk penempatan, sehingga penambahan node tidak otomatis membagi pekerjaan satu hot key. Lihat [spesifikasi Redis Cluster](https://redis.io/docs/latest/operate/oss_and_stack/reference/cluster-spec/).

Pantau rasio hit, latensi request, timeout, memori, eviction, dan beban yang masuk ke database. Eviction berarti cache menghapus nilai untuk mengelola memori dan dapat terjadi sebelum TTL habis. Jangan menganggap entri cache sebagai penyimpanan tahan lama yang terjamin untuk data bisnis atau pekerjaan antrean.

Untuk katalog, saya akan mulai dengan cache-aside yang key-nya jelas, kebijakan kesegaran, dan alur pengganti yang terlindungi. Saya hanya menambah node cache setelah pengukuran menunjukkan masalah kapasitas yang benar-benar dapat diselesaikan dengan distribusi. **Desain cache yang baik menjelaskan apa yang terjadi ketika nilai tersedia maupun ketika nilai hilang atau salah.**

1. Tentukan data yang aman disimpan dalam cache

2. Ikuti alur baca sebelum merancang pembaruan

3. Tentukan bagaimana pembaruan mulai terlihat

4. Cegah cache miss berubah menjadi gangguan layanan

5. Tambah kapasitas sesuai hambatan sebenarnya

Pertanyaan terkait