Infinispan Server includes an endpoint that implements the RESP3 protocol and allows you to interact with remote caches using Redis clients.

1. Infinispan RESP endpoint

The RESP endpoint is enabled by default on the single-port endpoint. Redis client connections will automatically be detected and routed to the internal connector. The RESP endpoint works with:

  • Standalone Infinispan Server deployments, exactly like standalone Redis, where each server instance runs independently of each other.

  • Clustered Infinispan Server deployments, where server instances replicate or distribute data between each other. Clustered deployments provides clients with failover capabilities.

Prerequisites

  • Install Infinispan Server.

Procedure

  1. Create a user

Verification

When you start Infinispan Server check for the following log message:

[org.infinispan.SERVER] ISPN080018: Started connector Resp (internal)

You can now connect to the RESP endpoint with a Redis client. For example, with the Redis CLI you can do the following to add an entry to the cache:

redis-cli -p 11222 --user username --pass password
127.0.0.1:11222> SET k v
OK
127.0.0.1:11222> GET k
"v"
127.0.0.1:11222> quit

1.1. Configuring caches for the RESP endpoint

The RESP endpoint automatically configures and starts a respCache cache. This cache has the following configuration:

  • local-cache or distributed-cache depending on the Infinispan Server clustering mode.

  • application/octet-stream encoding for both keys and values.

  • RESPHashFunctionPartitioner hash partitioner, which supports the CRC16 hashing used by Redis clients

Explicit configuration for cache

It is possible to supply a custom configuration for the cache, as long as it does not violate the requirements of the RESP connector, in which case the server will raise an exception and will not start. Main constraints are:

  • hash partitioning function must be org.infinispan.distribution.ch.impl.RESPHashFunctionPartitioner.

  • key encoding must be application/octet-stream.

Example of explicit cache configuration follows.

XML
<distributed-cache name="respCache" aliases="0" owners="2"
                   key-partitioner="org.infinispan.distribution.ch.impl.RESPHashFunctionPartitioner"
                   mode="SYNC" remote-timeout="17500" statistics="true">
	<encoding media-type="application/octet-stream"/>
</distributed-cache>
JSON
{
   "respCache": {
     "distributed-cache": {
       "aliases": ["0"],
       "owners": "2",
       "key-partitioner": "org.infinispan.distribution.ch.impl.RESPHashFunctionPartitioner",
       "mode": "SYNC",
       "statistics": true,
       "encoding": {
         "media-type": "application/octet-stream"
       }
     }
   }
 }
YAML
respCache:
  distributedCache:
    aliases:
      - "0"
    owners: "2"
    keyPartitioner: "org.infinispan.distribution.ch.impl.RESPHashFunctionPartitioner"
    mode: "SYNC"
    statistics: "true"
    encoding:
      mediaType: "application/octet-stream"

Configure your cache value encoding with Protobuf encoding if you want to view cache entries in the Infinispan Console (value media-type="application/x-protostream").
Explicit RESP endpoint configuration

If the implicit configuration used by the single-port endpoint does not fit your needs, explicit configuration is available.

XML
<endpoints>
  <endpoint socket-binding="default" security-realm="default">
    <resp-connector cache="mycache" />
    <hotrod-connector />
    <rest-connector/>
  </endpoint>
</endpoints>
JSON
{
  "server": {
    "endpoints": {
      "endpoint": {
        "socket-binding": "default",
        "security-realm": "default",
        "resp-connector": {
          "cache": "mycache"
        },
        "hotrod-connector": {},
        "rest-connector": {}
      }
    }
  }
}
YAML
server:
  endpoints:
    endpoint:
      socketBinding: "default"
      securityRealm: "default"
      respConnector:
        cache: "mycache"
      hotrodConnector: ~
      restConnector: ~
Clustered configuration

Infinispan is a horizontally scalable Resp-compatible server with high availability capabilities. Infinispan provides clustering mechanisms with automatic failover detection and membership discovery by default. Topology changes are handled automatically, and adding or removing nodes to the cluster is a streamlined process that automatically redistributes entries between nodes without downtime. The cluster is homogeneous, where nodes are the primary and the backup owners of entries, guaranteeing that entries are available even in case of server failures.

Backed by a consistent hash, compatible with the hash-slot algorithm in Resp clients, entries are distributed across cluster members. Infinispan automatically redirects requests to the proper entry owner. As a result, hash tags in keys and the -MOVED error response for requests are not required even for multi-key operations accessing keys with different owners.

Infinispan allows multiple logical databases with the SELECT command in clustering mode.

1.2. Mapping caches to Redis logical databases

Use the cache aliases configuration attributes to map caches to Redis logical databases. The default respCache is mapped to logical database 0.

Infinispan can use multiple logical databases even in clustered mode, as opposed to Redis which only supports database 0 when using Redis Cluster.

2. Differences between Infinispan and Redis implementation

Infinispan provides different guarantees compared to Redis for some functionalities. This chapter summarizes the differences and, when possible, alternative configurations for a similar behavior.

2.1. Isolation

Redis utilizes a single thread to handle user requests, which provides serializable isolation and atomic behavior for multi-key requests. Infinispan provides a relaxed isolation level, which is configurable. Concurrent requests might perceive a partial result for commands that access multiple keys, such as MSET, where only a subset of the keys were inserted in the cache before the operation finishes.

The only alternative in Infinispan for an atomic behavior is to submit multi-keys operations within a MULTI…EXEC block. However, this requires configuring the default cache with transactional capabilities.

Infinispan does not provide serializable transactions. See the cache configuration guide for more information.

2.2. Transactions

Applications utilizing the MULTI…EXEC commands should update the default cache configuration to enable transactional capabilities. Transactions in Redis do not have the concept of rollback to revert in case of failures. Infinispan provides ACID transactions and rollback in case of failures. Additionally, the transactions are distributed in cluster mode and can operate across many slots.

The recommended configuration utilizes PESSIMISTIC locking and transaction mode different from NONE. See the cache configuration guide for more information.

3. Redis commands

The Infinispan RESP endpoint implements the following Redis commands: