Amazon ElastiCache introduces support for Redis 6.2

In October 2020, we announced Redis 6 compatibility for Amazon ElastiCache for Redis. This update included significant features like role-based access control (RBAC), client-side caching, and several operational improvements designed to improve application availability and reliability. Specifically, Amazon ElastiCache improved replication under low memory conditions, especially for workloads with medium and large-sized keys, by reducing latency and the time it takes to perform snapshots. It also included improvements to the expiry algorithm for faster eviction of expired keys and various bug fixes.

Today, we’re happy to announce Amazon ElastiCache for Redis 6.2. This new version introduces new commands and enhancements along with performance and memory optimizations. ElastiCache for Redis 6.2 includes performance improvements for TLS-enabled clusters using x86 node types with 8 vCPUs or more or Graviton2 node types with 4 vCPUs or more. These enhancements are designed to improve throughput and reduce client connection establishment time by offloading encryption to other CPUs.

In this post, we showcase some important commands and their uses.

New commands

This section highlights some new commands with examples on how to use them: GETEX, SMISMEMBER, ZMSCORE, COPY, and GEOSEARCH and GEOSEARCHSTORE.

GETEX

GETEX is a new command to GET a string value and update the expiration in an atomic operation at the same time. It’s beneficial for use cases in which you have configuration items or time-sensitive data that must update the Time To Live (TTL). Before Redis 6.2, this was only possible with a transaction or LUA script. Now we have a single command, contributed by AWS, to do this:

elasticache:6379> SET config '{"version":"6.2.5"}' EX 60
OK
elasticache:6379> TTL config
(integer) 17
elasticache:6379> GETEX config EX 60
"{\"version\":\"6.2.5\"}"
elasticache:6379> TTL config
(integer) 59

SMISMEMBER

SMISMEMBER is a fit for use cases where you use Redis sets and you want to check if an item is a member of the set stored at key. With previous versions of Redis, you had to run N commands, where N is the number of items you want to check, to validate if the given item belongs to the set. Now, you can validate multiple members at once. While this is an O(N) time complexity command (linear time complexity), the major benefit is that the number of round trips required to verify membership is reduced to 1, whereas on previous versions you required N round trips if the commands weren’t performed in a pipeline.

Let’s look at an example of this:

# Populate SET with unique items
elasticache:6379> SADD rainbow Red Orange Yellow Green Blue Indigo Violet
(integer) 7
# Before Redis 6.2
elasticache:6379> SISMEMBER rainbow Red
(integer) 1
elasticache:6379> SISMEMBER rainbow Green
(integer) 1
elasticache:6379> SISMEMBER rainbow Blue
(integer) 1
elasticache:6379> SISMEMBER rainbow Cyan
(integer) 0
# With Redis 6.2
elasticache:6379> SMISMEMBER rainbow Red Green Blue Cyan
1) (integer) 1
2) (integer) 1
3) (integer) 1
4) (integer) 0

ZMSCORE

Use ZMSCORE when you require unique members with an associated score to retrieve multiple scores from a given list of members. This is useful for gaming leaderboards, time-based collections, or as a scoring for feature stores. Like in our previous example, you can reduce the number of round trips to the server from N to 1 by using this new command (where N is the number of elements we would like to get the score for). See the following code:

# Populate leaderboard with players and scores
elasticache:6379> ZADD myGame 26 player1
(integer) 1
elasticache:6379> ZADD myGame 83 player2
(integer) 1
elasticache:6379> ZADD myGame 75 player3
(integer) 1
# Before Redis 6.2
elasticache:6379> ZSCORE myGame player1
"26"
elasticache:6379> ZSCORE myGame player2
"83"
elasticache:6379> ZSCORE myGame player3
"75"
elasticache:6379> ZSCORE myGame player4
(nil)
# With Redis 6.2
elasticache:6379> ZMSCORE myGame player1 player2 player3 player4
1) "26"
2) "83"
3) "75"
4) (nil)

COPY

COPY lets you clone keys for duplicating or to perform new actions on the keys without recreating the data. Previously, the DUMP command was used in combination with RESTORE, where the data was serialized and then uploaded to a key. Now, you can do this faster with a single command:

# Create String Key
elasticache:6379> SET me Robert
OK
# Before Redis 6.2
elasticache:6379> DUMP me
"\x00\x06Robert\t\x00\xa5\x8f\x1b\xa2T\xb4 \xe8"
elasticache:6379> RESTORE anotherMe 0 "\x00\x06Robert\t\x00\xa5\x8f\x1b\xa2T\xb4 \xe8"
OK
# With Redis 6.2
elasticache:6379> COPY me myself
(integer) 1
# Fetch the cloned keys
elasticache:6379> GET anotherMe
"Robert"
elasticache:6379> GET myself
"Robert"

GEOSEARCH and GEOSEARCHSTORE

Geospatial indexes are one of the built-in data structures provided by Redis. Historically, search was limited to circular areas (by radius with the GEORADIUS command). Now, GEOSEARCH or GEOSEARCHSTORE is the recommended command because it increases the functionality by offering circular and rectangular areas for searching. Rectangular searching is useful for finding items and displaying results in a two-dimensional map. Let’s see how it works:

# Adding California cities
elasticache:6379> GEOADD us:cities -122.4163 37.7775 San-Francisco
(integer) 1
elasticache:6379> GEOADD us:cities -121.8905 37.3361 San-Jose
(integer) 1
elasticache:6379> GEOADD us:cities -121.4944 38.5816 Sacramento
(integer) 1
elasticache:6379> GEOADD us:cities -118.25 34.05 Los-Angeles
(integer) 1
elasticache:6379> GEOADD us:cities -117.1625 32.715 San-Diego
(integer) 1
# Adding more southwest cities
elasticache:6379> GEOADD us:cities -115.1663 36.175 Las-Vegas
(integer) 1
elasticache:6379> GEOADD us:cities -112.0738 33.4483 Phoenix
(integer) 1
elasticache:6379> GEOADD us:cities -111.8911 40.7608 Salt-Lake-City
(integer) 1
# Adding northwest
elasticache:6379> GEOADD us:cities -122.333 47.6097 Seattle
(integer) 1
# Adding midwest
elasticache:6379> GEOADD us:cities -87.6277 41.8819 Chicago
(integer) 1
# Adding northeast
elasticache:6379> GEOADD us:cities -74.0061 40.7127 New-York
(integer) 1
elasticache:6379> GEOADD us:cities -71.0636 42.3580 Boston
(integer) 1
# Find all cities within 1000km (radius) from Las Vegas ordered nearest to farthest
elasticache:6379> GEOSEARCH us:cities FROMMEMBER Las-Vegas BYRADIUS 1000 km ASC WITHDIST
1) 1) "Las-Vegas"
   2) "0.0000"
2) 1) "Los-Angeles"
   2) "366.8193"
3) 1) "Phoenix"
   2) "414.3556"
4) 1) "San-Diego"
   2) "426.1506"
5) 1) "Salt-Lake-City"
   2) "584.2775"
6) 1) "San-Jose"
   2) "612.8323"
7) 1) "Sacramento"
   2) "619.8682"
8) 1) "San-Francisco"
   2) "668.2117"
# Find northern California cities from downtown Oakland in a 200x250km rectangle
elasticache:6379> GEOSEARCH us:cities FROMLONLAT -122.2708 37.8044 BYBOX 200 250 km ASC WITHDIST
1) 1) "San-Francisco"
   2) "13.1344"
2) 1) "San-Jose"
   2) "61.9444"
3) 1) "Sacramento"
   2) "109.9040"

Behavioral changes

In this section, we highlight a few items as changes in behavior or bug fixes, because it affects memory usage and security.

ACL patterns for pub/sub channels

Redis Pub/Sub is a message broker system that allows publishers to send messages and events to multiple subscribers on a channel. Publishers can send messages to a channel without knowledge of any subscribers listening on the other side. Similarly, subscribers connected to a channel consume those messages with no knowledge of who is publishing those messages. Decoupling the publisher and subscriber allows for scalability and flexibility. The Redis Access Control List (ACL) allows you to limit certain connections including the commands that can be run and keys that can be accessed. Once connected, a client is required to authenticate a user name and a valid password. If the authentication stage is successful, the connection is associated with a given user and the limits the user has.

Consider a scenario where users subscribe to various news feeds and get messages from publishers of the newsfeeds. User Mike can subscribe to the sports.football.news channel as part of his subscription package from his provider. However, Mike can’t subscribe to the sports.golf.news channel (perhaps it is a paid subscription).

With the introduction of ACLs for pub/sub in Redis 6.2, we can restrict access to users of pub/sub channels and allow us to implement the preceding use case simply by creating an ACL:

elasticache:6379> ACL SETUSER Mike on nopass -@all +subscribe|sports.football.news
OK
elasticache:6379> AUTH Mike ""
OK
elasticache:6379> SUBSCRIBE sports.golf.news
Reading messages... (press Ctrl-C to quit)
(error) NOPERM this user has no permissions to run the 'subscribe' command or its subcommand

Mike can subscribe to channel sports.football.news, which is part of ACL:

elasticache:6379> SUBSCRIBE sports.football.news
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "sports.football.news"
3) (integer) 1 

Extending ACL functionality to pub/sub opens up many possibilities for implementing access control for messaging use cases.

EXISTS

Prior to Redis 6.2, EXISTS impacted the LRU (Least Recently Used) eviction policy. With Redis 6.2, EXISTS doesn’t impact the LRU policy, so you should test your applications thoroughly for expected outcomes when using this command. When memory usage is nearing or has reached its capacity based on the maxmemory setting, Redis offers a mechanism to evict old keys to manage the memory. An eviction policy such as LRU determines what keys are selected for eviction. By default, ElastiCache for Redis sets the volatile-lru eviction policy to your Redis cluster.

You can use the EXISTS command to check the existence of a particular keys:

elasticache:6379> SET mykey isalive
OK

The OBJECT IDLETIME returns the number of seconds since the object stored at the specified key is idle (not requested by read or write operations):

elasticache:6379> OBJECT IDLETIME mykey
(integer) 4

Now, if we run the EXISTS command and observe the idle time again, we get the following:

elasticache:6379> EXISTS mykey
(integer) 1
A return value of 1 indicates Key exists.

elasticache:6379> OBJECT IDLETIME mykey
(integer) 14
elasticache:6379>

The idle time didn’t reset after we ran the EXISTS command. Prior to Redis 6.2, every time we ran the EXISTS command, the key was considered to be touched and it had implications as to whether the key could be evicted based on the eviction policy.

Additional commands

We would also like to call out the following additional commands:

• ZUNION and ZINTER – These commands return results rather than store them using ZUNIONSTORE and ZINTERSTORE commands
• HRANDFIELD and ZRANDMEMBER – These commands return random values from the hash and sorted set data structures
• CLIENT TRACKINGINFO – This subcommand returns a current client connection’s usage details, such as whether or not it’s using client-side caching.

For a complete list of commands and features released in open-source Redis 6.2, refer to the Redis 6.2 release notes.

Conclusion

ElastiCache for Redis 6.2 is now available in all AWS Regions and AWS GovCloud (US) Regions. You can upgrade the engine version of your cluster or replication group by modifying it and specifying 6.2 as the engine version. For a list of supported versions, refer to Supported ElastiCache for Redis versions. To get started, log on to AWS Management Console.

About the Authors

Roberto Luna Rojas is an AWS In-Memory DB Specialist Solutions Architect based in NY. He works with customers from around the globe to make the best out of In-Memory Databases one bit at the time. When not in front of the computer he loves to spend time with his family, listening to music, watching movies, tv shows, and sports.

Siva Karuturi is a Specialist Solutions Architect for In-Memory Databases with Amazon Web Services and is based out of Dallas, TX.

Sonal Brahmane is a Senior Product Manager for Amazon ElastiCache in the In-Memory Databases team at Amazon Web Services.