Functions on Redis Cluster

Redis Function PR introduces a new scripting approach called Functions. Unlike eval (see new terminology as explained on this PR), functions are considered part of the data. As such, functions are replicated and persisted. This issue will discuss how to handle functions on Redis cluster, how to make sure functions are located on all the nodes and how to handle cluster topology changes.

Uploading Functions to Redis Cluster

Functions are considered part of the data. It's the developer's responsibility to send his functions to Redis using the FUNCTION CREATE command. On a cluster, the FUNCTION CREATE command needs to somehow arrive at all the nodes. We suggest 2 ways to handle it:

• The node, upon getting the FUNCTION CREATE command, will broadcast it to all the other nodes.
• FUNCTION CREATE command will be broadcasted from outside by the client or admin to all the nodes.

The first approach is complicated and can be tackled as part of a bigger story where nodes have a global data they need to share with each other (like ACL or configuration). This will not be tackled on this issue, we believe option two is easier and gives the functionality needed to make functions usable on cluster.

To make the user life easier we can extend the broadcast option on redis-cli to receive the last parameter from the stding (the -x option), this way a user can upload his function to a cluster like this:

redis-cli -x --cluster call <host>:<port> FUNCTION CREATE LUA test < my_function.lua

Handling Cluster topology changes

The second issue with cluster is that the topology can change, a new node can join the cluster at any time. Joining a node to the cluster is an administrative operation. It requires joining the new node to the cluster and then making it responsible for some slot range. We suggest adding another administrator step that sends the functions to the new node before moving any data into it.

To make this operation easier, we suggest adding a new API that allows export functions from a Redis server. Exporting functions will be done using a new function sub-command: FUNCTION EXPORT. The new command will return a list of FUNCTION CREATE commands. Invoking this list on a new Redis server will result in having the same set of functions on the new Redis server.

An admin that adds a new node to the cluster will be able to call FUNCTION EXPORT on any of the already existing nodes, get the list of FUNCTION CREATE commands and then execute it on the new node before moving any slots into it.

Loading functions on start time

Though not directly related, we would like to use this issue to open the discussion about loading functions on start time. The use case is pure cache without persistence nor replication. In such use cases functions will not survive restarts and users will have to reload them. We see 2 ways to handle it:

1. Startup file: allow configure a startup file that contains a list of Redis commands. Redis will execute all the commands on the startup file only if it doesn't load any persistence file. It will be possible to put FUNCTION CREATE commands on the startup file to load functions on startup
2. Allow saving RDB with only functions (and maybe more meta data in the future). In this approach users will still need to configure persistence but it will be possible to persist only the functions without the keyspace.

After discussion with @oranagra @yossigo and @yoav-steinberg there is no consensus on which approach is better.

Personally, because functions are considered part of the data, I prefer approach 2. I believe that approach 1 turns functions to be a configuration, and makes it admin responsibility to load them instead of developer responsibility. Having RDB with functions only keeps the developer responsible for functions (loading/updating/deleting) and still provides a solution for cache use-cases.

Because the solution is not yet clear, I am not writing a full design and Would like to hear others opinions about this topic.