Go 開發者必知：五大緩存策略詳解與選型指南

大家好，我是 Tony Bai。世界讀書日贈書活動火熱進行中，快快參與，也許你就是那個幸運兒。

在構建高性能、高可用的後端服務時，緩存幾乎是繞不開的話題。無論是爲了加速數據訪問，還是爲了減輕數據庫等主數據源的壓力，緩存都扮演着至關重要的角色。對於我們 Go 開發者來說，選擇並正確地實施緩存策略，是提升應用性能的關鍵技能之一。

目前業界主流的緩存策略有多種，每種都有其獨特的適用場景和優缺點。今天，我們就來探討其中五種最常見也是最核心的緩存策略：Cache-Aside、Read-Through、Write-Through、Write-Behind (Write-Back) 和 Write-Around，並結合 Go 語言的特點和示例（使用內存緩存和 SQLite），幫助大家在實際項目中做出明智的選擇。

0. 準備工作：示例代碼環境與結構

爲了清晰地演示這些策略，本文的示例代碼採用了模塊化的結構，將共享的模型、緩存接口、數據庫接口以及每種策略的實現分別放在不同的包中。我們將使用 Go 語言，配合一個簡單的內存緩存（帶 TTL 功能）和一個 SQLite 數據庫作爲持久化存儲。

示例項目的結構如下：

$tree -F ./go-cache-strategy 
./go-cache-strategy
├── go.mod
├── go.sum
├── internal/
│   ├── cache/
│   │   └── cache.go
│   ├── database/
│   │   └── database.go
│   └── models/
│       └── models.go
├── main.go
└── strategy/
    ├── cacheaside/
    │   └── cacheaside.go
    ├── readthrough/
    │   └── readthrough.go
    ├── writearound/
    │   └── writearound.go
    ├── writebehind/
    │   └── writebehind.go
    └── writethrough/
        └── writethrough.go

其中核心組件包括：

• internal/models: 定義共享數據結構 (如 User, LogEntry)。

• internal/cache: 定義 Cache 接口及 InMemoryCache 實現。

• internal/database: 定義 Database 接口及 SQLite DB 實現。

• strategy/xxx: 每個子目錄包含一種緩存策略的核心實現邏輯。

注意： 文中僅展示各策略的核心實現代碼片段。完整的、可運行的示例項目代碼在 Github 上，大家可以通過文末鏈接訪問。

接下來，我們將詳細介紹五種緩存策略及其 Go 實現片段。

1. Cache-Aside (旁路緩存 / 懶加載 Lazy Loading)

這是最常用、也最經典的緩存策略。核心思想是：應用程序自己負責維護緩存。

工作流程：

1. 應用需要讀取數據時，先檢查緩存中是否存在。

2. 緩存命中 (Hit): 如果存在，直接從緩存返回數據。

3. 緩存未命中 (Miss): 如果不存在，應用從主數據源（如數據庫）讀取數據。

4. 讀取成功後，應用將數據寫入緩存（設置合理的過期時間）。

5. 最後，應用將數據返回給調用方。

Go 示例 (核心實現 - strategy/cacheaside/cacheaside.go):

package cacheaside

import (
"context"
"fmt"
"log"
"time"

"cachestrategysdemo/internal/cache"    
"cachestrategysdemo/internal/database"
"cachestrategysdemo/internal/models"
)

const userCacheKeyPrefix = "user:"// Example prefix

// GetUser retrieves user info using Cache-Aside strategy.
func GetUser(ctx context.Context, userID string, db database.Database, memCache cache.Cache, ttl time.Duration) (*models.User, error) {
 cacheKey := userCacheKeyPrefix + userID

// 1. Check cache first
if cachedVal, found := memCache.Get(cacheKey); found {
if user, ok := cachedVal.(*models.User); ok {
   log.Println("[Cache-Aside] Cache Hit for user:", userID)
   return user, nil
  }
  memCache.Delete(cacheKey) // Remove bad data
 }

// 2. Cache Miss
 log.Println("[Cache-Aside] Cache Miss for user:", userID)

// 3. Fetch from Database
 user, err := db.GetUser(ctx, userID)
if err != nil {
returnnil, fmt.Errorf("failed to get user from DB: %w", err)
 }
if user == nil {
returnnil, nil// Not found
 }

// 4. Store data into cache
 memCache.Set(cacheKey, user, ttl)
 log.Println("[Cache-Aside] User stored in cache:", userID)

// 5. Return data
return user, nil
}

優點:

• 實現相對簡單直觀。

• 對讀密集型應用效果好，緩存命中時速度快。

• 緩存掛掉不影響應用讀取主數據源（只是性能下降）。

缺點:

• 首次請求（冷啓動）或緩存過期後，會有一次緩存未命中，延遲較高。

• 存在數據不一致的風險：需要額外的緩存失效策略。

• 應用代碼與緩存邏輯耦合。

使用場景: 讀多寫少，能容忍短暫數據不一致的場景。

2. Read-Through (穿透讀緩存)

核心思想：應用程序將緩存視爲主要數據源，只與緩存交互。緩存內部負責在未命中時從主數據源加載數據。

工作流程：

1. 應用向緩存請求數據。

2. 緩存檢查數據是否存在。

3. 緩存命中: 直接返回數據。

4. 緩存未命中: 緩存自己負責從主數據源加載數據。

5. 加載成功後，緩存將數據存入自身，並返回給應用。

Go 示例 (模擬實現 - strategy/readthrough/readthrough.go):

Read-Through 通常依賴緩存庫自身特性。這裏我們通過封裝 Cache 接口模擬其行爲。

package readthrough

import (
"context"
"fmt"
"log"
"time"

"cachestrategysdemo/internal/cache"     
"cachestrategysdemo/internal/database"
)

// LoaderFunc defines the function signature for loading data on cache miss.
type LoaderFunc func(ctx context.Context, key string) (interface{}, error)

// Cache wraps a cache instance to provide Read-Through logic.
type Cache struct {
 cache      cache.Cache // Use the cache interface
 loaderFunc LoaderFunc
 ttl        time.Duration
}

// New creates a new ReadThrough cache wrapper.
func New(cache cache.Cache, loaderFunc LoaderFunc, ttl time.Duration) *Cache {
return &Cache{cache: cache, loaderFunc: loaderFunc, ttl: ttl}
}

// Get retrieves data, using the loader on cache miss.
func (rtc *Cache) Get(ctx context.Context, key string) (interface{}, error) {
// 1 & 2: Check cache
if cachedVal, found := rtc.cache.Get(key); found {
  log.Println("[Read-Through] Cache Hit for:", key)
return cachedVal, nil
 }

// 4: Cache Miss - Cache calls loader
 log.Println("[Read-Through] Cache Miss for:", key)
 loadedVal, err := rtc.loaderFunc(ctx, key) // Loader fetches from DB
if err != nil {
returnnil, fmt.Errorf("loader function failed for key %s: %w", key, err)
 }
if loadedVal == nil {
returnnil, nil// Not found from loader
 }

// 5: Store loaded data into cache & return
 rtc.cache.Set(key, loadedVal, rtc.ttl)
 log.Println("[Read-Through] Loaded and stored in cache:", key)
return loadedVal, nil
}

// Example UserLoader function (needs access to DB instance and key prefix)
func NewUserLoader(db database.Database, keyPrefix string) LoaderFunc {
returnfunc(ctx context.Context, cacheKey string) (interface{}, error) {
  userID := cacheKey[len(keyPrefix):] // Extract ID
// log.Println("[Read-Through Loader] Loading user from DB:", userID)
return db.GetUser(ctx, userID)
 }
}

優點:

• 應用代碼邏輯更簡潔，將數據加載邏輯從應用中解耦出來。

• 代碼更易於維護和測試（可以單獨測試 Loader）。

缺點:

• 強依賴緩存庫或服務是否提供此功能，或需要自行封裝。

• 首次請求延遲仍然存在。

• 數據不一致問題依然存在。

使用場景: 讀密集型，希望簡化應用代碼，使用的緩存系統支持此特性或願意自行封裝。

3. Write-Through (穿透寫緩存)

核心思想：數據一致性優先！應用程序更新數據時，同時寫入緩存和主數據源，並且兩者都成功後纔算操作完成。

工作流程：

1. 應用發起寫請求（新增或更新）。

2. 應用先將數據寫入主數據源（或緩存，順序可選）。

3. 如果第一步成功，應用再將數據寫入另一個存儲（緩存或主數據源）。

4. 第二步寫入成功（或至少嘗試寫入）後，操作完成，向調用方返回成功。

5. 通常以主數據源寫入成功爲準，緩存寫入失敗一般只記錄日誌。

Go 示例 (核心實現 - strategy/writethrough/writethrough.go):

package writethrough

import (
"context"
"fmt"
"log"
"time"

"cachestrategysdemo/internal/cache"     // Adjust path
"cachestrategysdemo/internal/database"// Adjust path
"cachestrategysdemo/internal/models"   // Adjust path
)

const userCacheKeyPrefix = "user:"// Example prefix

// UpdateUser updates user info using Write-Through strategy.
func UpdateUser(ctx context.Context, user *models.User, db database.Database, memCache cache.Cache, ttl time.Duration) error {
 cacheKey := userCacheKeyPrefix + user.ID

// Decision: Write to DB first for stronger consistency guarantee.
 log.Println("[Write-Through] Writing to database first for user:", user.ID)
 err := db.UpdateUser(ctx, user)
if err != nil {
// DB write failed, do not proceed to cache write
return fmt.Errorf("failed to write to database: %w", err)
 }
 log.Println("[Write-Through] Successfully wrote to database for user:", user.ID)

// Now write to cache (best effort after successful DB write).
 log.Println("[Write-Through] Writing to cache for user:", user.ID)
 memCache.Set(cacheKey, user, ttl)
// If strict consistency cache+db is needed, distributed transaction is required (complex).
// For simplicity, assume cache write is best-effort. Log potential errors.

returnnil
}

優點:

• 數據一致性相對較高。

• 讀取時（若命中）能獲取較新數據。

缺點:

• 寫入延遲較高。

• 實現需考慮失敗處理（特別是 DB 成功後緩存失敗的情況）。

• 緩存可能成爲寫入瓶頸。

使用場景: 對數據一致性要求較高，可接受一定的寫延遲。

4. Write-Behind / Write-Back (回寫 / 後寫緩存)

核心思想：寫入性能優先！應用程序只將數據寫入緩存，緩存立即返回成功。緩存隨後異步地、批量地將數據寫入主數據源。

工作流程：

1. 應用發起寫請求。

2. 應用將數據寫入緩存。

3. 緩存立即嚮應用返回成功。

4. 緩存將此寫操作放入一個隊列或緩衝區。

5. 一個獨立的後臺任務在稍後將隊列中的數據批量寫入主數據源。

Go 示例 (核心實現 - strategy/writebehind/writebehind.go):

package writebehind

import (
"context"
"fmt"
"log"
"sync"
"time"

"cachestrategysdemo/internal/cache"    
"cachestrategysdemo/internal/database"
"cachestrategysdemo/internal/models"   
)

// Config holds configuration for the Write-Behind strategy.
type Config struct {
 Cache     cache.Cache
 DB        database.Database
 KeyPrefix string
 TTL       time.Duration
 QueueSize int
 BatchSize int
 Interval  time.Duration
}

// Strategy holds the state for the Write-Behind implementation.
type Strategy struct {
// ... (fields: cache, db, updateQueue, wg, stopOnce, cancelCtx/Func, dbWriteMutex, config fields) ...
    // Fields defined in the full code example provided previously
 cache       cache.Cache
 db          database.Database
 updateQueue chan *models.User
 wg          sync.WaitGroup
 stopOnce    sync.Once
 cancelCtx   context.Context
 cancelFunc  context.CancelFunc
 dbWriteMutex sync.Mutex // Simple lock for batch DB writes
 keyPrefix   string
 ttl         time.Duration
 batchSize   int
 interval    time.Duration
}


// New creates and starts a new Write-Behind strategy instance.
// (Implementation details in full code example - initializes struct, starts worker)
func New(cfg Config) *Strategy {
// ... (Initialization code as provided previously) ...
// For brevity, showing only the function signature here.
// It sets defaults, creates the context/channel, and starts the worker goroutine.
// Returns the *Strategy instance.
    // ... Full implementation in GitHub Repo ...
    panic("Full implementation required from GitHub Repo") // Placeholder
}


// UpdateUser queues a user update using Write-Behind strategy.
func (s *Strategy) UpdateUser(ctx context.Context, user *models.User) error {
 cacheKey := s.keyPrefix + user.ID
 s.cache.Set(cacheKey, user, s.ttl) // Write to cache immediately

// Add to async queue
select {
case s.updateQueue <- user:
returnnil// Return success to the client immediately
default:
// Queue is full! Handle backpressure.
  log.Printf("[Write-Behind] Error: Update queue is full. Dropping update for user: %s\n", user.ID)
return fmt.Errorf("update queue overflow for user %s", user.ID)
 }
}

// dbWriterWorker processes the queue (Implementation details in full code example)
func (s *Strategy) dbWriterWorker() {
// ... (Worker loop logic: select on queue, ticker, context cancellation) ...
// ... (Calls flushBatchToDB) ...
    // ... Full implementation in GitHub Repo ...
}

// flushBatchToDB writes a batch to the database (Implementation details in full code example)
func (s *Strategy) flushBatchToDB(ctx context.Context, batch []*models.User) {
// ... (Handles batch write logic using s.db.BulkUpdateUsers) ...
    // ... Full implementation in GitHub Repo ...
}

// Stop gracefully shuts down the Write-Behind worker.
// (Implementation details in full code example - signals context, waits for WaitGroup)
func (s *Strategy) Stop() {
// ... (Stop logic using stopOnce, cancelFunc, wg.Wait) ...
    // ... Full implementation in GitHub Repo ...
}

優點:

• 寫入性能極高。

• 降低主數據源壓力。

缺點:

• 數據丟失風險。

• 最終一致性。

• 實現複雜度高。

使用場景: 對寫性能要求極高，寫操作非常頻繁，能容忍數據丟失風險和最終一致性。

5. Write-Around (繞寫緩存)

核心思想：寫操作直接繞過緩存，只寫入主數據源。讀操作時纔將數據寫入緩存（通常結合 Cache-Aside）。

工作流程：

1. 寫路徑: 應用發起寫請求，直接將數據寫入主數據源。

2. 讀路徑 (通常是 Cache-Aside): 應用需要讀取數據時，先檢查緩存。如果未命中，則從主數據源讀取，然後將數據存入緩存，最後返回。

Go 示例 (核心實現 - strategy/writearound/writearound.go):

package writearound

import (
"context"
"fmt"
"log"
"time"

"cachestrategysdemo/internal/cache"    
"cachestrategysdemo/internal/database"
"cachestrategysdemo/internal/models"   
)

const logCacheKeyPrefix = "log:"// Example prefix for logs

// WriteLog writes log entry directly to DB, bypassing cache.
func WriteLog(ctx context.Context, entry *models.LogEntry, db database.Database) error {
// 1. Write directly to DB
 log.Printf("[Write-Around Write] Writing log directly to DB (ID: %s)\n", entry.ID)
 err := db.InsertLogEntry(ctx, entry) // Use the appropriate DB method
if err != nil {
return fmt.Errorf("failed to write log to DB: %w", err)
 }
returnnil
}

// GetLog retrieves log entry, using Cache-Aside for reading.
func GetLog(ctx context.Context, logID string, db database.Database, memCache cache.Cache, ttl time.Duration) (*models.LogEntry, error) {
 cacheKey := logCacheKeyPrefix + logID

// 1. Check cache (Cache-Aside read path)
if cachedVal, found := memCache.Get(cacheKey); found {
if entry, ok := cachedVal.(*models.LogEntry); ok {
   log.Println("[Write-Around Read] Cache Hit for log:", logID)
   return entry, nil
  }
  memCache.Delete(cacheKey)
 }

// 2. Cache Miss
 log.Println("[Write-Around Read] Cache Miss for log:", logID)

// 3. Fetch from Database
 entry, err := db.GetLogByID(ctx, logID) // Use the appropriate DB method
if err != nil { returnnil, fmt.Errorf("failed to get log from DB: %w", err) }
if entry == nil { returnnil, nil/* Not found */ }

// 4. Store data into cache
 memCache.Set(cacheKey, entry, ttl)
 log.Println("[Write-Around Read] Log stored in cache:", logID)

// 5. Return data
return entry, nil
}

優點:

• 避免緩存污染。

• 寫性能好。

缺點:

• 首次讀取延遲高。

• 可能存在數據不一致（讀路徑上的 Cache-Aside 固有）。

使用場景: 寫密集型，且寫入的數據不太可能在短期內被頻繁讀取的場景。

總結與選型

沒有銀彈！ 選擇哪種緩存策略，最終取決於你的具體業務場景對性能、數據一致性、可靠性和實現複雜度的權衡。

本文涉及的完整可運行示例代碼已託管至 GitHub，你可以通過這個鏈接 [1] 訪問。

希望這篇詳解能幫助你在 Go 項目中更自信地選擇和使用緩存策略。你最常用哪種緩存策略？在 Go 中實現時遇到過哪些坑？歡迎在評論區分享交流！ 別忘了點個【贊】和【在看】，讓更多 Gopher 受益！

注：本文代碼由 AI 生成，可編譯運行，但僅用於演示和輔助文章理解，切勿用於生產！

參考資料

[1] 

這個鏈接: https://github.com/bigwhite/experiments/tree/master/go-cache-strategy

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/aPiWDFInEXQjqosvGB-IUg