什么是 缓存策略与模式？

本技能提供关于缓存模式的权威指南，旨在降低延迟并减轻数据库负载。它将 Cache-Aside、Write-Behind 和 Refresh-Ahead 等复杂策略整合为开发人员可操作的工作流。通过利用这些 Openclaw Skills，工程团队可以实现平衡数据一致性与极致性能的稳健缓存层。内容涵盖缓存数据的整个生命周期，包括精确的失效方法、TTL 指南以及防止缓存击穿等常见反模式。

下载入口:https://github.com/openclaw/skills/tree/main/skills/wpank/caching

安装与下载

1. ClawHub CLI

从源直接安装技能的最快方式。

2. 手动安装

将技能文件夹复制到以下位置之一

优先级：工作区 > 本地 > 内置

3. 提示词安装

将此提示词复制到 OpenClaw 即可自动安装。

缓存策略与模式 应用场景

• 设计高吞吐量的读密集型工作负载，以减轻数据库压力。
• 通过先进的 HTTP Cache-Control 和 CDN 配置优化 Web 性能。
• 为应用程序状态在内存 LRU 和分布式 Redis 集群之间做出选择。
• 针对高流量全球资产实施缓存击穿预防。
• 使用基于事件或基于版本的失效机制建立数据一致性协议。

1. 分析应用程序访问模式以确定最佳策略，如延迟加载 (Cache-Aside) 或同步更新 (Write-Through)。
2. 选择合适的缓存层，从浏览器级存储到边缘 CDN 或集中式分布式缓存。
3. 配置 TTL 和失效逻辑，以确保数据保持新鲜，同时最大化命中率。
4. 应用如最近最少使用 (LRU) 等驱逐正策，以有效管理内存限制。
5. 集成坚控指标（如命中/未命中率和 p99 延迟），以便在生产环境中持续优化这些 Openclaw Skills。

缓存策略与模式 配置指南

建立一个稳健的缓存环境通常涉及在应用程序代码旁配置如 Redis 之类的分布式存储。使用以下步骤初始化生产就绪的缓存：

# 安装 Redis 服务器
sudo apt update && sudo apt install redis-server

# 在 /etc/redis/redis.conf 中配置驱逐正策
# maxmemory 256mb
# maxmemory-policy allkeys-lru

# 重启并验证服务
sudo systemctl restart redis-server
redis-cli ping

缓存策略与模式 数据架构与分类体系

本技能跨多个层级组织缓存数据和配置，以确保效率和清晰度。使用以下分类法组织您的缓存元数据：

name: caching
model: standard
description: Caching strategies, invalidation, eviction policies, HTTP caching, distributed caching, and anti-patterns. Use when designing cache layers, choosing eviction policies, debugging stale data, or optimizing read-heavy workloads.

Caching Patterns

A well-placed cache is the cheapest way to buy speed. A misplaced cache is the most expensive way to buy bugs.

Cache Strategies

Cache-Aside Flow:

  App ──? Cache ──? HIT? ──? Return data
              │
              ▼ MISS
          Read DB ──? Store in Cache ──? Return data

Cache Invalidation

TTL Guidelines

HTTP Caching

Cache-Control Directives

Common Recipes

# Immutable static assets (hashed filenames)
Cache-Control: public, max-age=31536000, immutable

# API response, CDN-cached, background refresh
Cache-Control: public, s-maxage=60, stale-while-revalidate=300

# Personalized data, browser-only
Cache-Control: private, max-age=0, must-revalidate
ETag: "abc123"

# Never cache (auth tokens, sensitive data)
Cache-Control: no-store

Conditional Requests

Prefer ETag over Last-Modified — ETags detect content changes regardless of timestamp granularity.

Application Caching

Redis vs Memcached

Distributed Caching

Rule of thumb: 3 primaries + 3 replicas minimum for production Redis Cluster.

Cache Eviction Policies

Redis default is noeviction. Set maxmemory-policy to allkeys-lru or volatile-lru for production.

Caching Layers

Browser Cache → CDN → Load Balancer → App Cache → DB Cache → Database

Cache Stampede Prevention

When a hot key expires, hundreds of requests simultaneously hit the database.

Cache Warming

Cold start impact: A full cache flush can increase DB load 10–100x. Always warm gradually or use stale-while-revalidate.

Monitoring

NEVER Do

1. NEVER cache without a TTL or invalidation plan — data rots; every entry needs an expiry path
2. NEVER treat cache as durable storage — caches evict, crash, and restart; always fall back to source of truth
3. NEVER cache sensitive data (tokens, PII) without encryption — cache breaches expose everything in plaintext
4. NEVER ignore cache stampede on hot keys — one expired popular key can take down your database
5. NEVER use unbounded in-memory caches in production — memory grows until OOM-killed
6. NEVER cache mutable data with immutable Cache-Control — browsers will never re-fetch
7. NEVER skip monitoring hit/miss rates — you won't know if your cache is helping or hurting