Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Amazon ElastiCache (Valkey) untuk aplikasi e-commerce
Aplikasi e-commerce mendapat manfaat dari lapisan cache dalam memori antara server aplikasi dan database. Amazon ElastiCache yang menjalankan Valkey menyediakan latensi baca sub-milidetik untuk data yang sering diakses — entri katalog produk, jumlah inventaris, hasil pencarian, dan sesi pengguna — mengurangi beban database dan meningkatkan waktu respons selama lonjakan lalu lintas.
## Konfigurasi klaster
Pilih jenis cluster berdasarkan volume data, persyaratan throughput, dan preferensi operasional.
**Perbandingan tipe cluster untuk e-commerce**
| Jenis klaster | Terbaik untuk | Penskalaan | Pertimbangan-pertimbangan |
| --- | --- | --- | --- |
| Nirserver | Pola lalu lintas variabel, aplikasi baru, tim tanpa keahlian operasi cache | Otomatis — skala komputasi dan memori berdasarkan permintaan | Tidak diperlukan perencanaan kapasitas. Model biaya variabel—Anda membayar untuk apa yang Anda konsumsi. |
| Node-based (mode cluster diaktifkan) | Beban kerja throughput tinggi yang dapat diprediksi, perlu kontrol halus atas jenis sharding dan node | Penskalaan pecahan dan replika secara manual atau otomatis | Membutuhkan perencanaan kapasitas. Model biaya tetap—Anda membayar kapasitas yang disediakan terlepas dari pemanfaatannya. Mendukung hingga 500 node per cluster. |
Untuk sebagian besar aplikasi e-commerce yang dimulai, Serverless menyediakan jalur paling sederhana menuju produksi. Bermigrasi ke cluster berbasis node jika Anda memiliki garis dasar lalu lintas yang dapat diprediksi dan memerlukan kontrol lebih besar atas topologi cluster, jenis node, dan perilaku penskalaan.
**Pengaturan cluster yang disarankan**
| Pengaturan | Nilai | Alasannya |
| --- | --- | --- |
| Engine | Versi stabil terbaru | Gunakan rilis Valkey stabil terbaru yang tersedia di ElastiCache. Sepenuhnya kompatibel dengan perintah Redis OSS. Memberikan peningkatan kinerja dibandingkan versi sebelumnya. |
| Multi-AZ | Diaktifkan | Failover otomatis ke replika di Availability Zone lain jika node utama gagal. Diperlukan untuk beban kerja e-commerce produksi. |
| In-transit enkripsi | Diaktifkan (TLS) | Mengenkripsi data antara aplikasi Anda dan cluster cache. Diperlukan untuk beban kerja yang menangani sesi pengguna atau PII apa pun. |
| At-rest enkripsi | Diaktifkan | Mengenkripsi data pada disk (backup, swap). Diperlukan untuk beban kerja kepatuhan. |
| Grup subnet | Subnet terisolasi pribadi (2\+ AZ) | Tidak ada akses internet. Hanya dapat dijangkau dari grup keamanan aplikasi Anda. |
## Desain kunci untuk data produk
Rancang kunci cache agar dapat diprediksi, dapat di-debug, dan dicakup untuk menghindari tabrakan di seluruh tipe data.
**Konvensi penamaan kunci**
| Jenis data | Pola kunci | Tipe nilai | Contoh |
| --- | --- | --- | --- |
| Detail produk | `product:{id}` | Hash | `product:12345`→ {nama, harga, deskripsi, imageURL} |
| Jumlah inventaris | `inventory:{sku}` | String (integer) | `inventory:SKU-A100`→ 42 |
| Sesi pengguna | `session:{sessionId}` | Hash | `session:abc123`→ {userId, keranjang, LastAccess} |
| Hasil pencarian | `search:{queryHash}` | String (JSON) | `search:sha256(q=shoes&page=1)`→ [ID produk] |
| Daftar kategori | `category:{slug}:page:{n}` | Daftar | `category:electronics:page:1`→ [ID produk] |
Praktik terbaik desain utama:
+ Gunakan titik dua sebagai pemisah untuk keterbacaan dan dukungan perkakas.
+ Jaga kunci pendek — tombol panjang menghabiskan memori dan bandwidth jaringan.
+ Sertakan awalan tipe data untuk menghindari tabrakan antara produk, sesi, dan entitas lain yang mungkin berbagi ID numerik.
+ Gunakan hash untuk objek multi-bidang (produk, sesi) untuk memungkinkan pembacaan dan pembaruan sebagian tanpa mengambil seluruh nilai.
## Strategi TTL berdasarkan tipe data
Tetapkan nilai TTL (time-to-live) berdasarkan seberapa sering data berubah dan seberapa basi data tanpa mempengaruhi pengalaman pelanggan.
**TTL yang direkomendasikan untuk data e-commerce**
| Jenis data | TTL | Pemicu pembatalan | Alasannya |
| --- | --- | --- | --- |
| Detail produk | 5 menit | Penjual mengedit produk | Deskripsi produk dan gambar jarang berubah. Cukup pendek untuk mengambil suntingan dengan cukup cepat tanpa pembatalan eksplisit untuk setiap perubahan. |
| Jumlah inventaris | 30 detik | Beli atau isi ulang | Persediaan basi dapat menyebabkan overselling. TTL yang sangat pendek memastikan jumlah sering disegarkan. Pembatalan eksplisit pada pembelian untuk akurasi segera. |
| Hasil pencarian | 60 detik | Tidak ada (TTL-based hanya) | Indeks pencarian diperbarui secara berkala. Caching mengurangi beban mesin pencari. Produk baru muncul dalam 60 detik tanpa pembatalan eksplisit. |
| Sesi pengguna | 24 jam | Logout atau kedaluwarsa sesi | Sesi tetap ada di seluruh penjelajahan. Segarkan TTL pada setiap akses untuk menjaga sesi aktif tetap hidup. Hapus secara eksplisit saat logout. |
| Daftar kategori | 2 menit | Produk added/removed dari kategori | Halaman kategori memiliki lalu lintas tinggi. Caching singkat mengurangi kueri database secara substansif selama browsing. |
## Cache-aside pola
Pola cache-aside (juga disebut lazy loading) adalah strategi caching yang paling umum untuk aplikasi e-commerce. Aplikasi Anda memeriksa cache terlebih dahulu, dan hanya menanyakan database pada cache yang hilang.
**Baca jalur (pseudocode)**
```
FUNCTION getProduct(productId):
cacheKey = "product:" + productId
// Step 1: Check the cache
cachedValue = cache.GET(cacheKey)
IF cachedValue exists:
RETURN deserialize(cachedValue) // Cache hit — sub-millisecond
// Step 2: Cache miss — query database
product = database.query("SELECT * FROM products WHERE id = ?", productId)
IF product not found:
RETURN null
// Step 3: Write to cache with TTL
cache.SET(cacheKey, serialize(product), EXPIRE = 300) // 5 minutes
RETURN product
```
**Tulis jalur (pseudocode)**
```
FUNCTION updateProduct(productId, updatedFields):
// Step 1: Update the database (source of truth)
database.update("UPDATE products SET ... WHERE id = ?", updatedFields, productId)
// Step 2: Invalidate the cache (don't update it)
cache.DELETE("product:" + productId)
// Next read will trigger a cache miss and repopulate from database
```
**penting**
Selalu membatalkan (hapus) daripada memperbarui cache saat menulis. Ini mengurangi jendela untuk kondisi balapan di mana bacaan basi mengganti nilai yang lebih baru. Bacaan berikutnya mengisi kembali cache dari database, yang merupakan sumber kebenaran. Perhatikan bahwa kondisi race sempit masih ada—jika pembacaan bersamaan mengambil data dari database sebelum penulisan terjadi, itu dapat mengisi ulang cache dengan data basi setelah kunci cache telah dihapus. Untuk sebagian besar beban kerja e-commerce, TTL pendek membuat ini dapat diterima. Jika Anda membutuhkan konsistensi yang ketat, gunakan kunci terdistribusi atau penulisan berversi.
**Menangani kegagalan cache**
```
FUNCTION getProductWithFallback(productId):
TRY:
RETURN getProduct(productId) // Normal cache-aside path
CATCH cacheConnectionError:
// Cache is unavailable — fall back to database directly
RETURN database.query("SELECT * FROM products WHERE id = ?", productId)
// Log the error, trigger an alarm, but don't fail the request
```
Rancang aplikasi Anda sehingga kegagalan cache menurunkan kinerja (respons yang lebih lambat) tetapi tidak merusak fungsionalitas. Database berfungsi sebagai fallback.
## Strategi pembatalan cache
Pembatalan memastikan pengguna melihat data saat ini setelah pembaruan. Pilih strategi berdasarkan seberapa cepat perubahan harus terlihat.
**Pendekatan pembatalan**
| Pendekatan | Cara kerjanya | Kapan harus digunakan |
| --- | --- | --- |
| Hapus saat menulis | Aplikasi menghapus kunci cache segera setelah memperbarui database. | Sebagian besar menulis (pengeditan produk, perubahan inventaris). Sederhana, andal, menghindari data basi. |
| Hanya kedaluwarsa TTL | Jangan membatalkan - biarkan TTL kedaluwarsa secara alami. | Data di mana kebuntuan singkat dapat diterima (hasil pencarian, daftar kategori, analitik). |
| Event-driven pembatalan | Proses latar belakang mendengarkan peristiwa perubahan database dan membatalkan kunci yang terpengaruh. | Sistem di mana jalur tulis dan cache berada di layanan yang berbeda, atau ketika perubahan database tunggal mempengaruhi banyak kunci cache. |
Untuk aplikasi pasar yang juga menggunakan Amazon CloudFront sebagai lapisan CDN, koordinasikan pembatalan di kedua tingkatan: hapus ElastiCache kunci * dan ki * rim pembatalan CloudFront cache (atau pembatalan tag cache) sehingga pengguna melihat konten yang diperbarui di lapisan aplikasi dan tepi.
## Manajemen koneksi
+ **Gunakan pengumpulan koneksi ** — Membuat koneksi TLS baru untuk setiap operasi cache menambah latensi. Pertahankan kumpulan koneksi persisten dan gunakan kembali di seluruh permintaan.
+ **Atur batas waktu koneksi ** — Gunakan batas waktu koneksi pendek (1-2 detik) dan batas waktu perintah yang lebih pendek (100-500 ms). Jika cache tidak merespons dengan cepat, kembali ke database daripada memblokir permintaan.
+ **Tangani failover dengan lancar ** — Saat Multi-AZ failover terjadi, koneksi ke primer lama terputus. Kumpulan koneksi Anda harus mendeteksi koneksi yang rusak dan menyambung kembali secara otomatis. Sebagian besar pustaka klien menangani ini, tetapi verifikasi perilaku yang sedang diuji.
+ **Gunakan titik akhir konfigurasi cluster ** — Untuk mode cluster diaktifkan, sambungkan ke titik akhir konfigurasi daripada titik akhir node individual. Titik akhir konfigurasi merutekan permintaan ke pecahan yang benar secara otomatis.
## Metrik utama untuk dipantau
**CloudWatch Alarm Amazon yang disarankan untuk cache e-commerce**
| Metrik | Ambang batas | Periode | Tindakan |
| --- | --- | --- | --- |
| CacheHitRate | < 80% | 5 menit | Selidiki — hit rate rendah berarti TTL Anda mungkin terlalu pendek, kunci dirancang dengan buruk, atau set kerja melebihi memori. |
| EngineCPUUtilization | > 70% | 5 menit | Menaikkan skala (node yang lebih besar) atau menskalakan (lebih banyak pecahan). CPU tinggi menunjukkan cache memproses lebih banyak perintah daripada yang dapat ditangani secara efisien. |
| DatabaseMemoryUsagePercentage | > 80% | 5 menit | Risiko penggusuran. Tingkatkan memori (meningkatkan skala) atau mengurangi data yang disimpan (TTL lebih pendek, lebih sedikit jenis data cache). |
| Evictions | > 0 berkelanjutan | 1 menit | Cache penuh dan menghapus data untuk membuat ruang. Meningkatkan kesalahan cache. Tingkatkan memori atau kurangi TTL pada data yang kurang penting. |
| CurrConnections | > 80% dari ukuran kumpulan klien Anda | 5 menit | Kolam koneksi mendekati kelelahan. Tingkatkan ukuran kumpulan, kurangi waktu penahanan koneksi, atau selidiki kebocoran koneksi dalam kode aplikasi. Dasarkan ambang batas pada ukuran kumpulan aplikasi yang dikonfigurasi, bukan maksimum server (65.000). |
## Pertanyaan umum
### Kapan saya harus menggunakan Serverless vs. berbasis node?
Gunakan Serverless saat lalu lintas Anda tidak dapat diprediksi (pasar baru, lonjakan musiman), saat Anda ingin menghindari perencanaan kapasitas, atau ketika tim Anda tidak memiliki keahlian operasi caching. Beralih ke berbasis node ketika pola lalu lintas Anda stabil, Anda memerlukan kontrol halus atas sharding, atau throughput berkelanjutan Anda membuat berbasis node lebih hemat biaya.
### Haruskah saya menggunakan Valkey atau Redis OSS?
Gunakan Valkey untuk penerapan baru. Valkey adalah mesin default untuk ElastiCache cluster baru, sepenuhnya kompatibel dengan perintah Redis OSS dan struktur data, dan menerima pengembangan berkelanjutan. Cluster Redis OSS yang ada terus bekerja - bermigrasi ke Valkey saat nyaman menggunakan peningkatan mesin di tempat.
### Apa yang terjadi ketika cache tidak tersedia?
Aplikasi Anda harus memperlakukan cache sebagai pengoptimalan, bukan ketergantungan. Jika cache tidak tersedia, kembali ke query database secara langsung. Waktu respons akan lebih tinggi, tetapi aplikasi tetap berfungsi. Dengan Multi-AZ diaktifkan, ketidaktersediaan cache lengkap jarang terjadi — failover ke replika biasanya selesai dalam waktu kurang dari 30 detik.
### Bagaimana cara memperkirakan memori yang saya butuhkan?
Hitung: (jumlah item unik untuk cache) × (ukuran rata-rata per item) × (faktor overhead 1,2 untuk struktur data Valkey). Overhead bervariasi berdasarkan ukuran objek dan tipe data—objek yang lebih kecil memiliki overhead yang lebih tinggi secara proporsional. Misalnya, 100.000 produk dengan 2 KB masing-masing dengan overhead 1,2x = sekitar 240 MB. Tambahkan data sesi, hasil pencarian, dan jumlah inventaris. Mulailah dengan headroom (gunakan 60% memori yang tersedia sebagai target Anda) dan pantau DatabaseMemoryUsagePercentage metrik untuk menyesuaikan.