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.

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.

Desain kunci untuk data produk

Rancang kunci cache agar dapat diprediksi, dapat di-debug, dan dicakup untuk menghindari tabrakan di seluruh tipe data.

Praktik terbaik desain utama:

Strategi TTL berdasarkan tipe data

Tetapkan nilai TTL (time-to-live) berdasarkan seberapa sering data berubah dan seberapa basi data tanpa mempengaruhi pengalaman pelanggan.

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

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.

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

Metrik utama untuk dipantau

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.