Kebarangkalian Tamat Tempoh Awal dalam Go

Mengenai rempuhan cache

Saya sering mengalami situasi di mana saya perlu menyimpan cache ini atau itu. Selalunya, nilai ini dicache untuk satu tempoh masa. Anda mungkin biasa dengan coraknya. Anda cuba mendapatkan nilai daripada cache, jika anda berjaya, anda mengembalikannya kepada pemanggil dan memanggilnya sehari. Jika nilai tidak ada, anda mengambilnya (kemungkinan besar daripada pangkalan data) atau mengiranya dan memasukkannya ke dalam cache. Dalam kebanyakan kes, ini berfungsi dengan baik. Walau bagaimanapun, jika kunci yang anda gunakan untuk entri cache anda kerap diakses dan operasi untuk mengira data mengambil sedikit masa, anda akan berada dalam situasi di mana berbilang permintaan selari akan mendapat kehilangan cache secara serentak. Semua permintaan ini akan memuatkan dari sumber secara bebas dan menyimpan nilai dalam cache. Ini mengakibatkan sumber terbuang malah boleh menyebabkan penafian perkhidmatan.

Izinkan saya menggambarkan dengan contoh. Saya akan menggunakan redis untuk cache dan pelayan Go http mudah di atas. Inilah kod penuh:

package main

import (
    "errors"
    "log"
    "net/http"
    "time"

    "github.com/redis/go-redis/v9"
)

type handler struct {
    rdb *redis.Client
    cacheTTL time.Duration
}

func (ch *handler) simple(w http.ResponseWriter, r *http.Request) {
    cacheKey := "my_cache_key"
    // we'll use 200 to signify a cache hit & 201 to signify a miss
    responseCode := http.StatusOK
    cachedData, err := ch.rdb.Get(r.Context(), cacheKey).Result()
    if err != nil {
        if !errors.Is(err, redis.Nil) {
            log.Println("could not reach redis", err.Error())
            http.Error(w, "could not reach redis", http.StatusInternalServerError)
            return
        }

        // cache miss - fetch & store
        res := longRunningOperation()
        responseCode = http.StatusCreated

        err = ch.rdb.Set(r.Context(), cacheKey, res, ch.cacheTTL).Err()
        if err != nil {
            log.Println("failed to set cache value", err.Error())
            http.Error(w, "failed to set cache value", http.StatusInternalServerError)
            return
        }
        cachedData = res
    }
    w.WriteHeader(responseCode)
    _, _ = w.Write([]byte(cachedData))
}

func longRunningOperation() string {
    time.Sleep(time.Millisecond * 500)
    return "hello"
}

func main() {
    ttl := time.Second * 3
    rdb := redis.NewClient(&redis.Options{
        Addr: "localhost:6379",
    })

    handler := &handler{
        rdb: rdb,
        cacheTTL: ttl,
    }

    http.HandleFunc("/simple", handler.simple)
    if err := http.ListenAndServe(":8080", nil); err != nil {
        log.Fatalf("Could not start server: %s\n", err.Error())
    }
}

Mari letakkan sedikit beban pada titik akhir /simple dan lihat apa yang berlaku. Saya akan menggunakan tumbuhan untuk ini.

Saya menjalankan serangan vegeta -duration=30s -rate=500 -targets=./targets_simple.txt > res_simple.bin. Vegeta akhirnya membuat 500 permintaan setiap saat selama 30 saat. Saya menggambarkannya sebagai histogram kod hasil HTTP dengan baldi yang menjangkau 100ms setiap satu. Hasilnya ialah graf berikut.

Apabila kami memulakan percubaan, cache kosong - kami tidak mempunyai nilai yang disimpan di sana. Kami mendapat rempuhan awal apabila sekumpulan permintaan mencapai pelayan kami. Kesemua mereka menyemak cache tidak menemui apa-apa di sana, hubungi longRunningOperation dan simpannya dalam cache. Memandangkan longRunningOperation mengambil masa ~500ms untuk menyelesaikan sebarang permintaan yang dibuat dalam 500ms pertama akhirnya memanggil longRunningOperation. Sebaik sahaja salah satu permintaan berjaya menyimpan nilai dalam cache semua permintaan berikut mengambilnya daripada cache dan kami mula melihat respons dengan kod status 200. Corak itu kemudian berulang setiap 3 saat apabila mekanisme tamat tempoh pada redis bermula.

Dalam contoh mainan ini, ini tidak menyebabkan sebarang masalah tetapi dalam persekitaran pengeluaran ini boleh membawa kepada beban yang tidak perlu pada sistem anda, pengalaman pengguna yang merosot atau malah penafian perkhidmatan yang disebabkan oleh diri sendiri. Jadi bagaimana kita boleh mencegah perkara ini? Nah, ada beberapa cara. Kami boleh memperkenalkan kunci - sebarang kehilangan cache akan menyebabkan kod cuba mencapai kunci. Penguncian teragih bukanlah perkara remeh untuk dilakukan dan selalunya ini mempunyai kes tepi halus yang memerlukan pengendalian yang halus. Kami juga boleh mengira semula nilai secara berkala menggunakan kerja latar belakang tetapi ini memerlukan proses tambahan untuk dijalankan dengan memperkenalkan satu lagi roda gigi yang perlu dikekalkan dan dipantau dalam kod kami. Pendekatan ini juga mungkin tidak boleh dilakukan jika anda mempunyai kunci cache dinamik. Terdapat pendekatan lain, yang dipanggil tamat tempoh awal kemungkinan dan ini adalah sesuatu yang saya ingin terokai dengan lebih lanjut.

Kebarangkalian tamat tempoh awal

Teknik ini membolehkan seseorang mengira semula nilai berdasarkan kebarangkalian. Apabila mengambil nilai daripada cache, anda juga mengira jika anda perlu menjana semula nilai cache berdasarkan kebarangkalian. Semakin hampir anda dengan tamat tempoh nilai sedia ada, semakin tinggi kebarangkalian.

Saya mendasarkan pelaksanaan khusus pada XFetch oleh A. Vattani, F.Chierichetti & K. Lowenstein dalam Pencegahan Rempuhan Cache Kebarangkalian Optimum.

Saya akan memperkenalkan titik akhir baharu pada pelayan HTTP yang juga akan melakukan pengiraan yang mahal tetapi kali ini menggunakan XFetch semasa caching. Untuk XFetch berfungsi, kita perlu menyimpan tempoh operasi yang mahal (delta) dan apabila kunci cache tamat tempoh. Untuk mencapainya, saya akan memperkenalkan struct yang akan memegang nilai ini serta mesej itu sendiri:

type probabilisticValue struct {
    Message string
    Expiry time.Time
    Delta time.Duration
}

Saya menambah fungsi untuk membungkus mesej asal dengan atribut ini & mensirikannya untuk disimpan dalam redis:

func wrapMessage(message string, delta, cacheTTL time.Duration) (string, error) {
    bts, err := json.Marshal(probabilisticValue{
        Message: message,
        Delta: delta,
        Expiry: time.Now().Add(cacheTTL),
    })
    if err != nil {
        return "", fmt.Errorf("could not marshal message: %w", err)
    }

    return string(bts), nil
}

Mari kita tulis kaedah untuk mengira semula dan menyimpan nilai dalam redis:

func (ch *handler) recomputeValue(ctx context.Context, cacheKey string) (string, error) {
    start := time.Now()
    message := longRunningOperation()
    delta := time.Since(start)

    wrapped, err := wrapMessage(message, delta, ch.cacheTTL)
    if err != nil {
        return "", fmt.Errorf("could not wrap message: %w", err)
    }
    err = ch.rdb.Set(ctx, cacheKey, wrapped, ch.cacheTTL).Err()
    if err != nil {
        return "", fmt.Errorf("could not save value: %w", err)
    }
    return message, nil
}

Untuk menentukan sama ada kita perlu mengemas kini nilai berdasarkan kebarangkalian, kita boleh menambah kaedah kepada probabilisticValue:

func (pv probabilisticValue) shouldUpdate() bool {
    // suggested default param in XFetch implementation
    // if increased - results in earlier expirations
    beta := 1.0
    now := time.Now()
    scaledGap := pv.Delta.Seconds() * beta * math.Log(rand.Float64())
    return now.Sub(pv.Expiry).Seconds() >= scaledGap
}

Jika kita menyambung semuanya, kita akan mendapat pengendali berikut:

func (ch *handler) probabilistic(w http.ResponseWriter, r *http.Request) {
    cacheKey := "probabilistic_cache_key"
    // we'll use 200 to signify a cache hit & 201 to signify a miss
    responseCode := http.StatusOK
    cachedData, err := ch.rdb.Get(r.Context(), cacheKey).Result()
    if err != nil {
        if !errors.Is(err, redis.Nil) {
            log.Println("could not reach redis", err.Error())
            http.Error(w, "could not reach redis", http.StatusInternalServerError)
            return
        }

        res, err := ch.recomputeValue(r.Context(), cacheKey)
        if err != nil {
            log.Println("could not recompute value", err.Error())
            http.Error(w, "could not recompute value", http.StatusInternalServerError)
            return
        }
        responseCode = http.StatusCreated
        cachedData = res

        w.WriteHeader(responseCode)
        _, _ = w.Write([]byte(cachedData))
        return
    }

    pv := probabilisticValue{}
    err = json.Unmarshal([]byte(cachedData), &pv)
    if err != nil {
        log.Println("could not unmarshal probabilistic value", err.Error())
        http.Error(w, "could not unmarshal probabilistic value", http.StatusInternalServerError)
        return
    }

    if pv.shouldUpdate() {
        _, err := ch.recomputeValue(r.Context(), cacheKey)
        if err != nil {
            log.Println("could not recompute value", err.Error())
            http.Error(w, "could not recompute value", http.StatusInternalServerError)
            return
        }
        responseCode = http.StatusAccepted
    }

    w.WriteHeader(responseCode)
    _, _ = w.Write([]byte(cachedData))
}

Pengendali berfungsi sama seperti yang pertama, namun, apabila mendapat pukulan cache, kami membaling dadu. Bergantung pada hasil, kami sama ada hanya mengembalikan nilai yang baru kami ambil atau mengemas kini nilai lebih awal.

Kami akan menggunakan kod status HTTP untuk menentukan antara 3 kes:

• 200 - kami mengembalikan nilai daripada cache
• 201 - cache miss, tiada nilai hadir
• 202 - cache hit, mencetuskan kemas kini kebarangkalian

Saya memulakan vegeta sekali lagi kali ini berjalan melawan titik akhir baharu dan inilah hasilnya:

Gumpalan biru kecil di sana menunjukkan apabila kami sebenarnya telah mengemas kini nilai cache lebih awal. Kami tidak lagi melihat kehilangan cache selepas tempoh pemanasan awal. Untuk mengelakkan lonjakan awal, anda boleh pra-simpan nilai cache jika ini penting untuk kes penggunaan anda.

Jika anda ingin menjadi lebih agresif dengan caching anda dan memuat semula nilai dengan lebih kerap, anda boleh bermain dengan parameter beta. Begini rupa percubaan yang sama dengan param beta yang ditetapkan kepada 2:

Kami kini melihat kemas kini berkebarangkalian dengan lebih kerap.

Semuanya ini adalah teknik kecil yang kemas yang boleh membantu mengelakkan rempuhan cache. Perlu diingat, ini hanya berfungsi jika anda mengambil kunci yang sama secara berkala daripada cache - jika tidak, anda tidak akan melihat banyak manfaat.

Ada cara lain untuk menangani rempuhan cache? perasan kesilapan? Beritahu saya dalam ulasan di bawah!

Atas ialah kandungan terperinci Kebarangkalian Tamat Tempoh Awal dalam Go. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!