HCL Cache with Redis
When remote caching is enabled, the HCL Cache uses a Redis server to store cache data and the required metadata, such as dependency IDs. Kafka is not required for cache invalidation if you are using Redis.
This topic describes the general implementation of Redis within HCL Commerce, and includes some best practices when using HCL Cache in a production Kubernetes environment.
Redis Overview
Individual caches are bound to a single Redis node. This enables many cache operations to be
performed with a single network call using LUA scripting. The data and metadata for a cache is
pre-fixed with the cache name which is a hash tag. For example:
{cache-services/cache/WCStoreDistributedMapCache}-.
HCL Cache entries are implemented as Redis HashMaps and contain the key value and metadata information such as dependencies, expiry time, entry creation time and the pod that the entry originated from. A Redis time-to-live (TTL) value is set to match the timeout configurations. Inactivity timeouts are not supported by the remote cache.
Dependency information is stored in Redis Sets which are updated as entries are created or invalidated. If cache keys are removed due to TTL or less-recently-used eviction, the set is not updated and may reference invalidated entries for a time. This is normal behavior.
An invalidation by dependency ID or a cache clear operation resets the dependency lists.
If Redis needs to evict less recently used keys due to lack of space, dependency sets should
never be evicted as long as there are entries in the cache. This is achieved by ensuring that all
cache entries have a timeout set while the dependency Sets do not. Redis must be configured with a
volatile-* LRU setting. See Using Redis as an LRU cache within the Redis documentation for
details.
When a cache enables local caching, remote operations publish invalidation messages to reflect
the changes that are required in the local caches. Invalidation messages are propagated using Redis
channels, with names that include the cache names. For example,
{cache-baseCache}-invalidation.
High Availability Considerations
Production environments must use highly available configurations of the Redis database. Use topologies that offer redundancy such as cluster, or master/minion with replicas. The Redisson Redis client, which is used by HCL Cache, supports the most popular topologies.
When an HCL Cache is enabled with local and remote interfaces, the local cache can provide availability if the remote Redis cache becomes unavailable. The HCL Cache includes a circuit breaker configuration that can be used to configure how the cache will behave upon Redis failure.
With the default configuration, a cache is set in outage mode after experiencing 20 or more consecutive failures (minimumConsecutiveFailures) during a period of time equal or greater than 10 seconds (minimumFailureTimeMs). When both conditions are met, the circuit breaker stops access to the backend and does not retry for 30 seconds (retryWaitTimeMs).
Once retryWaitTimeMs is reached, the circuit breaker will allow connections to the Redis server. During this time, if a successful remote request is registered, the circuit breaker will exit outage mode. If instead the number of failures configured in minimumConsecutiveFailuresResumeOutage is reached, the circuit breaker will restore outage mode and prevent remote requests. minimumConsecutiveFailuresResumeOutage allows quick testing of the remote connection without having to wait for minimumFailureTimeMs andminimumConsecutiveFailures to be reached again.
As invalidations are not available during a Redis outage, a new short time-to-live (TTL) can be used on the local cache during the outage. The TTL is controlled by the setting maxTimeToLiveWithRemoteOutage, which defaults to 60 seconds. When a connection exits outage mode, the regular timeouts continue to be used.
All of these circuit breaker settings can be overridden in the custom configuration file.