Redis 客户端的重试机制与幂等性操作 - 智猿学院-IT界的百科全书

好的，各位观众老爷，欢迎来到今天的“Redis 重试与幂等性：不怕宕机，稳如老狗”专场！我是你们的老朋友，人称“Bug 终结者”的程序猿小强。今天咱们不聊高深的理论，就用最接地气的方式，聊聊 Redis 客户端重试机制，以及如何让你的 Redis 操作拥有“不死之身”——幂等性。

开场白：Redis，你别给我掉链子！

想象一下，你的电商系统正在进行一场如火如荼的促销活动，用户像潮水般涌来，购物车里塞满了各种商品，付款的按钮都快被点烂了。突然，Redis 抽风了！缓存失效、连接超时、甚至直接宕机… 😱 这画面太美我不敢看！

如果没有重试机制，用户点击付款后，系统返回一个“支付失败”的提示，用户可能直接放弃购买，损失那可不是一点点。如果没有幂等性，用户可能因为网络波动或者其他原因重复提交订单，导致重复扣款，那客服电话估计要被打爆了。 🤯

所以，Redis 的重试机制和幂等性，就像是给你的系统上了双保险，保证在面对各种突发情况时，依然能够稳如老狗，让用户体验丝滑流畅。

第一幕：重试机制，掉线了？不存在的！

重试机制，简单来说，就是当 Redis 客户端与服务器的连接出现问题时，客户端会自动尝试重新连接并执行之前的操作。就像一个尽职尽责的快递员，第一次送货上门发现你不在家，他不会直接把包裹扔了，而是会尝试第二次、第三次，直到把你找到为止。

1. 为什么需要重试？

网络波动： 网络环境复杂多变，偶尔出现抖动是家常便饭。
服务器重启： Redis 服务器可能会因为维护、升级等原因重启。
连接超时： 客户端与服务器之间的连接可能会因为长时间没有数据交互而超时。
服务器过载： 在高并发场景下，Redis 服务器可能会因为负载过高而拒绝新的连接。

2. 重试策略：如何优雅地重试？

重试不是盲目的，需要制定合理的策略，否则可能会适得其反，加重服务器的负担。常见的重试策略有：

固定延迟重试： 每次重试之间等待固定的时间。就像一个耐心的老爷爷，每次敲门都隔五分钟。
指数退避重试： 每次重试之间等待的时间呈指数增长。第一次失败等待 1 秒，第二次失败等待 2 秒，第三次失败等待 4 秒… 这样可以避免在服务器恢复后，大量的客户端同时发起重试请求，造成更大的拥堵。
随机退避重试： 在指数退避的基础上，增加一个随机的延迟时间。就像一个调皮的孩子，每次敲门的时间间隔都不一样，让人捉摸不透。这样可以进一步分散重试请求，减少冲突。

3. 重试配置：不同客户端，不同玩法

不同的 Redis 客户端，重试机制的配置方式也略有不同。这里以常用的 Jedis 和 Lettuce 为例：

Jedis:

Jedis 默认没有开启重试机制，需要手动配置。可以通过 JedisPoolConfig 或者 JedisSentinelPool 来设置。

JedisPoolConfig poolConfig = new JedisPoolConfig();
// 最大连接数
poolConfig.setMaxTotal(100);
// 最大空闲连接数
poolConfig.setMaxIdle(50);
// 最小空闲连接数
poolConfig.setMinIdle(10);
// 连接超时时间
poolConfig.setConnectionTimeout(5000);
// 读取超时时间
poolConfig.setSoTimeout(5000);
// 获取连接时的最大等待时间
poolConfig.setMaxWaitMillis(10000);
// 连接池中资源耗尽时是否阻塞，true：阻塞，false：抛出异常
poolConfig.setBlockWhenExhausted(true);
// 是否在从连接池获取连接前进行验证，如果验证失败，则从连接池中移除连接
poolConfig.setTestOnBorrow(true);

// 单机模式
JedisPool jedisPool = new JedisPool(poolConfig, "redis.example.com", 6379, 5000, "password");

// 哨兵模式
Set<String> sentinels = new HashSet<>();
sentinels.add("redis-sentinel-1:26379");
sentinels.add("redis-sentinel-2:26379");
sentinels.add("redis-sentinel-3:26379");
JedisSentinelPool jedisSentinelPool = new JedisSentinelPool("mymaster", sentinels, poolConfig, 5000, "password");

// 使用 Jedis
try (Jedis jedis = jedisPool.getResource()) {
    jedis.set("foo", "bar");
    String value = jedis.get("foo");
    System.out.println(value);
} catch (Exception e) {
    // 处理异常，可以根据异常类型判断是否需要重试
    System.err.println("Redis 操作失败：" + e.getMessage());
    // 这里可以添加重试逻辑
}

注意: Jedis 官方推荐使用 Lettuce，因为 Jedis 在多线程环境下存在线程安全问题。

Lettuce:

Lettuce 提供了更强大的重试机制，可以通过 ClientOptions 和 RetryOptions 来配置。

RedisClient redisClient = RedisClient.create("redis://[email protected]:6379/0");
ClientOptions clientOptions = ClientOptions.builder()
        // 开启自动重连
        .autoReconnect(true)
        // 重试选项
        .retryOptions(RetryOptions.builder()
                // 最大重试次数
                .maxAttempts(3)
                // 重试间隔时间
                .fixedDelay(Duration.ofMillis(100))
                .build())
        .build();
redisClient.setOptions(clientOptions);

StatefulRedisConnection<String, String> connection = redisClient.connect();
RedisCommands<String, String> commands = connection.sync();

try {
    commands.set("foo", "bar");
    String value = commands.get("foo");
    System.out.println(value);
} catch (Exception e) {
    // 处理异常，可以根据异常类型判断是否需要重试
    System.err.println("Redis 操作失败：" + e.getMessage());
    // Lettuce 已经配置了自动重试，这里可以记录日志或者进行其他处理
} finally {
    connection.close();
    redisClient.shutdown();
}

表格：Jedis vs Lettuce 重试机制对比

特性	Jedis	Lettuce
默认重试	无	默认无，但可以方便地通过 `ClientOptions` 和 `RetryOptions` 开启和配置
配置方式	`JedisPoolConfig` 或 `JedisSentinelPool`	`ClientOptions` 和 `RetryOptions`
线程安全	线程不安全	线程安全
推荐使用	不推荐	推荐

4. 重试的注意事项

避免无限重试： 设置最大重试次数，防止程序陷入死循环。
监控重试情况： 记录重试日志，方便排查问题。
区分可重试和不可重试的错误： 比如，NoSuchKeyException 这种错误，重试也没用，直接放弃。
考虑业务场景： 某些场景下，重试可能会导致数据不一致，需要谨慎使用。

第二幕：幂等性，重复提交？不存在的！

幂等性，是指一个操作，无论执行多少次，产生的结果都是一样的。就像你按电梯的“关门”按钮，按一次和按十次的效果是一样的，电梯只会关一次。

1. 为什么需要幂等性？

网络抖动： 客户端发送请求后，可能没有收到服务器的响应，导致客户端认为请求失败，进行重试。
重复提交： 用户可能会因为误操作或者恶意攻击，重复提交相同的请求。
消息队列： 消息队列可能会因为各种原因，重复发送相同的消息。

2. 实现幂等性的几种姿势

唯一 ID： 为每个请求生成一个唯一的 ID，Redis 客户端在执行操作之前，先检查这个 ID 是否已经存在。如果存在，说明请求已经被执行过，直接返回成功；如果不存在，执行操作，并将 ID 存储起来。就像给每个包裹贴上唯一的条形码，避免重复发货。

public boolean executeWithIdempotency(String requestId, String key, String value) {
    String idempotentKey = "request:" + requestId;
    // 尝试设置一个带有过期时间的 key，如果设置成功，说明是第一次执行
    boolean success = redisTemplate.opsForValue().setIfAbsent(idempotentKey, "1", Duration.ofSeconds(60));
    if (success) {
        try {
            // 执行业务逻辑
            redisTemplate.opsForValue().set(key, value);
            return true;
        } finally {
            // 无论成功还是失败，都要删除 key，释放资源
            redisTemplate.delete(idempotentKey);
        }
    } else {
        // 说明已经执行过，直接返回成功
        return true;
    }
}

版本号控制： 为每个数据添加一个版本号，每次更新数据时，版本号加 1。Redis 客户端在更新数据时，需要携带版本号，只有当版本号与服务器上的版本号一致时，才能更新成功。就像给每个文件加上版本号，避免覆盖旧版本。

public boolean updateWithVersion(String key, String newValue, long expectedVersion) {
    String script = "if redis.call('get', KEYS[1]) == ARGV[1] then " +
            "  redis.call('set', KEYS[1], ARGV[2]); " +
            "  return 1; " +
            "else " +
            "  return 0; " +
            "end";

    List<String> keys = Collections.singletonList(key);
    List<String> args = Arrays.asList(String.valueOf(expectedVersion), newValue);

    Long result = redisTemplate.execute(
            (RedisScript<Long>) RedisScript.of(script, Long.class),
            keys,
            args.toArray()
    );

    return result != null && result == 1;
}

状态机： 定义数据的状态，只有在特定的状态下才能执行特定的操作。就像一个交通信号灯，只有在绿灯亮起时，车辆才能通行。

public boolean processOrder(String orderId, String action) {
    String orderStatusKey = "order:" + orderId + ":status";
    String currentStatus = redisTemplate.opsForValue().get(orderStatusKey);

    // 根据当前状态和 action 进行不同的处理
    if ("CREATED".equals(currentStatus) && "PAY".equals(action)) {
        // 支付订单
        redisTemplate.opsForValue().set(orderStatusKey, "PAID");
        return true;
    } else if ("PAID".equals(currentStatus) && "SHIP".equals(action)) {
        // 发货
        redisTemplate.opsForValue().set(orderStatusKey, "SHIPPED");
        return true;
    } else {
        // 不允许的操作，直接返回失败
        return false;
    }
}

3. 幂等性的注意事项

选择合适的方案： 不同的场景，需要选择不同的幂等性方案。
考虑性能： 幂等性会增加一定的性能开销，需要在性能和可靠性之间进行权衡。
保证原子性： 幂等性操作需要保证原子性，可以使用 Redis 的事务或者 Lua 脚本来实现。

第三幕：总结与展望

今天，我们一起学习了 Redis 客户端的重试机制和幂等性，相信大家对如何构建一个高可用、高可靠的 Redis 应用有了更深入的理解。

重试机制： 保证在 Redis 连接出现问题时，能够自动重试，避免业务中断。
幂等性： 保证在重复提交请求时，不会产生副作用，避免数据不一致。

未来，随着 Redis 的不断发展，相信会有更多更强大的特性出现，让我们一起学习，一起进步，共同构建更加健壮、高效的 Redis 应用！

结尾：彩蛋时间

最后，送给大家一句箴言：

“代码虐我千百遍，我待代码如初恋。Redis 宕机我不怕，重试幂等来护驾！”

谢谢大家！ 👏 希望今天的分享对大家有所帮助！如果觉得有用，请点赞、评论、转发，三连支持一下！ 😉

发表回复 取消回复

发表回复取消回复