## 01、痛点

上周三晚上十一点，报警群里突然炸了：商品详情接口响应时间从 80ms 飙到 3.2s，数据库连接池被占满，紧接着 PV 统计开始对不上数。我是老李，一个被 Redis 救过无数次的技术老兵。排查下来，原因并不复杂：每次商品详情都直接打到 MySQL，压力一上来查询排队；同时商品访问次数用了典型的“读出来加一写回去”，100 个实例并发时，丢失的更新次数比统计报表还难看。

这类问题在中小团队非常常见。商品缓存、计数器、验证码、接口幂等、分布式序列，看起来是不同的业务需求，但底层都指向同一个东西：一个能够高速读写、并且具备原子操作能力的存储结构。很多人以为 Redis String 只是 set/get，背了一堆命令，真到并发场景还是翻车。今天不聊花活，就聊 Redis 最基础也最重要的 String，以及它如何解决这些具体问题。

## 02、是什么

Redis String 是 Redis 中最简单的数据结构，但它不是只能存字符串。它二进制安全，最大支持 512MB，可以存放普通文本、JSON、数字、序列化后的对象，甚至图片字节流。很多场景下，String 都足够用。

真正要重点掌握的，不是全部命令，而是四个核心能力：

SET NX EX：只在 Key 不存在时写入，并设置过期时间。这是实现分布式锁、幂等 Key 的基础。NX 表示 Not eXists，EX 表示超时秒数。

INCR / INCRBY：对整数类型的值做原子自增。不要用 get 出来加一再 set 回去，那样在高并发下会丢更新。

MGET / MSET：批量读取和批量写入。减少网络往返，是优化缓存穿透和批量查询的关键。

原子性：单个命令在 Redis 服务端执行时不会被其他客户端命令打断。这是 Redis String 能解决并发计数问题的根本原因。

比如幂等控制，一条 SET uuid 1 NX EX 10 就能确保 10 秒内同一个请求标识只能写入一次。比如计数器，一条 INCR pv:1001 就能保证每次访问都精确加一。比如批量缓存，MGET key1 key2 key3 一次拿回三个 Key，而不是三次网络往返。这些命令本身并不复杂，复杂的是你是否在正确的时机使用它们。

## 03、为什么

为什么 Redis String 的 INCR 能解决并发自增，而 MySQL 的 count++ 不行？这里必须讲清楚原子性的含义。

MySQL 中常见的读改写逻辑是：先 SELECT count FROM goods WHERE id=1001；然后在应用内存里 +1；再 UPDATE goods SET count=? WHERE id=1001。当 100 个实例同时执行时，可能出现这样的交错：A 和 B 都读到 count=0，A 更新为 1，B 更新为 1，实际两次操作却只加了 1。这就是典型的更新丢失，因为读和写之间有时间窗口，多个事务可以同时读取旧值。

要解决 MySQL 的问题，通常需要加行锁、乐观锁或事务隔离级别，但代价是数据库压力大、吞吐量下降。

Redis 不同。Redis 服务端使用单线程事件循环处理命令。当客户端发送 INCR pv:1001 时，服务端在一条命令内完成以下动作：读取当前值、加一、写回内存。这个过程是原子的，中间不会有其他命令插入。即使 100 个客户端同时发送 INCR，服务端也会把它们排成队列，一个一个执行。因此 100 次 INCR 最终一定增加 100，不会丢失任何一次更新。

这就是为什么在计数、库存扣减、限流等场景，Redis 的单命令原子性远优于数据库的读改写。当然 Redis 单线程也有代价：单个命令不能太重，比如 KEYS、大 Key 操作会阻塞其他命令；数据主要存在内存，持久化配置不当可能丢数据。但单纯就并发自增来说，INCR 是成本最低、语义最清晰的方案。

## 04、架构

在一个典型的 Spring Boot 服务里，Redis String 通常扮演两类角色：缓存和原子计数器。

架构上，请求进入 Controller，经过 Service 层，优先查 Redis 缓存。如果缓存命中，直接返回；如果未命中，则查询 MySQL，将结果序列化后写入 Redis，并设置合理的过期时间。这是经典的 Cache Aside 模式，适合商品详情、用户信息等读多写少的数据。

对于访问次数这类计数需求，不建议走“读缓存-加一-写回”的路径，而是直接调用 INCR。计数器 Key 可以独立于缓存 Key 存在，比如 cache:goods:1001 存商品详情，pv:goods:1001 存访问次数。两者互不干扰，也不需要在业务代码里做复杂的同步。

对于接口幂等，可以在请求进入 Controller 之前，从请求头或请求体中取出幂等标识，执行 SET uuid 1 NX EX 10。如果返回 true，说明是第一次请求，继续处理业务；如果返回 false，说明 10 秒内重复请求，直接返回“请勿重复提交”。这比在数据库里建唯一索引更灵活，比在内存 Map 里实现更适合分布式环境。

对于验证码，短信验证码、图形验证码都可以用 String 存储，Key 是手机号或会话 ID，Value 是验证码，TTL 5 分钟。更新或校验时可以直接覆盖或删除。

批量场景则使用 MGET/MSET 减少网络开销。比如首页要展示多个商品的缓存，可以一次 MGET 取出，而不是循环 GET。

整体架构上，Redis 作为 MySQL 前面的高速缓冲层和原子操作层，能显著降低数据库压力，同时提供精确的计数和幂等能力。但它不是数据库的替代品，需要设置最大内存、淘汰策略、持久化策略和监控告警。

## 05、实战

下面直接看 Spring Boot 里怎么用 StringRedisTemplate 或 RedisTemplate 的 opsForValue() 实现商品详情缓存和访问计数。

1. 商品详情接口

@Service
public class GoodsService {
    @Resource
    private StringRedisTemplate stringRedisTemplate;
    @Resource
    private GoodsMapper goodsMapper;
    @Resource
    private ObjectMapper objectMapper;

    public GoodsDetail getGoodsDetail(Long goodsId) {
        String cacheKey = "cache:goods:" + goodsId;
        String cached = stringRedisTemplate.opsForValue().get(cacheKey);
        if (cached != null) {
            // 记录访问次数
            stringRedisTemplate.opsForValue().increment("pv:goods:" + goodsId);
            try {
                return objectMapper.readValue(cached, GoodsDetail.class);
            } catch (Exception e) {
                // 解析失败则查库
            }
        }
        GoodsDetail detail = goodsMapper.selectById(goodsId);
        if (detail == null) {
            return null;
        }
        try {
            stringRedisTemplate.opsForValue().set(cacheKey, objectMapper.writeValueAsString(detail), 30, TimeUnit.MINUTES);
        } catch (Exception ignored) {
        }
        // 同样记录访问次数
        stringRedisTemplate.opsForValue().increment("pv:goods:" + goodsId);
        return detail;
    }
}

这里有两个 Key：cache:goods:1001 保存商品详情的 JSON，TTL 30 分钟；pv:goods:1001 保存访问次数，每次请求 INCR 一次，不需要 TTL 也可以，但最好根据业务定期归档或清理。

2. PV 计数接口

@GetMapping("/pv/{goodsId}")
public Long getPv(@PathVariable Long goodsId) {
    String pvKey = "pv:goods:" + goodsId;
    String value = stringRedisTemplate.opsForValue().get(pvKey);
    return value == null ? 0L : Long.parseLong(value);
}

如果要做防刷，可以在 INCR 之前加 SET NX EX 限制同一用户短时间只计一次，但这里暂时不展开。

3. 验证码存储

public void sendSmsCode(String phone) {
    String code = String.valueOf(new Random().nextInt(9000) + 1000);
    String smsKey = "sms:code:" + phone;
    // 5 分钟有效
    stringRedisTemplate.opsForValue().set(smsKey, code, 5, TimeUnit.MINUTES);
    // 发送短信...
}

校验时：

public boolean verifySmsCode(String phone, String inputCode) {
    String smsKey = "sms:code:" + phone;
    String saved = stringRedisTemplate.opsForValue().get(smsKey);
    if (saved != null && saved.equals(inputCode)) {
        stringRedisTemplate.delete(smsKey);
        return true;
    }
    return false;
}

4. 幂等控制

public boolean tryAcquireIdempotent(String requestId) {
    String key = "idempotent:" + requestId;
    Boolean success = stringRedisTemplate.opsForValue().setIfAbsent(key, "1", 10, TimeUnit.SECONDS);
    return Boolean.TRUE.equals(success);
}

在 Controller 层，如果 tryAcquireIdempotent 返回 false，直接返回“重复提交”。真正处理完业务后，可以选择删除 Key 或等待其过期。

这些代码都基于 opsForValue()，底层就是 String 数据结构。生产环境中还要注意序列化方式：如果使用 RedisTemplate 默认的 JDK 序列化，Key 会带二进制前缀，不直观，建议使用 StringRedisTemplate 或配置 JSON 序列化器。另外缓存穿透、缓存雪崩、缓存击穿等问题也要配套处理，比如空值缓存、分布式锁、随机 TTL 等。

## 06、洞见

回到开头那个测验：100 个实例同时执行 count++，为什么数据库读改写可能丢数据，而 Redis INCR 不会？

最核心的原因是操作粒度。数据库的读改写是三个独立步骤，应用代码在中间做了加法，多个事务之间没有隔离保证时，后提交的更新会覆盖先提交的更新。即使将读和写放在同一个事务里，默认隔离级别下也可能产生更新丢失。要解决必须引入悲观锁或乐观锁，复杂度上升。

Redis 的 INCR 是一条命令，服务端单线程执行，读取、加法、写回在同一个命令周期内完成。这个周期对外不可分割，其他客户端命令无法插入。所以 100 次 INCR 就是 100 次自增，结果不会少。

但这里有两个常见误区需要提醒。

第一，单命令原子性不代表多个命令组合也是原子的。比如先 GET 再判断再 SET，中间就可能被其他客户端干扰。如果需要保证多步操作的原子性，应该使用 Lua 脚本、事务或锁。不过在计数场景，简单 INCR 就够了。

第二，Redis 主从复制是异步的。如果主节点刚执行完 INCR 后宕机，从节点可能还没有收到这条命令，客户端返回成功后数据可能丢失。对于要求强一致的计数，需要权衡。一般访问计数允许少量丢失，因为它们更多是趋势分析，不要求绝对精确。但如果是订单号、库存扣减等强一致场景，就要考虑 Redis 的持久化和复制策略，甚至回到数据库。

另外，单线程模型意味着单个命令执行时间必须短。如果某个 String 特别大，比如几 MB 的 JSON，GET 和 SET 会占用较长时间，阻塞其他命令。所以 String 适合小对象，大对象建议拆分或使用其他数据结构。

## 07、行动

如果让你明天就开始优化，我建议按下面这份清单落地：

第一，把读多写少、查询频繁的数据放进 Redis String 缓存，设置合理的 TTL。商品详情、字典数据、用户信息都是典型对象。序列化建议使用 JSON，Key 设计要有命名空间和业务含义，比如 cache:goods:1001，不要随意。

第二，凡是计数、访问量、自增序列，一律使用 INCR / INCRBY，禁止出现 get 后加一再 set。100 个实例并发时，这一条能帮你少背很多锅。

第三，接口幂等、防重复提交，使用 SET NX EX。比如支付回调、优惠券领取、下单接口，从请求参数中生成唯一请求 ID，用 setIfAbsent 控制。过期时间要覆盖业务处理时间。

第四，批量读取使用 MGET/MSET。尤其是首页、列表页需要多个 Key 时，一次 MGET 比循环 GET 减少网络 RTT，性能可以提升数倍。

第五，给 Redis 设置最大内存和淘汰策略。不要默认不限制，一旦内存打满，写入失败甚至影响已有数据。常见策略是 allkeys-lru 或 allkeys-lfu，根据业务热数据选择。

第六，做好监控。关注内存使用率、命中率、命令延迟、慢查询、连接数。缓存命中率低于 60% 就要检查 Key 设计和 TTL 是否合理。

第七，避免大 Key。String 虽然最大 512MB，但实际使用不要超过 10KB。大对象 JSON 会拖慢网络和单线程处理，尤其是批量操作时影响更明显。

第八，缓存穿透、击穿、雪崩三个问题要心里有数。空值缓存、互斥锁、随机 TTL 是基础解法，不要等到压力上来才补救。

这些行动都不是高深技巧，但真正落实到每个接口，效果立竿见影。

## 08、小结

Redis String 是 Redis 中最简单却最重要的数据结构。它最大的价值不是命令多，而是单命令原子性带来的并发安全。掌握 SET NX EX、INCR、MGET/MSET，就能覆盖缓存、计数器、验证码、幂等控制、批量读取等大量场景。Spring Boot 中通过 opsForValue() 可以方便地实现这些能力。看完这篇文章，希望你至少记住一件事：以后写 count++，先想想能不能用 INCR。

## 09、链接与概念说明

String：Redis 基础数据类型，二进制安全，可存任意字符串或数字。官方文档：https://redis.io/docs/data-types/strings/

SET NX EX：SET 命令带 NX 只当 Key 不存在时写入，EX 设置过期时间（秒）。可用于分布式锁和幂等 Key。官方命令：https://redis.io/commands/set/

INCR：对存储的数字执行原子加一，返回加后的值。官方命令：https://redis.io/commands/incr/

MGET/MSET：一次读写多个 Key，减少网络往返。官方命令：https://redis.io/commands/mget/ 和 https://redis.io/commands/mset/

原子性：在 Redis 中，单个命令执行期间不会被其他命令打断。原因是服务端单线程处理命令。注意多命令组合不保证原子，需使用 Lua 或事务。

缓存穿透：查询不存在的数据导致请求打到数据库。可用空值缓存或布隆过滤器缓解。

缓存击穿：热点 Key 过期瞬间大量请求打到数据库。可用互斥锁或逻辑过期。

缓存雪崩：大量 Key 同时过期或 Redis 宕机。可设置随机 TTL、多级缓存、高可用部署。

Spring Data Redis：Spring 生态下操作 Redis 的框架，提供 RedisTemplate 和 StringRedisTemplate。文档：https://spring.io/projects/spring-data-redis

Redis 持久化：RDB 和 AOF 两种方式，用于重启恢复数据。注意默认配置下可能丢失最近写入。文档：https://redis.io/docs/management/persistence/

以上链接和概念有助于进一步理解 Redis String 及其应用。

上周三晚上十一点，报警群里突然炸了：商品详情接口响应时间从 80ms 飙到 3.2s，数据库连接池被占满，紧接着 PV 统计开始对不上数。我是老李，一个被 Redis 救过无数次的技术老兵。排查下来，原因并不复杂：每次商品详情都直接打到 MySQL，压力一上来查询排队；同时商品访问次数用了典型的“读出来加一写回去”，100 个实例并发时，丢失的更新次数比统计报表还难看。

《Redis 8.10 + Spring Boot 实战》第3招 String——从缓存、计数器到分布式状态

从商品详情缓存到高并发计数，讲透 Redis String 的 SET NX EX、INCR、MGET/MSET 和原子性，并用 Spring Boot 实战演

架构师

数据库

后端

开发工具

Redis String实战解析：从商品缓存、PV原子计数到接口幂等，用SETNXEX、INCR、MGET解决并发更新丢失与性能瓶颈，SpringBoot案例与架构优化全指南。

数据库连接池

数据结构

验证码

短信

MySQL

Redis

JSON

腾讯云BI特惠9.9元起！


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

《Redis 8.10 + Spring Boot 实战》第3招 String——从缓存、计数器到分布式状态-腾讯云开发者社区-腾讯云

《Redis 8.10 + Spring Boot 实战》第3招 String——从缓存、计数器到分布式状态

《Redis 8.10 + Spring Boot 实战》第3招 String——从缓存、计数器到分布式状态

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐