前言

前段时间，有位小伙伴去小米面试，被问到一个经典题目：“Redis为什么能支撑10万+ QPS？”

他回答“因为它是内存数据库”，面试官追问：“Memcached也是内存数据库，为什么Redis能处理更复杂的数据结构还更快？”他一时语塞，直接挂了。

今天这篇文章专门跟大家一起聊聊这个话题，希望对你会有所帮助。

一、开篇：10万+ QPS是什么概念？

先看一组官方基准测试数据（普通笔记本环境下）：

• GET请求：约 103,504 QPS
• SET请求：约 100,894 QPS
• INCR请求：约 99,662 QPS

前言

最近面试季，好多小伙伴都反馈同一个问题：“面试官问我Redis的使用场景，我只说了缓存，结果当场被怼——‘就这？’”

其实，Redis远不止“缓存”这么简单。

它是一个多才多艺的选手，凭借内存读写、丰富的数据结构、原子操作、持久化、高可用等特性，几乎渗透到了后端开发的所有角落。

今天这篇文章就专门跟大家一起聊聊Redis的11种使用场景，希望对你会有所帮助。

场景一：高速缓存（最经典）

业务场景

查询商品详情、用户信息等高频读数据，把数据库扛不住的读压力放到Redis。

代码示例（旁路缓存模式）

@Service
public class ProductService {
    @Autowired
    private RedisTemplate<String, Product> redisTemplate;
    @Autowired
    private ProductMapper productMapper;

    public Product getProduct(Long id) {
        String cacheKey = "product:" + id;
        // 1. 读缓存
        Product product = redisTemplate.opsForValue().get(cacheKey);
        if (product != null) {
            return product;
        }
        // 2. 缓存未命中，查DB
        product = productMapper.selectById(id);
        if (product != null) {
            // 3. 写缓存，随机过期时间防雪崩
            int expire = 300 + new Random().nextInt(60);
            redisTemplate.opsForValue().set(cacheKey, product, expire, TimeUnit.SECONDS);
        }
        return product;
    }
}

前言

在很多小伙伴的印象中，Redis就是一个用来做缓存的工具。

但如果你只把它当作缓存，那真是“杀鸡用牛刀”了。

Redis的强大远不止于此，它的高级特性可以让你的系统在性能、扩展性、可靠性上直接起飞。

今天这篇文章就跟大家聊聊Redis中10种高级用法，希望对你会有所帮助。

一、布隆过滤器

有些小伙伴在做高并发系统时，最怕的就是缓存穿透——大量请求直接打穿缓存，压垮数据库。

布隆过滤器就是解决这个问题的利器。

1.1 什么是布隆过滤器

布隆过滤器是一种空间效率极高的概率型数据结构，用于判断一个元素是否存在于一个集合中。

它的特点是：

• 极省内存：存储1亿个元素，只需要约100MB内存
• 存在误判：判断“不在”一定准确；判断“在”可能误判（小概率）
• 不可删除：不支持删除元素

前言

今天我们来聊聊一个非常经典的话题：JWT和Token+Redis两种认证方案，到底哪种更好用？

有些小伙伴在工作中可能会纠结于选择哪种方案，今天我就从底层原理到实际应用，给大家做一个全面的剖析。

希望对你会有所帮助。

一、认证与授权

在深入讨论之前，我们先明确两个基本概念：

1. 认证（Authentication）：你是谁？验证用户身份的过程
2. 授权（Authorization）：你能做什么？验证用户权限的过程

无论是JWT还是Token+Redis，都是用来解决这两个问题的技术方案。

前言

今天想和大家深入聊聊Redis为什么能够轻松抗住百万级别的并发请求。

有些小伙伴在工作中可能遇到过这样的场景：系统访问量一上来，数据库就扛不住了，这时候大家第一时间想到的就是Redis。

但你有没有想过，为什么Redis能够承受如此高的并发量？它的底层到底做了什么优化？

今天我们就从浅入深，一步步揭开Redis高性能的神秘面纱。

1. Redis高并发的核心架构

1.1 单线程模型的威力

有些小伙伴可能会疑惑：Redis是单线程的，为什么还能支持这么高的并发？

这里需要澄清一个概念，Redis的"单线程"指的是网络IO和键值对读写是由一个线程来完成的，但Redis的整个系统并不是只有一个线程。

前言

Redis作为一种优秀的基于key/value的缓存中间件，有非常不错的性能和稳定性，无论是在工作中，还是面试中，都经常会出现。

今天这篇文章就跟大家一起聊聊，我在实际工作中使用Redis的10种场景，希望对你会有所帮助。

1 统计访问次数

对于很多官方网站的首页，经常会有一些统计首页访问次数的需求。

访问次数只有一个字段，如果保存到数据库中，再最后做汇总显然有些麻烦。

该业务场景可以使用Redis，定义一个key，比如：OFFICIAL_INDEX_VISIT_COUNT。

在Redis中有incr命令，可以实现给value值加1操作：

incr OFFICIAL_INDEX_VISIT_COUNT

前言

我们日常工作中，在使用Redis的时候，不知道你有没有遇到过这种情况。

我们定义了某对key/value保存数据，然后在查询接口中，通过该key可以查询出value的数据，返回给用户。

这个功能刚开始上线的一两年，性能都OK。

但随着时间的推移，会发现通过key查询value的性能越来越差。

我们定位原因之后发现，是value值越来越大导致的问题。

这就是Redis的大key问题。

1 大key问题的危害

1.1 性能下降

操作大key可能会导致Redis的命令执行时间显著增加，影响整体性能。

2.2 占用大量内存

大key会占用大量内存，这可能导致Redis实例内存不足，从而影响其他键的存储。

前言

有些小伙伴在工作中，可能遇到过这样的场景：老板突然要求统计Redis中所有key的数量，你随手执行了KEYS *命令，下一秒监控告警疯狂闪烁——整个Redis集群彻底卡死，线上服务大面积瘫痪。

今天这篇文章就跟大家一起聊聊如果给你1亿个Redis key，如何高效统计这个话题，希望对你会有所帮助。

1 为什么不建议使用KEYS命令？

Redis的单线程模型是其高性能的核心，但也是最大的软肋。

当Redis执行 KEYS * 命令时，内部的流程如下：