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. Read for a complete guide on all the parameters.

4. Restart the Decisions server.

Disconnecting from Redis and Rolling Back Cluster Caching

This section outlines the steps required to remove Redis from the Decisions platform configuration and revert to a non-clustered environment. This process should be followed carefully to ensure proper application behavior after disconnection.

Pre-Disconnection Considerations

• Ensure that no active Flows or assignments are mid-process across multiple Decisions servers.
• All user sessions, Flow states, and assignments are either completed or can be safely resumed on a single server.
• One Decisions server (e.g., Server 1) is designated to operate independently after removing Redis.
• Any secondary servers (e.g., Server 2) will either be decommissioned or reconfigured to redirect traffic to the standalone server.
• Back up System configurations and databases before making changes.
• Any Decisions instance that will no longer be part of the cluster must not continue pointing to the same database. If clustering is disabled, all active instances must operate with isolated databases to avoid conflicts.

Rollback Procedure

1. Designate the Primary Server:
   Identify the server that will continue operating after Redis and clustering are disabled. This server will become the standalone Decisions instance (e.g., Server 1).
2. Deactivate Clustering on All Nodes:
   On each Decisions server:
   1. Log in to Decisions Studio.
   2. Navigate to: System > Settings > Clustering Settings
   3. Uncheck Turn On Clustering.
   4. Clear the Redis URL.
   5. Save the settings.
3. Database Isolation (Important):
   Any server not remaining in the cluster (e.g., Server 2 and beyond) must be disconnected from the shared database. Either:
   • Shut down or decommission the server, or
   • Reconfigure it to use a separate database if continued use is necessary.
   Running multiple non-clustered servers against a shared database is unsupported and may cause data integrity issues.
4. Restart Each Decisions Server:
   Restart the Decisions application service on all affected servers to apply the changes:
   • Windows: Restart DecisionsServerService via the Services console.
   • Linux/Docker: Restart the service or container.

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 specified 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.

Related Articles

• Licensing Multi-Tenancy

• Troubleshooting Multi-Tenant Environments

• Setting the Primary Job Server for a Cluster

• Multi-Tenancy with Clustering