Update to Redis

{
  "name": "redis-clustering",
  "description": "Redis Cluster and replication guidance covering hash tags for multi-key operations, avoiding CROSSSLOT errors, and reading from replicas to scale read-heavy workloads. Use when designing keys for a sharded Redis Cluster, debugging CROSSSLOT errors on MGET / SDIFF / pipelines, configuring a multi-key transaction in a cluster, or routing reads to replicas for caches, analytics, or dashboards.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 239
    },
    {
      "relative_path": "references/hash-tags.md",
      "size_in_bytes": 2552
    },
    {
      "relative_path": "references/read-replicas.md",
      "size_in_bytes": 1187
    }
  ],
  "skill_md_contents": "---\nname: redis-clustering\ndescription: Redis Cluster and replication guidance covering hash tags for multi-key operations, avoiding CROSSSLOT errors, and reading from replicas to scale read-heavy workloads. Use when designing keys for a sharded Redis Cluster, debugging CROSSSLOT errors on MGET / SDIFF / pipelines, configuring a multi-key transaction in a cluster, or routing reads to replicas for caches, analytics, or dashboards.\nlicense: MIT\n---\n\n# Redis Clustering\n\nGuidance for designing keys and routing reads in a sharded Redis Cluster (and in standalone primary/replica replication). Covers the two failure modes that bite most new cluster users: `CROSSSLOT` errors on multi-key operations, and overloading primaries with read traffic.\n\n## When to apply\n\n- Designing keys for a Redis Cluster deployment.\n- Debugging a `CROSSSLOT` error on `MGET`, `SDIFF`, transactions, or pipelines.\n- Implementing transactions / Lua scripts that touch multiple keys.\n- Scaling out read traffic without adding shards.\n\n## 1. Hash tags for multi-key operations\n\nRedis Cluster distributes keys across 16,384 slots by hashing the key name. Any command that touches **multiple keys** (`MGET`, `SDIFF`, `SUNIONSTORE`, transactions, pipelines, Lua scripts with multiple `KEYS[]`) requires all keys to live on the **same slot** — otherwise the server returns a `CROSSSLOT` error.\n\nHash tags force this: the part between `{` and `}` is the only thing hashed for slot assignment, so two keys sharing a hash tag always land together.\n\n```python\n# Same slot — multi-key ops work\nredis.set(\"{user:1001}:profile\",  \"...\")\nredis.set(\"{user:1001}:settings\", \"...\")\nredis.lmove(\"{user:1001}:pending\", \"{user:1001}:processed\", \"LEFT\", \"RIGHT\")\n```\n\n```python\n# Different keys, no hash tag — CROSSSLOT on multi-key commands in cluster mode\nredis.set(\"user:1001:profile\",  \"...\")\nredis.set(\"user:1001:settings\", \"...\")\npipe = redis.pipeline()\npipe.get(\"user:1001:profile\")\npipe.get(\"user:1001:settings\")\npipe.execute()  # CROSSSLOT error in cluster\n```\n\nRules of thumb:\n\n- **Use a tag scoped to the meaningful entity**, e.g. `{user:1001}`. Avoid bare `{1001}` — unrelated namespaces (`purchase:{1001}`, `employee:{1001}`) would all collide on the same slot.\n- **Only tag where you actually need multi-key ops.** Tagging everything creates hotspots and defeats the point of sharding.\n- A single-key command on a hash-tagged key works fine, so adding tags later is incremental — but renaming keys in production is painful, so plan tagging up front for entities you'll group.\n\nSee [references/hash-tags.md](references/hash-tags.md).\n\n## 2. Read replicas for read-heavy workloads\n\nIf reads dominate writes, route them to replicas to free primary capacity. Works both in Redis Cluster (each shard has 1+ replica) and in standalone primary/replica replication.\n\n```python\n# Redis Cluster: enable replica reads on the client\nfrom redis.cluster import RedisCluster\n\nrc = RedisCluster(host=\"localhost\", port=6379, read_from_replicas=True)\nrc.set(\"key\", \"value\")     # → primary\nvalue = rc.get(\"key\")       # → may be served by a replica\n```\n\nFor non-cluster setups, point two clients at the right nodes:\n\n```python\nprimary = Redis(host=\"primary-host\", port=6379)\nreplica = Redis(host=\"replica-host\", port=6379)\nprimary.set(\"key\", \"value\")\nvalue = replica.get(\"key\")\n```\n\nThe trade-off is consistency: **replicas are eventually consistent**. Don't read your own writes from a replica; don't use replica reads for anything that requires strict freshness (financial balances, idempotency state). Good fits: cache layers, analytics, dashboards, recommendation feeds.\n\nSee [references/read-replicas.md](references/read-replicas.md).\n\n## References\n\n- [Redis Cluster spec — hash tags](https://redis.io/docs/latest/operate/oss_and_stack/reference/cluster-spec/#hash-tags)\n- [Redis: multi-key operations in cluster](https://redis.io/docs/latest/operate/rs/databases/durability-ha/clustering/#multikey-operations)\n- [Redis: Replication](https://redis.io/docs/latest/operate/oss_and_stack/management/replication/)\n"
}