Advanced Redis Operations: Pipeline, Transactions, Pub/Sub, Key Migration, and Scanning

Today we introduce advanced Redis operations, including how to use pipeline, handle transactions, work with publish/subscribe, migrate keys, implement custom commands, and efficiently scan keys. The article provides code snippets and performance insights to deepen your understanding of Redis.

1. Pipeline Mode Introduction

1.1 Typical Redis Usage

Most of the time Redis is accessed via a request‑response pattern:

Obtain a Jedis instance.

Send Redis commands.

Because Redis is single‑threaded, each command is processed after the previous one finishes.

The interaction flow is illustrated below:

1.2 Pipeline Mode

In pipeline mode the client can send many commands at once without waiting for each reply, dramatically reducing network round‑trips and improving performance.

Pipeline batches multiple commands, sends them in a single request, and receives all replies together, eliminating most network overhead.

1.3 Performance Comparison

The chart shows that Redis latency is dominated by the number of network I/O operations. Using pipeline reduces the number of round‑trips, thus lowering overall latency.

2. Redis Transactions

A simple Redis transaction groups commands between MULTI and EXEC . MULTI starts the transaction, EXEC ends it.

2.1 Transaction Commands

MULTI : start transaction

EXEC : commit transaction

WATCH : monitor one or more keys for changes

DISCARD : abort transaction

Example of a transaction session:

127.0.0.1:6379> multi      // start transaction
OK
127.0.0.1:6379> sadd tt 1   // business operation
QUEUED
127.0.0.1:6379> DISCARD   // abort transaction
OK
127.0.0.1:6379> exec      // commit (error because MULTI was discarded)
(error) ERR EXEC without MULTI
127.0.0.1:6379> get tt      // key does not exist
(nil)

2.2 Transaction Exceptions

Redis provides weak transaction guarantees; certain errors can abort the transaction.

1) Syntax error aborts the transaction:

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set aa 123
QUEUED
127.0.0.1:6379> sett bb 124   // unknown command
(error) ERR unknown command 'sett'
127.0.0.1:6379> exec
(error) EXECABORT Transaction discarded because of previous errors.

2) Runtime type errors do not abort the transaction; they are reported per command:

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set t 1   // OK
QUEUED
127.0.0.1:6379> sadd t 1   // WRONGTYPE
QUEUED
127.0.0.1:6379> set t 2   // OK
QUEUED
127.0.0.1:6379> exec
1) OK
2) (error) WRONGTYPE Operation against a key holding the wrong kind of value
3) OK
127.0.0.1:6379> get t
"2"

3. Redis Publish/Subscribe

Redis offers a publish‑subscribe messaging model where publishers send messages to a channel and all subscribers to that channel receive them.

3.1 Common Pub/Sub Commands

3.2 Performance Test Reference

https://blog.csdn.net/b379685397/article/details/95626295

3.3 Application Scenarios

Pub/Sub is suitable for simple notification scenarios such as:

Subscription services (public accounts, email newsletters, etc.)

Real‑time communication systems

Group chat or community platforms

4. Key Migration

Key migration is rarely needed because most deployments rely on master‑slave replication, but it becomes useful for analytical workloads or to avoid massive deletions that could cause a Redis “snowball” effect.

4.1 MOVE

The MOVE command moves a key from one logical database to another within the same Redis instance.

move key db   // Redis has 16 databases (0‑15)
set name DK; move name 5   // move to database 5 (index 5)
select 5; get name   // returns "DK"

If the target already contains the key, nothing happens. This command is not recommended for production use across databases.

4.2 DUMP / RESTORE

DUMP serializes a key’s value; RESTORE imports the serialized payload into another Redis instance.

# On server A
set name james;
dump name;   // returns binary payload

# On server B
restore name 0 "\x00\x05james\b\x001\x82;f\"DhJ"   // 0 = no TTL
get name   // returns "james"

4.3 MIGRATE

MIGRATE combines DUMP , RESTORE and DEL to move a key between two Redis instances atomically.

Example:

192.168.42.111:6379> migrate 192.168.42.112 6379 name 0 1000 copy

5. Custom Command Encapsulation

When using Jedis or Spring’s RedisTemplate , some low‑level commands (e.g., key migration) are not exposed. You can invoke them via reflection on the underlying Connection object.

Establish a Connection to Redis.

Reflectively obtain the protected sendCommand method.

Invoke sendCommand with the desired Protocol.Command (e.g., MIGRATE ) and arguments.

Read the bulk reply to get the command result.

package com.james.cache.jedis;

import redis.clients.jedis.Connection;
import redis.clients.jedis.Protocol;

import java.io.IOException;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;

public class RedisKeyMove {
    public static void main(String[] args) throws IOException {
        try (Connection connection = new Connection("10.1.253.188", 6379)) {
            Method method = Connection.class.getDeclaredMethod("sendCommand", Protocol.Command.class, String[].class);
            method.setAccessible(true);
            method.invoke(connection, Protocol.Command.MIGRATE,
                new String[]{"10.1.253.69", "6379", "name", "0", "1000", "copy"});
            System.out.println(connection.getBulkReply());
        } catch (NoSuchMethodException | IllegalAccessException | InvocationTargetException e) {
            e.printStackTrace();
        }
    }
}

6. Full‑Key Traversal

6.1 KEYS

KEYS returns all matching keys but blocks the single thread; it is discouraged in production when the keyspace is large.

6.2 Incremental Scan

Use SCAN to iterate keys without blocking:

mset n1 1 n2 2 n3 3 n4 4 n5 5 n6 6 n7 7 n8 8 n9 9 n10 10 n11 11 n12 12 n13 13

First iteration:

scan 0 match n* count 5   // returns up to 5 keys starting with 'n'

Subsequent calls use the cursor returned by the previous call until the cursor becomes 0.

6.3 SCAN vs KEYS Comparison

SCAN uses a cursor and does not block the server.

COUNT limits the number of returned elements (but is only a hint).

Both support pattern matching.

The server does not keep cursor state; the client tracks it.

SCAN may return duplicate keys; client must deduplicate.

Modifications during iteration may or may not be seen.

An empty result does not mean the iteration is finished; the cursor must be zero.

6.4 Other Iteration Commands

Similar incremental commands exist for specific data structures:

SSCAN – iterate set members.

HSCAN – iterate hash fields and values.

ZSCAN – iterate sorted‑set members and scores.

All follow the same cursor‑based usage as SCAN .

END