做后端开发的大概没有几个人不知道Redis这个单词。我面试过不少人简历上写着“熟练使用Redis做缓存”但真问下去往往就卡在“Redis到底快在哪里”“为什么用Redis不用HashMap”“如果Redis挂了怎么办”这类问题上。作为《Redis系列》的第一篇我想先带你把地基打扎实Redis是什么、能做什么、怎么安装、有哪些数据类型以及学习路线应该怎么规划。这篇文章不追求几句命令让你“看起来会了”而是尽量把原理和场景讲透让你确实搞懂核心概念后面再深入时就不会一头雾水。我也提前说明一下这个系列会按“初识 - 命令 – 持久化与高可用 - 缓存治理与实战”的路子往下走。如果你是刚接触Redis的初学者或者用了一段时间但总感觉哪里没想明白这篇文章就是给你准备的。1. Redis到底是什么先建立正确的底层认知1.1 一句话定位它是跑在内存里的远程字典服务Redis全称叫Remote Dictionary Server直译过来是“远程字典服务器”。这个词其实已经把它的本质说清楚了一个部署在服务器上的、通过网络访问的“字典”。什么是字典就是键值对Key-Value集合。你在程序里写的HashMap、Dictionary本质上也是键值对存储Redis干的就是这件事只是它把数据放到了一台独立服务器上让多个应用可以共同访问同一份数据。用个更生活化的比喻Redis就像一个开在商场里的共享储物柜。你把东西value放进标了号码key的柜子锁好后自己保管钥匙。以后想取想存拿着号码开柜子就行。和本地HashMap最大的区别是这个储物柜是所有应用共享的你的Java服务、Python服务、前端网关只要配置对了都能访问同一个key。这才是缓存、分布式锁、Session共享等技术能成立的前提数据不在某个进程里而在一个独立的公共位置。所以你可以把它理解成一个跑在内存里、支持网络访问、数据格式远比普通字典丰富的共享字典服务。它既是缓存也能当数据库用还能兼职消息队列。这就是为什么大家都说Redis是后端技能树的必修课。1.2 为什么Redis快内存、单线程与精心设计的数据结构很多人第一次接触Redis第一个问题就是“它为什么会这么快”。官方给出的数据是单节点QPS可以突破10万比传统数据库高几个数量级。快的原因归纳起来有三层。第一数据都在内存里。内存的随机访问延迟是纳秒级别而磁盘的随机访问延迟是毫秒级别这两者之间差了好几个数量级。当然市面上不是只有Redis一个内存数据库但Redis把“内存存储”这件事做到了极致简洁。第二命令执行是单线程模型。你可能会觉得“并发才快单线程不慢吗”恰恰相反单线程省掉了多线程中的上下文切换、锁竞争、CPU调度这些开销。Redis的核心操作都是纯内存计算CPU根本来不及成为瓶颈网络IO才是大头。所以单线程反而让系统更简单、更高效。Redis在6.0之后引入了多线程IO来提升网络吞吐但命令本身的执行仍然是单线程这是为了保持操作的原子性和实现上的简单可靠。第三底层数据结构不是一把梭。Redis为不同类型设计了专用结构比如SDS动态字符串、跳表、压缩列表、quicklist等等每个结构都针对典型场景做了内存和性能上的优化。这不是用通用方案硬扛而是“因材施教”。1.3 初识阶段必须记住的6个特性既然要系统学先把特性清单列出来。初识阶段你只需要记住下面这几条后面的文章会逐条展开。纯内存存储读写性能极高单节点十万级QPS。支持丰富的数据类型不止是String还有List、Hash、Set、ZSet等。支持为每个key单独设置过期时间天然契合缓存场景。支持持久化RDB快照和AOF日志重启后数据不会全部丢失。支持主从复制、哨兵和集群部署可以搭建高可用的生产架构。提供事务、Lua脚本、发布订阅、管道等高级特性能做很多中间件能做的事。把这6条记在脑子里你已经比很多人对Redis的理解深入一层了。紧接着的问题就是怎么把它跑起来下面讲安装这部分我尽量把不同系统下的坑都给你点出来。2. 第一台RedisWindows、Linux、Mac和Docker怎么选2.1 Windows安装5.0.14.1与开机启动先说一个很多人不知道的冷知识Redis官方并不提供Windows原生版本因为它的核心实现依赖fork这类在Linux下表现更好的系统调用。你在Windows上能装到的基本都是微软维护的旧版本或者民间移植版目前社区里流传最广的就是5.0.14.1这个版本。日常学习和本地开发够用了但生产环境不要用Windows版这是底线。下载解压之后目录结构大概是这样的redis-server.exe是服务端redis-cli.exe是客户端redis.windows.conf是配置文件。启动服务先在目录下开一个命令行窗口执行redis-server.exe如果看到监听6379端口的日志输出就说明已经起来了。再开一个窗口验证一下redis-cli.exe -h 127.0.0.1 -p 6379 ping返回PONG说明状态正常。这里有个小坑Windows下的解压路径不要带中文和空格否则可能出现各种奇怪的路径读取问题。另外如果你安装的版本带了配置文件建议启动时显式指定它redis-server.exe redis.windows.conf这样配置文件里的参数才会生效比如设置密码、修改端口、开启AOF持久化等等。想把它注册成Windows服务实现开机自启也比较简单redis-server.exe --service-install redis.windows.conf --loglevel verbose redis-server.exe --service-start以后服务就在Windows服务列表里了不用每次手动开窗口。需要卸载时执行redis-server.exe --service-uninstall2.2 Linux下源码编译安装Redis生产环境的Redis基本都是跑在Linux上的所以Linux下的安装你一定得会。最快的方式是用包管理器# Ubuntu/Debian sudo apt install redis-server # CentOS/RHEL sudo yum install redis包管理器安装的好处是省心坏处是版本往往偏旧——我见过不少CentOS自带源里还是4.x、5.x的版本一些新特性用不上。想要官方最新稳定版走一遍源码编译流程更靠谱整个过程也不复杂wget https://download.redis.io/releases/redis-7.2.4.tar.gz tar xzf redis-7.2.4.tar.gz cd redis-7.2.4 make make install编译前确保环境里有gcc编译器和相关依赖CentOS下可以提前执行sudo yum install gcc make。如果make过程报内存分配相关的错可以带上make MALLOClibc这能绕开jemalloc在某些服务器环境下的兼容问题。编译安装完成后redis-server和redis-cli默认装到了/usr/local/bin任何目录下都能直接执行。接着把配置文件放到规范的位置方便后续管理mkdir -p /etc/redis /var/lib/redis /var/log/redis cp redis.conf /etc/redis/然后编辑配置文件按生产需要调整几个关键项daemonize yes让Redis在后台运行requirepass设置访问密码appendonly yes开启AOF持久化logfile /var/log/redis/redis.log指定日志路径。启动时用/usr/local/bin/redis-server /etc/redis/redis.conf这套流程走一遍你对“编译、安装、配置、启动”这个链路就有了整体概念后面在云服务器上部署也会很顺手。2.3 Mac用户最省事的安装方式Mac下装RedisHomebrew是唯一推荐的方式brew install redis redis-server /opt/homebrew/etc/redis.conf如果是Apple Silicon芯片路径一般是/opt/homebrew/etc/redis.confIntel芯片则是/usr/local/etc/redis.conf。安装完默认不会后台运行想开机自启就用brew services start redis用brew services管理的好处是日志和进程都交给系统统一管重启电脑也不用手动启动排查问题时直接看日志就行。2.4 Docker一条命令完成安装与主从现在我个人带新人最推荐的学习方式其实是Docker。一条命令就能把Redis跑起来环境干净坏了就删掉重建根本不需要跟本机依赖作斗争docker run -d --name redis -p 6379:6379 redis:7.0-d表示后台运行--name redis给容器命名-p 6379:6379把容器内的6379端口映射到宿主机。启动后验证docker exec -it redis redis-cli ping如果想要带密码启动在镜像后面直接追加参数docker run -d --name redis -p 6379:6379 redis:7.0 --requirepass 123456后面学主从复制时Docker的优势更明显。比如先启动一个主节点再启动一个从节点通过--link或者自定义网络就能在几秒钟内组成一主一从docker run -d --name redis-slave -p 6378:6379 redis:7.0 --replicaof redis-master 6379这比你在一台机器上装两个Redis实例省太多事了。所以我常跟新人说学习Redis的第一步不是背命令是先把环境问题解决掉。环境越简单你越能专注于Redis本身。3. 五种数据类型把String、List、Hash、Set、ZSet一次讲透Redis解决业务问题的核心武器就是它丰富的数据类型。下面逐个讲清楚它们的底层逻辑和适用场景。注意这里我讲的是设计思路具体的命令实操放到后面专门章节这样知识结构更清晰。3.1 String不只是存字符串它还是计数器String是Redis最基础的类型value最大能存512MB。你平时用的SET key value、GET key就属于这类。但它远不止“存字符串”这么简单——它还提供了原子自增命令用来做计数器非常顺手。比如写文章网站的阅读量统计典型操作是INCR article:read:1001 INCRBY article:read:1001 10这两个命令是原子操作高并发下不会丢更新这比“先GET再SET”的写法安全得多。网上经常有人问“Redis的incr不准”其实INCR本身不会不准真正不准的情况往往是你用了GET拿到值在程序里加1再SET回去这个“读改写”三步操作在并发下会互相覆盖或者多个应用实例同时写同一个计数器但没做同步。解决方式很简单计数类的操作永远走Redis的原子命令不要绕开它。String的典型场景包括缓存序列化后的对象、计数器、分布式ID生成、Session共享等。3.2 List栈、队列、消息流都能做List在底层是一个双向链表结构头部和尾部操作都是O(1)级别。你可以用LPUSH往左塞RPUSH往右塞再配合LPOP、RPOP弹出数据于是栈、队列、消息流它都能做。一个很常见的用法是做轻量级消息队列。生产者只需要LPUSH task:queue task-1消费者用阻塞式的BRPOP取消息没有数据时客户端会阻塞等待不会空转消耗CPUBRPOP task:queue 0这里的0表示永不超时。拿List做队列有个前提你要能接受消息可能丢失的缺陷。因为List本身没有消费者确认机制消费者取走消息之后进程崩了这条消息就再也找不回来了。如果想要更可靠的消息队列还是要去用专业中间件比如RabbitMQ、RocketMQ这些。List还适合做“最新N条”这类业务比如用户下拉刷新要看到最新5条公告用LRANGE list 0 4就能直接取到。为什么List合适因为新数据都是往队头或队尾插入的天然有时间顺序。3.3 Hash一个key能存多个字段天然适合对象Hash类型在Redis内部是一个字段到值的映射表相当于“key里套了一个小字典”。看命令就明白了HSET user:1001 name 张三 age 25 city 深圳 HGET user:1001 name HGETALL user:1001和String存一个JSON字符串相比Hash的优势是你可以只修改其中一个字段不需要整个对象读出来反序列化再写回去。比如修改年龄一条HSET就搞定。另外Hash还能对单个字段做原子自增HINCRBY user:1001 age 1业务对象信息、购物车、配置项这类“一个实体多个属性”的数据用Hash非常合适。3.4 Set去重、抽奖、好友关系就靠它Set是一个无序的字符串集合元素不能重复。它天然就适合去重场景用户访问的IP、参与活动抽奖的用户ID、文章的标签都可以往Set里塞。常用命令也很直观SADD tag:article:1001 Redis 后端 教程 SISMEMBER tag:article:1001 Redis SCARD tag:article:1001SISMEMBER判断元素是否存在是O(1)级别的适合做“某用户是否已经参与过活动”这类校验。更强大的是集合运算能力取两个Set的交集、并集、差集。比如求两个用户的好友共同关注一行SINTER user:1:follow user:2:follow就出结果了。不用在程序里拉全量数据再过滤在Redis内部就完成了。3.5 ZSet排行榜这类“带权排序”的首选ZSet又叫有序集合它在Set的基础上给每个元素关联了一个分数score。分数允许重复但元素本身不重复。Redis内部用跳跃表加哈希表实现了这个结构既能通过元素快速查询分数又能按分数范围高效遍历。排行榜业务是ZSet的经典应用。以游戏战力排行榜为例ZADD leaderboard 100 player:1 ZADD leaderboard 98 player:2 ZREVRANGE leaderboard 0 2 WITHSCORESZREVRANGE按分数从高到低取出前三名。玩家战力发生变化时用ZINCRBY leaderboard 5 player:1直接改分数排行榜顺序自动维护完全不需要你重排。ZSet还有很多其他玩法比如把score当成时间戳就能实现延迟队列。3.6 类型选型速查表初学时最容易纠结的就是“这个业务到底该用哪个类型”。我整理一张速查表建议直接收藏类型底层结构典型场景核心命令时效性StringSDS动态字符串缓存、计数器、SessionSET、GET、INCR永久可用List双向链表/quicklist消息队列、最新列表LPUSH、BRPOP、LRANGE数据多时注意内存Hashlistpack/hashtable对象存储、购物车HSET、HGET、HINCRBY字段少省内存Setintset/hashtable去重、抽奖、标签SADD、SISMEMBER、SINTER集合运算灵活ZSet跳表哈希表排行榜、延迟队列ZADD、ZINCRBY、ZREVRANGE排序需求强烈推荐选型的大原则很简单有排序用ZSet要去重用Set对象属性频繁改动用Hash消息流用List纯缓存和计数器用String。把这个原则记牢大部分场景都不会选错。4. 客户端工具选型命令行永远是底线GUI只是锦上添花4.1 redis-cli学会它你将无所畏惧不管你装了哪个版本的Redisredis-cli一定是自带的核心客户端。它支持连接远程服务redis-cli -h 192.168.1.10 -p 6379 -a 你的密码里面的-a指定密码但要注意这会暴露在命令行历史里生产环境建议用REDISCLI_AUTH环境变量传密码更稳妥。还有一个很实用的小细节默认情况下redis-cli在中文Windows控制台里输出中文可能乱码加--raw参数可以以原始格式输出。需要了解Redis运行状态时INFO命令能输出一大票指标比如内存占用、客户端连接数、命中率排查线上连接问题用CLIENT LISTMONITOR可以实时看所有请求但生产环境慎用它会拖低性能。连接不上时最常见的原因有几个Redis没启动、端口没放通、配置文件里bind限制了访问、设置了密码但没带-a。排查顺序就按这个来。4.2 Redis Desktop Manager与Another Redis Desktop Manager图形化客户端这块老牌选手是Redis Desktop Manager社区习惯简称RDM。它经历了开源和商业化几次变动早期版本大家用得比较多后来不少人转向了开源的Another Redis Desktop Manager界面更现代支持Windows、Mac、Linux全平台连接配置、key浏览、类型查看、命令执行都做得很成熟。这些GUI工具核心能干什么一是连接管理你可以把开发、测试、生产环境的不同Redis实例按环境分组保存二是可视化浏览key按前缀过滤查看每个key的类型和值三是执行命令的窗口四是一些简单的分析工具比如查看key数量、内存占用。对日常开发来说这些功能已经足够。但我要提醒一句GUI工具只是辅助不要完全依赖它。原因有二一是生产环境出于安全考虑往往禁止GUI直连你最终还是要靠命令行二是GUI的自动刷新、格式化显示会掩盖一些细节比如某个key的TTL到底还剩多少不如命令输出直观。所以我建议新人的工具学习顺序是先把redis-cli用熟再配一个GUI当可视化辅助。4.3 我给新人的工具选型建议总结一下我的推荐方案本地学习Windows或Mac上用Redis Desktop Manager这类GUI直观理解数据和类型。日常开发调试优先redis-cli写脚本或者快速验证时效率极高。线上环境只用命令行配合监控平台查看指标。工具本质上只是“看数据”的手段真正值钱的是你脑子里的模型比如决定用ZSet而不是List、用Hash而不是String。这些判断能力GUI给你提供不了。5. 高频命令实操用4个典型业务把常用命令串一遍这一章换一种学法不按命令分类背而是模拟真实业务场景把高频命令都用上。你跟着敲一遍比死记命令列表强得多。5.1 业务一缓存用户信息用户登录后通常要把用户信息缓存起来避免每次请求都查数据库。最简单的方式是用String把用户对象序列化成JSON再存SET user:info:1001 {name:张三,age:25,city:深圳}取的时候直接GET user:info:1001在服务端反序列化回对象。这种方式写起来简单适合“整体读取、整体覆盖”的场景。但如果某个字段经常变动比如用户的积分、等级用Hash更好HSET user:info:1001 name 张三 age 25 city 深圳 points 100 HINCRBY user:info:1001 points 10一条命令只更新一个字段不用重新序列化整个对象性能和代码复杂度都会更优。这里给你一个经验法则整体缓存用String局部更新用Hash。5.2 业务二排行榜排行榜是ZSet的舞台。以新人积分榜为例ZADD rank:newbee 200 user:1 ZADD rank:newbee 150 user:2 ZADD rank:newbee 188 user:3查看前三名ZREVRANGE rank:newbee 0 2 WITHSCORES给某个人加10分ZINCRBY rank:newbee 10 user:1查看某个人的当前排名ZRANK rank:newbee user:1一套操作下来你会发现“排序”这件事Redis全给你代劳了。换成用MySQL实现每次查询都要走一次ORDER BY还要处理索引性能和代码复杂度都不可同日而语。5.3 业务三IP去重与集合运算假设要统计某天的独立访客IPSet是天然适合的类型SADD ip:2025-01-01 10.0.0.1 SADD ip:2025-01-01 10.0.0.2 SADD ip:2025-01-02 10.0.0.2看一眼当天独立IP数SCARD ip:2025-01-01判断某个IP是否访问过SISMEMBER ip:2025-01-01 10.0.0.1如果还要分析“元旦和第二天都访问过的人”一个交集命令就搞定SINTER ip:2025-01-01 ip:2025-01-02再看“1月1日访问过但1月2日没访问的人”SDIFF ip:2025-01-01 ip:2025-01-02这类集合运算在用户标签、好友关系、权限控制里用得极多建议动手敲一遍。5.4 业务四轻量级消息队列用List做简单任务队列生产者往左边塞LPUSH task:queue task-1 LPUSH task:queue task-2消费者阻塞取BRPOP task:queue 0BRPOP会一直阻塞到队列里有数据才返回这样消费者就避免了一个空的while true循环在那里疯狂自旋。你也可以指定超时时间比如BRPOP task:queue 3等3秒没数据就返回null方便做心跳检测。这套轻量队列适合异步发短信、发邮件、下游系统解耦这类对可靠性要求不高的场景。如果要严格不丢消息请换专业消息队列。5.5 通用操作过期时间、TTL与key管理Redis所有类型的key都支持设置过期时间这也是它作为缓存最重要的一块拼图EXPIRE user:info:1001 3600 # 一小时后过期 TTL user:info:1001 // 查看剩余存活时间-1表示永不过期-2表示key不存在清除过期时间让key永存PERSIST user:info:1001删除key和类型检查DEL user:info:1001 EXISTS user:info:1001 TYPE user:info:1001还有一个必须强调的坑生产环境禁止用KEYS命令。KEYS *会把所有key拉一遍数据量大时直接卡死Redis。线上环境需要用SCAN命令进行增量遍历SCAN 0 MATCH user:* COUNT 100它每次返回一批key还带一个游标循环遍历直到游标归0。这是安全和性能之间的平衡虽然稍微啰嗦一点但绝不会拖垮Redis这也是“初识”阶段就有必要知道的红线。6. 进阶概念扫盲知道这些名词面试不露怯6.1 持久化RDB与AOFRedis是内存数据库没有持久化的话服务器一重启数据就全没了。官方提供了两条持久化路线RDB快照和AOF日志。RDB的思路是定时把当前内存里的全量数据生成一个二进制快照文件dump.rdb。它恢复速度快、文件紧凑适合做备份和灾难恢复。缺点是快照之间这段时间的数据会丢。AOF的思路则是把每一条写命令追加到日志文件里恢复时重放日志就行。AOF能实现更细粒度的持久化你可以配置always每次写都刷盘或者everysec每秒刷一次数据安全性更高但文件体积更大恢复速度也相对慢。Redis 4.0之后还提供了混合持久化RDB快照加AOF增量日志兼顾了重启速度和数据完整性。初识阶段你只需要记住一句话RDB管快照AOF管日志两者可以共存重启时优先加载AOF来恢复数据。至于具体配置和踩坑后面的专项文章会展开。6.2 缓存穿透、缓存击穿与缓存雪崩这三个名词是Redis在高并发场景下绕不开的问题也是面试高频题。我用自己的理解给你讲明白。缓存穿透查询一个根本不存在的key缓存里没有数据库里也没有每次请求都会一路打到数据库。如果这个key被恶意刷数据库压力直接爆炸。解决方案有两个方向一是布隆过滤器提前把所有可能存在的数据放到过滤器里查不到就直接拦截二是把“空结果”也缓存起来给个很短的过期时间比如5分钟避免相同查询重复打库。缓存击穿一个热点key正好在某个瞬间过期与此同时大量请求打过来全部穿透到数据库。解决思路是加互斥锁让第一个请求去数据库加载并重建缓存其他请求等一会儿再重试或者用“逻辑过期”方案给缓存值里塞一个过期时间戳发现逻辑过期了再回源更新返回旧值先顶住。缓存雪崩大量key在同一段时间集中过期导致一波请求全部穿透到数据库。解决方法是给过期时间加随机抖动比如基准时间加0到5分钟的随机值让过期时间分散开同时可以做多级缓存分摊压力。这三个问题你需要能用自己的话说清楚并且说出至少一种应对方案。到了后续的《缓存治理》篇我会再给完整的落地方案。6.3 主从复制、哨兵与集群的区别很多人把这几个概念混在一起我直接给一张对比表看完就清楚了维度主从复制哨兵模式集群模式核心能力数据备份、读写分离在主从基础上自动故障转移数据分片存储、水平扩展部署结构一个主节点多个从节点主从加哨兵进程多个主节点每个主节点可带从节点故障处理需要人工干预哨兵自动提升从节点为主哈希槽迁移自动容错数据分片无无有16384个哈希槽适用场景中小规模起步对可用性要求高的单分片大数据量、高并发场景主从复制解决的问题是“一台Redis挂了数据就没了”的恐惧从节点持有完整副本可以承接读流量。但主节点故障时从节点不会自动上位所以有人设计了哨兵专门盯着主从的状态发现主节点挂了就自动把一个从节点提升为主节点应用通过哨兵感知新地址。当数据量大到单节点内存装不下时就要上集群数据按key算哈希槽分散到多个主节点上每个主节点再配从节点保证高可用。这个演进过程就是Redis从“单机”走向“分布式”的完整路径。6.4 分布式锁从SETNX到Redisson分布式锁是Redis在微服务架构里最重要的应用之一。核心需求是多个服务实例同时操作同一个资源时只能有一个实例获得执行权。Redis实现分布式锁的基石是SET命令带上NX和EX参数SET lock:order 9529 NX EX 30NX表示“只有当key不存在时才设置成功”谁设置成功了谁就拿到了锁EX 30表示这把锁30秒后自动过期防止持有锁的实例挂了导致死锁。释放锁时要注意不能简单地DEL因为你可能把别人刚获取到的锁误删了。正确做法是用Lua脚本先校验锁的value是不是自己设置的再决定是否删除if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end这个“先比较再删除”的过程必须原子执行Lua脚本正好保证原子性。实际生产项目里更推荐直接用Redisson这个客户端库它把锁续期、自动重试这些细节都封装好了。初识阶段你只需要理解原理动手造一把简单的分布式锁能帮自己把分布式场景的思维建立起来。6.5 给新手的学习路线建议基于我自己的经验和带人经历Redis的学习大致可以分三个阶段。第一个阶段就是把这篇内容吃透理解定位、会安装、熟练操作五种数据类型、能用redis-cli完成常规排查。第二个阶段是进阶核心机制持久化、过期删除策略、内存淘汰策略、主从与哨兵或集群的搭建和验证。第三个阶段是工程实战缓存穿透击穿雪崩的治理、分布式锁的落地、Spring Boot整合Redis时的序列化问题、链路追踪与监控告警。这里特别提一下Spring Boot整合Redis时最容易踩的坑序列化器不一致。很多人项目里用默认的JdkSerializationRedisSerializer往Redis写数据时是二进制用客户端工具查看全是一堆乱码。正确做法是使用StringRedisTemplate或者给RedisTemplate指定GenericJackson2JsonRedisSerializer作为value序列化器。还有人在用Spring Cache Redis时出现“缓存key变化导致命中不了”的情况多半也是序列化策略没统一。这个话题展开讲能写一整篇我先在这里埋个引子后续系列文章会专门处理。说点我的经验体会最后聊一点个人带新人时的观察。很多初学者在Redis上栽跟头根本不是不会用命令而是不知道“该把什么数据放Redis、用什么类型放、能接受多少数据不一致”。我面试时常问一个很基础的问题你项目里Redis存了什么很多人回答“用户信息、验证码”行那追问一句“用户信息的修改频率高吗缓存和数据库不一致能接受几秒”就卡壳了。Redis本身不复杂复杂的是业务判断。你越是能想清楚一个数据该不该进内存、该用什么结构组织、过期时间给多久、挂了之后业务怎么办你就越接近一个真正有经验的后端开发者。这篇“初识Redis”先把地基给出后面我们接着往里盖楼。