Redis缓存三大问题深度解析：穿透、击穿、雪崩的原理与实战解决方案

文章摘要

本文从底层原理、解决方法、代码实现、技术选型四个维度，系统性拆解Redis缓存最经典的三大问题：缓存穿透、缓存击穿、缓存雪崩。不仅讲清楚“是什么”和“为什么”，更提供了生产环境可直接运行的Java代码示例，包含基础版和Redisson生产级版两种实现，并针对不同业务场景给出了明确的技术选型建议和最佳实践。适合所有后端开发、架构师阅读，帮助你构建高性能、高可用的分布式缓存系统。

本文目录

前言

在现代分布式系统架构中，Redis作为高性能的内存数据库，几乎是所有高并发系统的标配。它通过将热点数据存储在内存中，将数据库的访问压力降低了90%以上，极大地提升了系统的整体响应速度。

然而，缓存的引入也带来了新的挑战。当缓存使用不当时，会出现缓存穿透、缓存击穿、缓存雪崩三大经典问题。这些问题如果处理不当，可能会导致数据库压力瞬间飙升至几十倍甚至上百倍，最终引发数据库宕机，整个系统瘫痪。

真实案例： 某电商平台在双十一活动中，由于热门商品缓存同时过期，导致数据库CPU使用率瞬间达到100%，系统宕机30分钟，直接经济损失超过千万元。

本文将带你深入理解这三大问题的本质，掌握最有效的解决方案，并提供可直接复制到生产环境的代码实现。

一、缓存穿透：无效请求的数据库噩梦

1.1 什么是缓存穿透

缓存穿透是指用户请求的数据既不在Redis缓存中，也不在后端数据库中。由于数据不存在，每次请求都会穿透整个缓存层，直接到达数据库层。如果有大量这样的无效请求，数据库将承受无法承受的压力，甚至被直接击垮。

典型攻击场景：

• 黑客恶意构造大量不存在的ID（如id=-1、id=999999999）进行批量请求
• 爬虫程序遍历不存在的资源ID
• 业务逻辑错误，导致重复查询不存在的数据

1.2 底层原理深度剖析

核心原理： 缓存穿透的本质是“无效请求绕过缓存直接打数据库”。由于这些数据永远不会被缓存，导致每次相同的请求都会重复访问数据库，形成恶性循环。

标准Redis查询流程：

问题就出在第5步：对于数据库中不存在的数据，我们没有在缓存层进行任何拦截，导致每次无效请求都必须访问数据库。

1.3 主流解决方案对比

方案一：缓存空值

当数据库查询返回空结果时，仍然将这个空值（或特殊标记值）缓存起来，并设置一个较短的过期时间（通常5-10分钟）。这样，后续相同的无效请求就会直接从缓存中获取空值，而不会再访问数据库。

优点： 实现极其简单，几乎没有额外开发成本
缺点：

• 会占用一定的Redis内存空间
• 如果黑客构造大量不同的无效key，仍然会穿透到数据库
• 可能会出现短时间的数据不一致（如果后续该key被创建）

方案二：布隆过滤器（Bloom Filter）

布隆过滤器是一种空间效率极高的概率型数据结构，它的核心特性是：

• 如果布隆过滤器说某个元素不存在，那么它一定不存在
• 如果布隆过滤器说某个元素存在，那么它可能存在（存在一定的误判率）

我们可以将数据库中所有存在的key预先存入布隆过滤器中。当有请求到来时，先通过布隆过滤器判断这个key是否存在：

• 如果布隆过滤器说不存在，直接返回空结果，无需访问缓存和数据库
• 如果说可能存在，再继续查询缓存和数据库

优点： 内存占用极小（100万条数据仅需几MB内存），查询速度极快，拦截效果优秀
缺点：

• 存在一定的误判率（可通过调整参数降低到0.01%以下）
• 删除元素困难（传统布隆过滤器不支持删除）
• 需要预先加载所有存在的key

1.4 完整代码实现

1.4.1 缓存空值实现（Spring Boot + RedisTemplate）

@Service
public class UserService {

@Autowired
private RedisTemplate<String, Object> redisTemplate;

@Autowired
private UserMapper userMapper;

// 缓存空值的过期时间：5分钟（不宜过长）
private static final long NULL_CACHE_EXPIRE = 5 * 60;
// 正常数据的过期时间：30分钟
private static final long NORMAL_CACHE_EXPIRE = 30 * 60;

public User getUserById(Long userId) {
String cacheKey = "user:info:" + userId;

// 1. 先查询Redis缓存
User user = (User) redisTemplate.opsForValue().get(cacheKey);
if (user != null) {
// 注意：这里需要判断是否是空值标记
return user instanceof NullUser ? null : user;
}

// 2. 缓存未命中，查询数据库
user = userMapper.selectById(userId);

// 3. 无论数据库是否存在，都写入缓存
if (user != null) {
// 存在则正常缓存
redisTemplate.opsForValue().set(cacheKey, user, NORMAL_CACHE_EXPIRE, TimeUnit.SECONDS);
} else {
// 不存在则缓存空值标记，设置较短过期时间
redisTemplate.opsForValue().set(cacheKey, new NullUser(), NULL_CACHE_EXPIRE, TimeUnit.SECONDS);
}

return user;
}

// 空用户标记类（用于区分正常null和缓存空值）
static class NullUser extends User {}
}

生产环境提示： 不要直接缓存null值，因为redisTemplate.opsForValue().get(null)会返回null，无法区分是缓存不存在还是缓存的就是null。建议使用一个特殊的标记类来表示空值。

1.4.2 布隆过滤器实现（Google Guava本地版）

@Configuration
public class BloomFilterConfig {

@Autowired
private UserMapper userMapper;

@Bean
public BloomFilter<Long> userBloomFilter() {
// 预期插入的数据量：100万
int expectedInsertions = 1000000;
// 期望的误判率：0.01%（误判率越低，内存占用越大）
double fpp = 0.0001;

// 创建布隆过滤器
BloomFilter<Long> bloomFilter = BloomFilter.create(
Funnels.longFunnel(),
expectedInsertions,
fpp
);

// 预加载数据库中所有存在的用户ID
List<Long> allUserIds = userMapper.selectAllUserIds();
for (Long userId : allUserIds) {
bloomFilter.put(userId);
}

return bloomFilter;
}
}

@Service
public class UserService {

@Autowired
private RedisTemplate<String, Object> redisTemplate;

@Autowired
private UserMapper userMapper;

@Autowired
private BloomFilter<Long> userBloomFilter;

public User getUserById(Long userId) {
// 1. 先通过布隆过滤器拦截无效请求
if (!userBloomFilter.mightContain(userId)) {
// 布隆过滤器说不存在，一定不存在，直接返回
return null;
}

// 2. 再查询Redis缓存
String cacheKey = "user:info:" + userId;
User user = (User) redisTemplate.opsForValue().get(cacheKey);
if (user != null) {
return user;
}

// 3. 最后查询数据库
user = userMapper.selectById(userId);
if (user != null) {
redisTemplate.opsForValue().set(cacheKey, user, 30, TimeUnit.MINUTES);
}

return user;
}
}

分布式系统提示： Guava的布隆过滤器是本地实现，每个应用实例都有自己的一份。如果是分布式系统，建议使用Redis官方的RedisBloom模块，实现全局共享的布隆过滤器。

1.5 技术选型建议

• 简单业务、数据量小于10万：优先选择缓存空值方案，实现简单，维护成本低
• 高并发、大数据量、有明确防攻击需求：优先选择布隆过滤器方案，内存占用小，拦截效果好
• 生产环境推荐：使用“布隆过滤器 + 缓存空值”的混合方案，布隆过滤器拦截99.99%的无效请求，缓存空值处理布隆过滤器误判的极少数情况

二、缓存击穿：热点key过期的瞬间灾难

2.1 什么是缓存击穿

缓存击穿是指某个访问量极高的热点key在缓存过期的瞬间，同时有大量并发请求访问这个key。由于缓存已经过期，所有这些请求都会穿透缓存直接到达数据库，导致数据库压力瞬间激增。

典型场景：

• 秒杀活动的商品信息缓存过期
• 热门新闻、热搜话题的缓存过期
• 爆款商品的详情页缓存过期

关键区别：

• 缓存穿透：数据本身不存在
• 缓存击穿：数据本身存在，但缓存过期了

2.2 底层原理深度剖析

核心原理： 缓存击穿的本质是“缓存重建期间的并发请求全部打向数据库”。当一个热点key过期时，在缓存重建完成之前，所有对这个key的请求都会直接访问数据库。如果这个key的QPS达到1万以上，瞬间就会把数据库打垮。

举个例子：假设某个爆款商品的缓存过期时间是30分钟，在第30分钟整的时候，同时有1万个用户访问这个商品的详情页。这1万个请求都会发现缓存已经过期，然后同时去查询数据库，数据库瞬间就会被这1万个请求压垮。

2.3 主流解决方案对比

方案一：热点数据永不过期

对于一些访问量极高且极少更新的热点数据，可以直接设置为永不过期。这样就从根本上避免了缓存过期导致的击穿问题。

优点： 实现最简单，性能最好
缺点：

• 数据更新不及时，只能通过手动更新缓存
• 占用Redis内存空间
• 可能会导致缓存与数据库数据不一致

方案二：互斥锁（Mutex Lock）

当缓存过期时，不是所有请求都去查询数据库，而是只允许一个请求去查询数据库并重建缓存。其他请求等待缓存重建完成后，再从缓存中获取数据。

通常使用Redis的SETNX（Set if Not Exists）命令来实现分布式互斥锁。

优点：

• 可以有效控制数据库的访问量，最多只有一个请求访问数据库
• 数据一致性较好
• 内存占用合理

缺点：

• 实现相对复杂，需要处理锁过期、死锁等问题
• 等待的请求会有一定的延迟
• 如果锁被意外释放，可能会导致多个请求同时重建缓存

方案三：逻辑过期

不设置缓存的物理过期时间，而是在缓存的value中添加一个逻辑过期时间字段。当查询到数据时，判断逻辑过期时间是否已到：

• 如果未过期，直接返回数据
• 如果已过期，异步启动一个线程去重建缓存，同时立即返回旧数据

优点：

• 不会出现大量请求等待的情况，响应速度极快
• 数据库压力极小，最多只有一个线程去重建缓存
• 性能最好

缺点：

• 数据一致性较差，在缓存重建完成前会返回旧数据
• 实现相对复杂
• 内存占用会稍微大一些（需要存储逻辑过期时间）

2.4 完整代码实现

2.4.1 互斥锁实现

2.4.1.1 基础版（RedisTemplate原生实现）

@Service
public class ProductService {

@Autowired
private RedisTemplate<String, Object> redisTemplate;

@Autowired
private ProductMapper productMapper;

// 锁的过期时间：10秒（防止死锁）
private static final long LOCK_EXPIRE = 10;
// 正常缓存过期时间：30分钟
private static final long CACHE_EXPIRE = 30 * 60;

public Product getProductById(Long productId) {
String cacheKey = "product:info:" + productId;
String lockKey = "lock:product:" + productId;

// 1. 先查询缓存
Product product = (Product) redisTemplate.opsForValue().get(cacheKey);
if (product != null) {
return product;
}

// 2. 缓存未命中，尝试获取分布式锁
try {
Boolean lockAcquired = redisTemplate.opsForValue()
.setIfAbsent(lockKey, "locked", LOCK_EXPIRE, TimeUnit.SECONDS);

if (Boolean.TRUE.equals(lockAcquired)) {
// 3. 获取锁成功，双重检查缓存（防止其他线程已经重建了缓存）
product = (Product) redisTemplate.opsForValue().get(cacheKey);
if (product != null) {
return product;
}

// 4. 查询数据库并重建缓存
product = productMapper.selectById(productId);
if (product != null) {
redisTemplate.opsForValue().set(cacheKey, product, CACHE_EXPIRE, TimeUnit.SECONDS);
}

return product;
} else {
// 5. 获取锁失败，等待50毫秒后重试
Thread.sleep(50);
return getProductById(productId);
}
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
return null;
} finally {
// 6. 释放锁（注意：生产环境中存在锁误删风险）
redisTemplate.delete(lockKey);
}
}
}

⚠️ 生产环境警告： 上述基础版实现存在锁误删的严重问题：如果线程A获取锁后执行时间过长，锁自动过期释放，此时线程B获取到锁；当线程A执行完成后，会错误地删除线程B持有的锁。生产环境中强烈建议使用Redisson的分布式锁，它已经完美解决了锁过期、锁续期、原子性释放等所有问题。

2.4.1.2 生产级版（Redisson分布式锁实现）

第一步：添加Redisson依赖

<!– pom.xml –>
<dependency>
<groupId>org.redisson</groupId>
<artifactId>redisson-spring-boot-starter</artifactId>
<version>3.23.5</version>
</dependency>

第二步：Redisson配置（application.yml）

spring:
redis:
host: 127.0.0.1
port: 6379
password: yourpassword
database: 0

第三步：生产级互斥锁代码实现

@Service
public class ProductService {

@Autowired
private RedisTemplate<String, Object> redisTemplate;

@Autowired
private ProductMapper productMapper;

@Autowired
private RedissonClient redissonClient;

// 正常缓存过期时间：30分钟
private static final long CACHE_EXPIRE = 30 * 60;
// 锁的等待时间：1秒（超过这个时间就不再等待）
private static final long LOCK_WAIT_TIME = 1;
// 锁的持有时间：10秒（Redisson会自动续期）
private static final long LOCK_LEASE_TIME = 10;

public Product getProductById(Long productId) {
String cacheKey = "product:info:" + productId;
String lockKey = "lock:product:" + productId;

// 1. 先查询缓存
Product product = (Product) redisTemplate.opsForValue().get(cacheKey);
if (product != null) {
return product;
}

// 2. 获取Redisson分布式锁
RLock lock = redissonClient.getLock(lockKey);

try {
// 3. 尝试获取锁：最多等待1秒，持有锁10秒
boolean lockAcquired = lock.tryLock(LOCK_WAIT_TIME, LOCK_LEASE_TIME, TimeUnit.SECONDS);

if (lockAcquired) {
// 4. 获取锁成功，双重检查缓存
product = (Product) redisTemplate.opsForValue().get(cacheKey);
if (product != null) {
return product;
}

// 5. 查询数据库并重建缓存
product = productMapper.selectById(productId);
if (product != null) {
redisTemplate.opsForValue().set(cacheKey, product, CACHE_EXPIRE, TimeUnit.SECONDS);
}

return product;
} else {
// 6. 获取锁失败，等待50毫秒后重试
Thread.sleep(50);
return getProductById(productId);
}
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
return null;
} finally {
// 7. 只有当前线程持有锁时才释放
if (lock.isHeldByCurrentThread()) {
lock.unlock();
}
}
}
}

Redisson分布式锁优势：

• 自动续期：如果业务执行时间超过锁的持有时间，Redisson会自动给锁续期
• 原子性释放：只有持有锁的线程才能释放锁，避免锁误删
• 可重入性：同一个线程可以多次获取同一把锁
• 丰富的锁类型：支持公平锁、读写锁、联锁等多种锁类型

2.4.2 逻辑过期实现

/**
* 带逻辑过期时间的缓存数据包装类
*/
@Data
@AllArgsConstructor
@NoArgsConstructor
public class RedisData<T> {
private T data;
// 逻辑过期时间
private LocalDateTime expireTime;
}

@Service
public class ProductService {

@Autowired
private RedisTemplate<String, Object> redisTemplate;

@Autowired
private ProductMapper productMapper;

@Autowired
private RedissonClient redissonClient;

// 缓存重建线程池
private static final ExecutorService CACHE_REBUILD_EXECUTOR =
Executors.newFixedThreadPool(10);
// 逻辑过期时间：30分钟
private static final long LOGIC_EXPIRE_MINUTES = 30;
// 锁的持有时间：10秒
private static final long LOCK_LEASE_TIME = 10;

public Product getProductById(Long productId) {
String cacheKey = "product:info:" + productId;

// 1. 查询缓存
RedisData<Product> redisData = (RedisData<Product>) redisTemplate.opsForValue().get(cacheKey);
if (redisData == null) {
return null;
}

// 2. 判断是否逻辑过期
Product product = redisData.getData();
if (redisData.getExpireTime().isAfter(LocalDateTime.now())) {
// 未过期，直接返回数据
return product;
}

// 3. 已过期，尝试获取锁并异步重建缓存
String lockKey = "lock:product:" + productId;
RLock lock = redissonClient.getLock(lockKey);

try {
// 尝试获取锁，不等待
boolean lockAcquired = lock.tryLock(0, LOCK_LEASE_TIME, TimeUnit.SECONDS);

if (lockAcquired) {
// 4. 获取锁成功，异步重建缓存
CACHE_REBUILD_EXECUTOR.submit(() -> {
try {
// 查询数据库
Product newProduct = productMapper.selectById(productId);
// 重建缓存，设置新的逻辑过期时间
RedisData<Product> newRedisData = new RedisData<>(
newProduct,
LocalDateTime.now().plusMinutes(LOGIC_EXPIRE_MINUTES)
);
redisTemplate.opsForValue().set(cacheKey, newRedisData);
} finally {
// 释放锁
if (lock.isHeldByCurrentThread()) {
lock.unlock();
}
}
});
}
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}

// 5. 无论是否获取到锁，都立即返回旧数据
return product;
}
}

2.5 技术选型建议

• 学习和演示场景：可以使用RedisTemplate基础版互斥锁，理解分布式锁的基本原理
• 生产环境：必须使用Redisson分布式锁，避免锁误删、死锁等问题
• 对性能要求极高、允许短暂数据不一致：选择逻辑过期方案，这是性能最好的解决方案
• 对数据一致性要求较高、并发量适中：选择Redisson互斥锁方案，兼顾性能和数据一致性
• 极少更新、访问量极高的热点数据：可以考虑设置永不过期，配合手动更新缓存

三、缓存雪崩：大面积失效的系统瘫痪危机

3.1 什么是缓存雪崩

缓存雪崩是指大量缓存数据在同一时间集中过期，或者Redis服务突然宕机，导致所有请求都直接到达数据库，数据库压力瞬间剧增，甚至可能导致数据库宕机，整个系统瘫痪。

典型场景：

• 系统上线时，大量缓存数据设置了相同的过期时间（如都是30分钟）
• Redis服务突然宕机
• 缓存服务器重启
• 缓存服务器网络中断

关键区别：

• 缓存击穿：单个热点key过期
• 缓存雪崩：大量key同时过期或Redis整体不可用

3.2 底层原理深度剖析

核心原理： 缓存雪崩的本质是“缓存层整体失效，导致流量洪峰直接冲击数据库”。与缓存击穿不同的是，缓存雪崩影响的是大量key甚至全部key，对数据库的破坏力要大得多。

当大量缓存同时过期时，数据库需要同时处理成千上万甚至上百万的查询请求，这远远超出了数据库的处理能力。数据库会因为CPU使用率过高或连接数耗尽而无法响应，最终导致整个系统瘫痪。

3.3 主流解决方案对比

方案一：过期时间加随机值

给每个缓存的过期时间都加上一个随机偏移量，避免大量缓存同时过期。例如，原本统一设置30分钟过期，现在可以设置为30分钟 ± 5分钟随机。

优点： 实现极其简单，成本极低，效果明显
缺点： 只能缓解大量key同时过期的问题，不能解决Redis宕机导致的雪崩

方案二：Redis集群与高可用

通过Redis主从复制、哨兵机制和集群部署，保证Redis服务的高可用性，避免Redis单点故障导致的缓存雪崩。

优点： 从根本上解决了Redis宕机导致的缓存雪崩问题
缺点： 部署和维护成本较高

方案三：多级缓存架构

使用多级缓存架构，例如：

• 一级缓存：Redis分布式缓存
• 二级缓存：应用本地缓存（Caffeine、Guava Cache）

当Redis缓存失效时，可以先查询本地缓存，如果本地缓存也不存在，再查询数据库。这样即使Redis宕机，本地缓存仍然可以提供服务，大大减少对数据库的访问压力。

优点：

• 可靠性极高，即使Redis宕机，系统仍然可以正常运行
• 响应速度更快，本地缓存的访问速度比Redis快一个数量级
• 可以有效分散数据库压力

缺点：

• 实现相对复杂
• 数据一致性更难保证
• 会占用应用服务器的内存

方案四：服务熔断与降级

当数据库压力过大时，启动服务熔断机制，暂时拒绝部分请求，保护数据库不被击垮。同时，对于非核心业务，可以进行服务降级，返回默认数据或错误信息。

优点： 可以有效保护数据库，防止系统完全瘫痪
缺点： 会影响用户体验，是最后的兜底方案

3.4 完整代码实现

3.4.1 过期时间加随机值

@Service
public class ProductService {

@Autowired
private RedisTemplate<String, Object> redisTemplate;

@Autowired
private ProductMapper productMapper;

// 基础过期时间：30分钟
private static final long BASE_EXPIRE_SECONDS = 30 * 60;
// 随机偏移量范围：±5分钟
private static final long RANDOM_OFFSET_SECONDS = 5 * 60;

public Product getProductById(Long productId) {
String cacheKey = "product:info:" + productId;

// 1. 查询缓存
Product product = (Product) redisTemplate.opsForValue().get(cacheKey);
if (product != null) {
return product;
}

// 2. 查询数据库
product = productMapper.selectById(productId);
if (product != null) {
// 3. 计算带随机偏移量的过期时间
long expireTime = BASE_EXPIRE_SECONDS +
new Random().nextLong(RANDOM_OFFSET_SECONDS * 2) – RANDOM_OFFSET_SECONDS;
// 4. 写入缓存
redisTemplate.opsForValue().set(cacheKey, product, expireTime, TimeUnit.SECONDS);
}

return product;
}
}

生产环境提示： 这是所有缓存系统都必须实现的基础防护措施，没有任何理由不做。

3.4.2 多级缓存实现（Redis + Caffeine）

@Configuration
public class LocalCacheConfig {

@Bean
public Cache<String, Product> productLocalCache() {
return Caffeine.newBuilder()
// 本地缓存最大容量：10000条
.maximumSize(10000)
// 写入后过期时间：5分钟
.expireAfterWrite(5, TimeUnit.MINUTES)
// 开启统计功能
.recordStats()
.build();
}
}

@Service
public class ProductService {

@Autowired
private RedisTemplate<String, Object> redisTemplate;

@Autowired
private ProductMapper productMapper;

@Autowired
private Cache<String, Product> productLocalCache;

// 基础过期时间：30分钟
private static final long BASE_EXPIRE_SECONDS = 30 * 60;
// 随机偏移量范围：±5分钟
private static final long RANDOM_OFFSET_SECONDS = 5 * 60;

public Product getProductById(Long productId) {
String cacheKey = "product:info:" + productId;

// 1. 先查询本地缓存（速度最快）
Product product = productLocalCache.getIfPresent(cacheKey);
if (product != null) {
return product;
}

// 2. 再查询Redis缓存
product = (Product) redisTemplate.opsForValue().get(cacheKey);
if (product != null) {
// 写入本地缓存
productLocalCache.put(cacheKey, product);
return product;
}

// 3. 最后查询数据库
product = productMapper.selectById(productId);
if (product != null) {
// 写入Redis缓存
long expireTime = BASE_EXPIRE_SECONDS +
new Random().nextLong(RANDOM_OFFSET_SECONDS * 2) – RANDOM_OFFSET_SECONDS;
redisTemplate.opsForValue().set(cacheKey, product, expireTime, TimeUnit.SECONDS);
// 写入本地缓存
productLocalCache.put(cacheKey, product);
}

return product;
}
}

3.5 技术选型建议

• 基础防护（必须做）：给所有缓存的过期时间加上随机值，这是成本最低、效果最明显的措施
• 高可用要求（必须做）：部署Redis主从+哨兵集群，避免Redis单点故障
• 高并发系统（推荐做）：使用多级缓存架构，进一步提升系统的可靠性和性能
• 核心系统（必须做）：实现服务熔断与降级机制，作为最后一道防线

四、三大问题核心对比表

五、生产环境通用最佳实践

六、总结与展望

缓存穿透、缓存击穿和缓存雪崩是Redis缓存系统中最常见的三大问题，也是每个后端开发工程师必须掌握的核心技能。理解它们的底层原理，掌握正确的解决方法，是构建高性能、高可用分布式系统的基础。

本文详细介绍了这三大问题的原理、解决方法、代码实现和技术选型，特别对比了基础版和Redisson生产级版的互斥锁实现，并提供了生产环境的最佳实践。在实际开发中，我们需要根据自己的业务场景和需求，选择合适的解决方案，并结合多种方法进行综合防护，才能构建出真正健壮的缓存系统。

记住，缓存不是银弹，合理使用才能发挥它的最大价值。

写在最后

如果这篇文章对你有帮助，欢迎点赞、收藏、关注，我会持续分享更多分布式系统和后端开发的干货。如果你有任何问题或建议，欢迎在评论区留言交流。