Skip to content
GitLab
Next
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • GitLab GitLab
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 44,761
    • Issues 44,761
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 1,330
    • Merge requests 1,330
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GitLab.orgGitLab.org
  • GitLabGitLab
  • Issues
  • #118820
Closed
Open
Issue created Dec 18, 2019 by Sean McGivern@smcgivernMaintainer

Use Redis Cluster-compatible naming for Redis keys

If we were to do Redis sharding (see also #38002 (closed)), we'd want the maximum flexibility in how we do so. The simplest solution to that seems to be to use hash tags in keys: https://redis.io/topics/cluster-spec#keys-hash-tags

TLDR; if a key contains a balance pair of curly braces with content in between them, that content is used for computing the hash slot. Some examples from the docs:

Key Part used for hash
{user1000}.following user1000
{user1000}.followers user1000
foo{}{bar} foo{}{bar}
foo{bar}{zap} bar

Note that we don't have to use Redis Cluster to benefit from this - we could write something ourselves, we could use twemproxy, etc.

This would have benefits event if we didn't shard based on it, as it would give our Redis keys more consistency, making it easier for engineers to understand the context.

Assignee
Assign to
Time tracking