在Redis中为键添加版本/变体（Flavor）方案咨询

Great question! When you're storing versioned asset paths like /pathOfUniqueAsset/v11/ mapped to disk locations in Redis, there are several practical, scalable approaches to manage evolving versions cleanly. Let’s walk through the most viable options tailored to different needs:

1. Structured Key Naming (Refined Version of Your Current Pattern) #

Your existing approach is totally workable, but you can make it more maintainable with consistent key structure. Instead of /pathOfUniqueAsset/v11/, use a format like:

asset:{unique_asset_path}:version:{number}

For example:

asset:/pathOfUniqueAsset:version:11

With the value still being /disk1/pathOfUniqueAsset/path/v/11/.

To make fetching the latest version fast, add a metadata key that tracks the current latest version for each asset:

asset:/pathOfUniqueAsset:latest_version → 11

When you roll out v12, first write the new version key, then update this metadata key. This way, you can quickly get the latest path by combining the metadata value with the structured key format.

Bonus: Use Redis's SCAN command (preferred over KEYS for large datasets) with a pattern like asset:/pathOfUniqueAsset:version:* to list all versions of an asset without blocking the server.

2. Hash Data Structure (Aggregate Versions in One Key) #

Instead of creating a separate key for each version, store all versions of an asset in a single Redis Hash. The main key could be asset:/pathOfUniqueAsset, with hash fields as version identifiers (like v11, v12) and values as the corresponding disk paths:

HSET asset:/pathOfUniqueAsset v11 "/disk1/pathOfUniqueAsset/path/v/11/"
HSET asset:/pathOfUniqueAsset v12 "/disk1/pathOfUniqueAsset/path/v/12/"

You can even add a latest field to track the current version:

HSET asset:/pathOfUniqueAsset latest "v12"

This approach keeps related data grouped, reduces key clutter, and lets you:

• Fetch all versions at once with HGETALL asset:/pathOfUniqueAsset
• Get a specific version with HGET asset:/pathOfUniqueAsset v11
• Update the latest version in one atomic operation (using HSET)

3. Sorted Set (For Version Ordering & Quick Latest/Oldest Queries) #

If you need to easily sort versions or fetch the newest/oldest paths, use a Redis Sorted Set. The main key is asset:/pathOfUniqueAsset:versions, with members as disk paths and scores as numeric version numbers (11, 12, etc.):

ZADD asset:/pathOfUniqueAsset:versions 11 "/disk1/pathOfUniqueAsset/path/v/11/"
ZADD asset:/pathOfUniqueAsset:versions 12 "/disk1/pathOfUniqueAsset/path/v/12/"

This lets you:

• Get the latest version instantly with ZREVRANGE asset:/pathOfUniqueAsset:versions 0 0
• Fetch the 3 most recent versions with ZREVRANGE asset:/pathOfUniqueAsset:versions 0 2
• List all versions in ascending order with ZRANGE asset:/pathOfUniqueAsset:versions 0 -1

If you need to associate version labels (like v11) with paths, you can encode them into the member value (e.g., v11:/disk1/...) and split the string when retrieving.

4. Prefix Keys with Expiry (For Temporary Old Versions) #

If old versions don’t need to be stored permanently, add an expiry time to outdated version keys. For example, when you release v12, set an expiry (e.g., 7 days) on the v11 key:

EXPIRE asset:/pathOfUniqueAsset:version:11 604800

Redis will automatically clean up old versions, saving storage space. Pair this with the metadata key for latest version to keep your workflow efficient.

Which Should You Choose? #

• Use structured keys + metadata if you prefer simple, isolated keys and need to keep all versions long-term.
• Use Hashes if you want to group all versions of an asset together and minimize key count.
• Use Sorted Sets if version ordering or quick access to latest/oldest versions is a priority.
• Use expiry keys if old versions can be auto-deleted after a period.

内容的提问来源于stack exchange，提问作者user1767754