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.
This section highlights some new commands with examples on how to use them: GETEX, SMISMEMBER, ZMSCORE, COPY, and GEOSEARCH and GEOSEARCHSTORE.
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:
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:
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:
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:
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:
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:
Mike can subscribe to channel
sports.football.news, which is part of ACL:
Extending ACL functionality to pub/sub opens up many possibilities for implementing access control for messaging use cases.
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:
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):
Now, if we run the EXISTS command and observe the idle time again, we get the following:
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.
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.
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.