什么是 Redis？

此技能为管理 Redis 实例提供了一个强大的框架，专注于高速数据访问和内存效率。它使 AI 代理能够实现企业级缓存策略、通过 Streams 实现可靠的消息队列，以及使用有序集合（Sorted Sets）和哈希（Hashes）进行复杂的数据建模。通过将其集成到 Openclaw Skills 中，开发人员可以获得对持久化、原子性和内存逐出策略的精细控制，从而确保应用在大负荷下保持快速且可扩展。

下载入口:https://github.com/openclaw/skills/tree/main/skills/ivangdavila/redis-store

安装与下载

1. ClawHub CLI

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

2. 手动安装

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

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

3. 提示词安装

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

Redis 应用场景

• 使用有序集合实现 API 保护的滑动窗口速率限制
• 管理带有自动过期功能的用户会话数据以防止内存泄漏
• 构建支持通过 Streams 进行确认和重试的可靠、持久化任务队列
• 使用内存优化的哈希高效存储和检索复杂对象
• 使用原子锁和服务器端 Lua 脚本协调分布式系统

1. 代理根据应用需求识别适当的 Redis 数据结构（例如，用于队列的 Streams 或用于对象的 Hashes）。
2. 通过 CLI 或客户端库执行命令，通过 SETNX 或 Lua 脚本确保原子性，以防止竞争条件。
3. 对所有缓存键严格应用 TTL（生存时间）值，以确保自动内存清理。
4. 根据数据的持久性需求评估并配置持久化级别（RDB 或 AOF）。
5. 系统根据定义的 maxmemory 限制坚控内存使用情况，以触发正确的逐出策略，如 allkeys-lru。

Redis 配置指南

要利用此技能，请确保执行环境中提供 Redis CLI：

# 在 Ubuntu/Debian 上安装
sudo apt update && sudo apt install redis-tools

# 在 macOS 上安装
brew install redis

# 验证安装
redis-cli --version

确保您的 Redis 配置包含定义的 maxmemory 限制和适当的逐出策略，以确保 Openclaw Skills 生态系统内的稳定性。

Redis 数据架构与分类体系

name: Redis
description: Use Redis effectively for caching, queues, and data structures with proper expiration and persistence.
metadata: {"clawdbot":{"emoji":"??","requires":{"anyBins":["redis-cli"]},"os":["linux","darwin","win32"]}}

Expiration (Memory Leaks)

• Keys without TTL live forever—set expiry on every cache key: SET key value EX 3600
• Can't add TTL after SET without another command—use SETEX or SET ... EX
• EXPIRE resets on key update by default—SET removes TTL; use SET ... KEEPTTL (Redis 6+)
• Lazy expiration: expired keys removed on access—may consume memory until touched
• SCAN with large database: expired keys still show until cleanup cycle runs

Data Structures I Underuse

• Sorted sets for rate limiting: ZADD limits:{user} {now} {request_id} + ZREMRANGEBYSCORE for sliding window
• HyperLogLog for unique counts: PFADD visitors {ip} uses 12KB for billions of uniques
• Streams for queues: XADD, XREAD, XACK—better than LIST for reliable queues
• Hashes for objects: HSET user:1 name "Alice" email "a@b.com"—more memory efficient than JSON string

Atomicity Traps

• GET then SET is not atomic—another client can modify between; use INCR, SETNX, or Lua
• SETNX for locks: SET lock:resource {token} NX EX 30—NX = only if not exists
• WATCH/MULTI/EXEC for optimistic locking—transaction aborts if watched key changed
• Lua scripts are atomic—use for complex operations: EVAL "script" keys args

Pub/Sub Limitations

• Messages not persisted—subscribers miss messages sent while disconnected
• At-most-once delivery—no acknowledgment, no retry
• Use Streams for reliable messaging—XREAD BLOCK + XACK pattern
• Pub/Sub across cluster: message goes to all nodes—works but adds overhead

Persistence Configuration

• RDB (snapshots): fast recovery, but data loss between snapshots—default every 5min
• AOF (append log): less data loss, slower recovery—appendfsync everysec is good balance
• Both off = pure cache—acceptable if data can be regenerated
• BGSAVE for manual snapshot—doesn't block but forks process, needs memory headroom

Memory Management (Critical)

• maxmemory must be set—without it, Redis uses all RAM, then swap = disaster
• Eviction policies: allkeys-lru for cache, volatile-lru for mixed, noeviction for persistent data
• INFO memory shows usage—monitor used_memory vs maxmemory
• Large keys hurt eviction—one 1GB key evicts poorly; prefer many small keys

Clustering

• Hash slots: keys distributed by hash—same slot required for multi-key operations
• Hash tags: {user:1}:profile and {user:1}:sessions go to same slot—use for related keys
• No cross-slot MGET/MSET—error unless all keys in same slot
• MOVED redirect: client must follow—use cluster-aware client library

Common Patterns

• Cache-aside: check Redis, miss → fetch DB → write Redis—standard caching
• Write-through: write DB + Redis together—keeps cache fresh
• Rate limiter: INCR requests:{ip}:{minute} with EXPIRE—simple fixed window
• Distributed lock: SET ... NX EX + unique token—verify token on release

Connection Management

• Connection pooling: reuse connections—creating is expensive
• Pipeline commands: send batch without waiting—reduces round trips
• QUIT on shutdown—graceful disconnect
• Sentinel or Cluster for HA—single Redis is SPOF

Common Mistakes

• No TTL on cache keys—memory grows until OOM
• Using as primary database without persistence—data loss on restart
• Blocking operations in single-threaded Redis—KEYS * blocks everything; use SCAN
• Storing large blobs—Redis is RAM; 100MB values are expensive
• Ignoring maxmemory—production Redis without limit will crash host