Setting Up Redis External Caching

Overview 

In order to expand operations across multiple servers, it is necessary to deploy a Redis server for external caching. The Decisions servers and the Redis server communicate via a series of API calls to store and retrieve Objects. While internal caching acts as a dictionary that clears old items when accessed, external caching supports more transactions between instances and from instance to database.

Decisions Uses Redis in Two Ways

Redis as Pub-Sub Model

When an entity is modified on Server 1, the updated information is stored in the database and sent to Redis for caching. Redis then broadcasts this cached data to all other servers in real time, ensuring that if a user accesses a different server, they will see the exact, updated details from the database.

Redis as Cache

Redis stores information about which server owns the cache for the Flow engine data but does not directly store the cached data itself. Each server manages its own cache independently, and Redis serves as a lookup mechanism for determining the cache owner.

For example:

When a user on Server 1 initiates a Flow, completes the process from their end, and assigns a Form to a second user, the information about the Flow is stored locally on Server 1. In addition to this, the information, including the Flow ID and server details, is sent to Redis, indicating that Server 1 is responsible for the cached data associated with that particular Flow.

When the second user from Server 2 tries to access the same Flow to complete the assignment, Server 2 checks Redis for the stored information instead of searching all servers or the database. If the Flow ID information is found in Redis, Server 2 learns that Server 1 owns the cache for that Flow. Consequently, Server 2 contacts Server 1 directly to retrieve the cached data for the Flow. Once the second server maintains the cache, the information is sent back to Redis, designating Server 2 as the owner of the cached data for Flow.

Note:

Decisions do not store any user data or session-related data in Redis.

Redis System Recommendations

Connecting to the Redis server

After meeting all the prerequisites listed under the overview section, the following subsection explains how to connect Decisions with the Redis server.

1. Log in to Decisions Studio. Select the gear icon on the left taskbar, then navigate to System > Settings > Clustering Settings.

2. Enable Turn On Clustering and then enter the Redis URL.

3. This example utilizes the default localhost Redis URL localhost:6379. If a wrong connection string is entered, a validation stating, "Failed to validate Redis connection string," will be thrown.
   
   

   URL Configuration Options

   • Users can configure the Redis configuration options in the connection string field by adding a comma. E.g., localhost:6379, Password=null, allowAdmin=true etc.

   • Refer to Configurations from StackExchange.Redis for a complete guide on all the parameters.

4.  Restart the Decisions server.

FAQs on Redis

• Does Decisions Support Redis Clusters?

  • Yes, from the automation platform perspective, as long as the connection to Redis is set up correctly. 

• Can the same Redis Cluster be used for Multiple Tenants?

  • Yes. Since Decisions uses Redis as Pub-Sub, using the same Redis instance for multiple tenants is supported as long as it is specced appropriately.

• What would be the memory footprint of each Decisions Cluster on the Redis Cluster?

  • The memory footprint depends on the number of active flows a customer has. However, the footprint is relatively small since Redis is used solely for communicating object IDs between clusters.