AWS Solutions Architect · Pelajaran

Strategi Caching: Pemuatan Malas dan Tulis Terus

Laksanakan pemuatan malas untuk mengisi cache apabila berlaku kehilangan cache, dan gunakan tulis terus untuk memastikan cache selaras dengan setiap penulisan pangkalan data.

Pelajaran 3 daripada 413 langkah

Strategi Caching: Pemuatan Malas dan Tulis Terus ialah pelajaran AWS Solutions Architect percuma di CoddyKit. Ini ialah pelajaran 3 daripada 4. Sebanyak 3 pelajaran dalam laluan pembelajaran ini boleh dibaca sepenuhnya secara percuma — selepas itu, CoddyKit PRO membuka akses kepada semua pelajaran, serta latihan praktikal dengan penyunting kod terbina dalam dan tutor kecerdasan buatan yang tersedia 24/7. Pelajaran ini merupakan sebahagian daripada laluan pembelajaran AWS Solutions Architect, dan kemajuan anda disegerakkan merentas web serta aplikasi CoddyKit. Kursus AWS Solutions Architect merangkumi sejumlah 4 pelajaran.

Mengapa Strategi Cache Penting

Meletakkan cache antara aplikasi dan pangkalan data memerlukan strategi caching — satu set peraturan yang menentukan bila data dimasukkan ke dalam cache, bila data dibaca daripada cache dan bila data dikeluarkan. Pemilihan strategi yang salah membawa kepada data lapuk (cache mengembalikan nilai yang sudah ketinggalan), cache terlepas sejuk (cache kosong dan setiap permintaan mengakses pangkalan data) atau lonjakan permintaan cache (banyak permintaan serentak untuk Key yang sama dan tiada dalam cache semuanya mengakses pangkalan data pada masa yang sama). Dua strategi asas ialah pemuatan malas dan penulisan terus.

Pemuatan Malas (Cache-Aside): Cara Ia Berfungsi

Pemuatan malas (juga dipanggil cache-aside) ialah corak caching yang paling lazim. Aplikasi menyemak cache terlebih dahulu. Apabila berlaku cache hit, data dikembalikan terus daripada cache — laluan pantas. Apabila berlaku cache miss, aplikasi mengambil data daripada pangkalan data, menulis hasilnya ke dalam cache dengan TTL dan mengembalikannya kepada pemanggil. Cache hanya diisi dengan data yang benar-benar diminta — sebab itulah ia dipanggil 'malas'. Permintaan seterusnya untuk Key yang sama akan menemui data tersebut dalam cache.

# Lazy loading pattern (Python with redis-py)
def get_user(user_id, redis_client, db):
    cache_key = f'user:{user_id}'

    # 1. Check cache
    cached = redis_client.get(cache_key)
    if cached:
        return json.loads(cached)   # Cache HIT

    # 2. Cache MISS: fetch from DB
    user = db.query('SELECT * FROM users WHERE id = %s', user_id)

    # 3. Populate cache with TTL of 300 seconds
    redis_client.setex(cache_key, 300, json.dumps(user))

    return user

Pemuatan Malas: Kelebihan

Pemuatan malas mempunyai tiga kelebihan utama: hanya data yang diminta dicachekan — cache tidak dipenuhi data yang tiada siapa membacanya, jadi memori digunakan dengan cekap. Cache sejuk tidak merosakkan aplikasi — apabila cache terlepas, aplikasi kembali kepada pangkalan data, jadi walaupun ElastiCache dimulakan semula atau nod gagal, aplikasi terus berfungsi (dengan kependaman yang lebih tinggi). Cache sentiasa akhirnya konsisten dengan pangkalan data kerana data lapuk luput melalui TTL walaupun kemas kini terlepas.

Pemuatan Malas: Kekurangan

Pemuatan malas mempunyai tiga kekurangan utama: cache miss adalah mahal — tiga operasi (semakan cache, bacaan pangkalan data dan penulisan cache) berbanding satu operasi bagi cache hit, lalu menyebabkan kependaman lebih tinggi untuk permintaan sejuk. Data lapuk — selepas kemas kini pangkalan data, cache masih melayan nilai lama sehingga TTL luput atau Key dibatalkan secara jelas (tetingkap ketidakselarasan cache). Lonjakan permintaan cache — jika Key popular luput, banyak permintaan serentak mengalami cache miss dan mengakses pangkalan data secara serentak, yang berpotensi membebankannya.

# Mitigating cache stampede with a probabilistic early expiration
# (Refresh the key before it expires to avoid simultaneous misses)
def get_with_stampede_protection(key, redis_client, db_fetch_fn, ttl=300):
    value = redis_client.get(key)
    ttl_remaining = redis_client.ttl(key)

    # Probabilistically refresh before expiry
    if value is None or (ttl_remaining < 30 and random.random() < 0.1):
        value = db_fetch_fn()
        redis_client.setex(key, ttl, json.dumps(value))
    return json.loads(value)

Penulisan Terus: Cara Ia Berfungsi

Dalam strategi penulisan terus, setiap penulisan ke pangkalan data turut ditulis ke cache pada masa yang sama. Aplikasi menulis ke cache dan pangkalan data sebagai sebahagian daripada operasi yang sama (atau pangkalan data mencetuskan kemas kini cache). Oleh itu, cache sentiasa selaras dengan pangkalan data — tiada tetingkap data lapuk. Penulisan terus menjamin bahawa data dalam cache sentiasa terkini, menjadikan bacaan seterusnya sentiasa cache hit bagi data yang baru ditulis.

# Write-through pattern (Python)
def update_user(user_id, user_data, redis_client, db):
    # 1. Write to database FIRST
    db.execute('UPDATE users SET name=%s WHERE id=%s',
                (user_data['name'], user_id))

    # 2. Update cache immediately (write-through)
    cache_key = f'user:{user_id}'
    redis_client.setex(cache_key, 3600, json.dumps(user_data))

    return user_data

# Every read is now a cache hit for recently updated data

Penulisan Terus: Kelebihan

Kelebihan penulisan terus: data cache sentiasa segar — tiada data lapuk kerana cache dikemas kini pada setiap penulisan. Bacaan sentiasa pantas — data popular yang kerap ditulis sentiasa berada dalam cache. Tiada lonjakan permintaan cache semasa bacaan — kerana data diisi terlebih dahulu sebelum dibaca, tiada cache miss sejuk untuk data yang baru ditulis. Strategi ini sesuai untuk beban kerja yang banyak membaca dengan kemas kini yang kerap apabila kesegaran data amat penting, seperti katalog produk, sistem penetapan harga atau cache profil pengguna.

Penulisan Terus: Kekurangan

Kekurangan penulisan terus: penalti penulisan — setiap penulisan melibatkan dua operasi (pangkalan data + cache), lalu menambah kependaman penulisan. Pencemaran cache — data dicachekan walaupun tidak akan dibaca lagi (ditulis sekali, tidak pernah diminta), lalu membazirkan memori cache. Cache dimulakan semula bermakna cache sejuk — jika kluster cache dimulakan semula, semua data yang ditulis secara proaktif hilang dan cache mesti diisi semula melalui penulisan atau proses pemanasan cache. Gabungkan penulisan terus dengan TTL untuk mengelakkan pertumbuhan tanpa had data dicachekan yang jarang dibaca.

Menggabungkan Pemuatan Malas dan Penulisan Terus

Dalam amalan, banyak sistem pengeluaran menggabungkan kedua-dua strategi: gunakan penulisan terus untuk data yang kerap dikemas kini dan kerap dibaca (seperti sesi pengguna atau harga semasa) dan pemuatan malas untuk data yang jarang dikemas kini tetapi kerap dibaca (seperti penerangan produk atau kandungan artikel). Tetapkan TTL yang sesuai bagi kedua-duanya: Key penulisan terus mendapat TTL yang panjang kerana datanya sentiasa segar; Key yang dimuatkan secara malas mendapat TTL yang lebih pendek untuk mengehadkan tetingkap data lapuk. Pendekatan hibrid ini memaksimumkan kadar cache hit sambil meminimumkan kelapukan.

# Hybrid: write-through for sessions, lazy loading for product data

# Write-through for session data (always fresh, critical)
def save_session(session_id, data, redis_client, db):
    db.upsert('sessions', session_id, data)
    redis_client.setex(f'session:{session_id}', 3600, json.dumps(data))

# Lazy loading for product catalog (infrequent updates OK)
def get_product(product_id, redis_client, db):
    cached = redis_client.get(f'product:{product_id}')
    if cached:
        return json.loads(cached)
    product = db.query('SELECT * FROM products WHERE id=%s', product_id)
    redis_client.setex(f'product:{product_id}', 86400, json.dumps(product))
    return product

Prinsip Reka Bentuk TTL

Time-To-Live (TTL) pada data yang dicachekan mengawal tetingkap maksimum data lapuk dan jejak memori cache. Reka bentuk TTL berdasarkan: kekerapan kemas kini data (data sesi kerap berubah → TTL pendek; kandungan statik jarang berubah → TTL panjang), toleransi terhadap kelapukan (harga kewangan → sangat pendek; teks catatan blog → berjam-jam atau berhari-hari) dan kapasiti memori cache (memori rendah → TTL lebih pendek untuk mengeluarkan data lapuk dengan lebih cepat). Sentiasa tetapkan TTL — jangan sekali-kali cachekan data tanpa tamat tempoh, kerana cache akhirnya akan dipenuhi data lapuk.

# TTL examples by data type

# API rate limit counter: 60 seconds
redis_client.setex(f'ratelimit:{ip}', 60, count)

# User session: 30 minutes
redis_client.setex(f'session:{id}', 1800, json.dumps(session))

# Product catalog: 24 hours
redis_client.setex(f'product:{id}', 86400, json.dumps(product))

# Stock price: 10 seconds
redis_client.setex(f'price:{symbol}', 10, price)

# Static site content: 7 days
redis_client.setex(f'page:{slug}', 604800, html_content)

Pembatalan Cache Semasa Kemas Kini

Daripada bergantung sepenuhnya pada tamat tempoh TTL, anda boleh membatalkan cache secara jelas (memadam) Key cache apabila data asas berubah. Tindakan ini menghapuskan tetingkap data lapuk sepenuhnya. Corak yang lazim: padam-semasa-tulis (padam Key cache selepas setiap kemas kini pangkalan data — bacaan seterusnya mengisi semula melalui pemuatan malas), pembatalan dipacu peristiwa (DynamoDB Streams atau tangkapan perubahan RDS mencetuskan Lambda yang memadam Key yang terjejas). Pembatalan cache ialah salah satu masalah paling sukar dalam sistem teragih; semakin mudah logik pembatalan, semakin boleh dipercayai cache anda.

# Delete-on-write invalidation pattern
def update_product(product_id, new_data, redis_client, db):
    # Update the database
    db.execute('UPDATE products SET ... WHERE id=%s', (product_id,))

    # Invalidate the cache key
    redis_client.delete(f'product:{product_id}')

    # Also invalidate any list/search caches that may include this product
    redis_client.delete('products:list:page:1')
    redis_client.delete(f'products:category:{new_data["category_id"]}')

    # Next read will trigger lazy loading with fresh data

Caching Tulis Kemudian (Tulis Balik)

Corak yang kurang lazim tetapi berkuasa ialah tulis kemudian (tulis balik): aplikasi menulis hanya ke cache, dan cache mengepam data ke pangkalan data secara tak segerak di latar belakang. Ini memberikan penulisan yang sangat pantas (hanya dalam memori) dengan risiko kehilangan data jika cache gagal sebelum proses mengepam selesai. Tulis kemudian sesuai untuk penulisan berfrekuensi tinggi dan volum tinggi apabila data boleh dibina semula atau kehilangan kecil boleh diterima — seperti pembilang hit, peristiwa analitik atau kemas kini skor permainan. ElastiCache tidak menyokong tulis kemudian secara natif; fungsi ini mesti dilaksanakan pada lapisan aplikasi.

# Write-behind pattern: write to cache, flush to DB asynchronously
# Application writes:
# redis_client.incr('post:42:views')      # fast, in-memory only

# Background job (runs every 60 seconds):
def flush_view_counts(redis_client, db):
    for key in redis_client.scan_iter('post:*:views'):
        count = redis_client.getdel(key)  # atomic get-and-delete
        post_id = key.split(':')[1]
        db.execute('UPDATE posts SET views = views + %s WHERE id = %s',
                   (int(count), post_id))

Semakan Pantas

Uji pemahaman anda tentang konsep AWS Solutions Architect (SAA-C03) daripada pelajaran ini.

Jawab dalam pelajaran interaktif

Ringkasan Pelajaran

Dalam pelajaran ini, anda telah mempelajari bahawa: pemuatan malas mengisi cache apabila bacaan terlepas dan menggunakan memori dengan cekap tetapi boleh melayan data lapuk sehingga TTL luput, penulisan terus mengemas kini cache pada setiap penulisan untuk menghapuskan data lapuk tetapi membazirkan memori bagi data yang tidak dibaca, dan pembatalan secara jelas memadam Key cache apabila pangkalan data dikemas kini untuk menghapuskan tetingkap data lapuk. Seterusnya, kita akan meneroka corak penyimpanan sesi dan papan pendahulu dengan ElastiCache.

Percuma untuk bermula

Pelajari AWS Solutions Architect dengan tutor kecerdasan buatan — percuma

Tulis dan jalankan kod sebenar dalam pelayar anda, dapatkan bantuan segera daripada tutor kecerdasan buatan yang tersedia 24/7, dan sambung semula dari tempat anda berhenti di web atau dalam aplikasi.

Kursus: 30
Pelajaran: 120

Mula belajar secara percuma Lihat kursus penuh

Soalan Lazim

Adakah pelajaran “Strategi Caching: Pemuatan Malas dan Tulis Terus” percuma?

Ya — sebanyak 3 pelajaran dalam laluan pembelajaran AWS Solutions Architect, termasuk “Strategi Caching: Pemuatan Malas dan Tulis Terus”, boleh dibaca sepenuhnya secara percuma di web ini. Selepas itu, CoddyKit PRO membuka akses kepada semua pelajaran, serta latihan interaktif dengan penyunting kod terbina dalam dan tutor kecerdasan buatan yang tersedia 24/7. Kursus AWS Solutions Architect merangkumi sejumlah 4 pelajaran.

Apakah yang akan saya pelajari dalam “Strategi Caching: Pemuatan Malas dan Tulis Terus”?

Laksanakan pemuatan malas untuk mengisi cache apabila berlaku kehilangan cache, dan gunakan tulis terus untuk memastikan cache selaras dengan setiap penulisan pangkalan data. Anda berlatih AWS Solutions Architect menggunakan kod praktikal yang dijalankan terus dalam pelayar, manakala tutor kecerdasan buatan 24/7 menjawab soalan anda semasa anda mengikuti pelajaran.

Adakah saya memerlukan pengalaman untuk memulakan AWS Solutions Architect?

Tiada pengalaman terdahulu diperlukan. Pembelajaran AWS Solutions Architect di CoddyKit disusun untuk pelajar daripada peringkat pemula hingga lanjutan, jadi anda boleh bermula di sini atau dari awal dan belajar mengikut kadar anda sendiri. Ini ialah pelajaran 3 daripada 4.

Berapa lamakah pelajaran “Strategi Caching: Pemuatan Malas dan Tulis Terus” diambil?

Kebanyakan pelajaran CoddyKit mengambil masa kira-kira 5–10 minit. Setiap pelajaran ringkas dan interaktif, jadi anda boleh membuat kemajuan secara berterusan dan menyambung tepat dari tempat anda berhenti di web atau aplikasi.

Bolehkah saya menulis dan menjalankan kod dalam pelajaran AWS Solutions Architect ini?

Ya. Setiap pelajaran AWS Solutions Architect menyertakan penyunting kod terbina dalam, jadi anda boleh menulis dan menjalankan kod sebenar terus dalam pelayar serta menerima maklum balas kecerdasan buatan serta-merta — tanpa memerlukan persediaan setempat.

Semua pelajaran dalam kursus ini

Redis berbanding Memcached: Memilih Enjin yang Sesuai
Kumpulan Replikasi Redis ElastiCache dan Mod Kluster
Strategi Caching: Pemuatan Malas dan Tulis Terus
Storan Sesi dan Corak Papan Pendahulu

← Kembali ke AWS Solutions Architect