作为程序员，那就离不开Redis，谁让不争气的磁盘还是那么慢呢？要过了面试这道坎，Redis必须掌握好。除了会用，还得了解它背后的原理。

为啥？因为大家现在都在养蛊。人生在世，诸多无奈。逆水行舟，不进则退。

如果你读过Redis相关的书籍，本文就帮你快速的撸一遍。没读过也不要紧，缺啥补啥。

redis能力：

1 0W/s QPS （redis-benchmark）
1w+ 长链接（netstat / ss）
最复杂的Zset 6kw数据写入1k/s 读取5k/s 平均耗时5ms
持久化 (rdb)

1. 基本概览

学习一门新语言，重要的是掌握它的基本数据结构，以及这些数据结构的API。redis的这些数据结构，就类似一门语言。

Redis数据结构

常用5种，一共10种。面试时一般回答5种即可，但其他5种是加分项。

String 字符串
Hash 字典
List 列表
Set 集合
ZSet 有序集合。

性能参考：

我来分享一点遇到过的线上数据，或许对你的决策有帮助。

redis支持一个数据结构，叫做 zset，也就是有序的列表。当然redis也不能滥用

忘了zset是个啥的同学可以看这张gif图。

通过它，可以实现游戏排行榜一类的功能，或者实现Topx这样的需求，也能精准的让用户在海量数据中找到自己的位置。

zset的底层结构是跳跃表，而与之类似的Java中的有序Set是TreeSet，使用红黑树实现的。

concurrent包里面，还有一个类叫做ConcurrentSkipListMap，从它的名字就可以看出来，也是用跳跃表实现的，这个和zset最像。

好了，这是前提。广度面试的时候我也会这么问。

我们的问题是：zset中能存放多少条记录？线上有没有有说服力的数据？

先笼统的回答一下，zset理论上支持的元素最多是2^32-1个，约42亿，如果你的内存够大，放下国人绰绰有余。

使用redis-benchmark去测这个效果，不是很可信，测试用例写起来也比较费劲。测完了也不一定信，那就让线上流量去冲击吧。

为了应付产品的需求，我把用户按照省市进行了划分（geohash），结果，用户分布最大的就是广东省，非常棒。

在广东省的zset里，存放了接近6千万的数据，我们就要算在这6千万内任何人的排行。zcard、zrank等一系列操作，easy实现。

运行一段时间后，内存直接飙升到了8G左右。这是由于跳表的特殊结构所引起的，额外的辅助信息会占用更多的内存。

以下是经验值：

最高TPS写入量1k/秒。
同时最高QPS查询量5k/秒。
平均耗时5ms左右。
百分之95的请求都在10ms以内返回。
长尾请求超过100ms的不超过100条。

也就是说，在保持高写入和高查询的同时，zset能够保证较低的响应耗时。

你要说再多，我就不知道了，看这些数据，或许还能够再升一把。但要让服务要尽量的稳，压力尽量的分散，就不能太过苛刻，对这个数据我已经很满意了。

这只是一个省份的数据。如果综合起来，上层的业务，就需要承载10w/s的请求。这是非常容易的，但也没有意义，许多高并发经验都是这么吹上去的，要不要去改改简历？

复杂业务高并发才有价值，10w/s请求，给我两台redis就够了，没必要拿来吹。

但也是被zset的性能震惊了一把。跳表的结构，也了解一些，没想到在高并发大数据量场景下，能这么快。

测试数据？没有。这里只是分享一个经验值。对了，redis几乎不占用CPU，你只需要一台2core16gb的服务器就可以了。

Pubsub 发布订阅（不推荐使用，坑很多）
Bitmap 位图
GEO 地理位置（有限使用，附近的人）
Stream 流(5.0) （与Kafka非常像）
Hyperloglog 基数统计

Redis的协议

Redis是文本协议

RESP 以CRLF结尾(\r\n)
RESP3 （redis6启用，增加客户端缓存）

Redis底层数据结构

数据量较小和大数据量的时候，往往不同，关注大数据量的主要结构。

String-sds
Hash-(ziplist , dict)
Set-(intset,dict)
List-(ziplist,quicklist)
ZSet-(ziplist+skiptable 跳表)
Stream-(radix-tree 基数数)

跳表的关注度比较大，在Java中，可以参考类似ConcurrentSkipListMap实现。

另：Java中有序Set叫做TreeSet，但是用红黑树实现的，注意区别。

Redis持久化方式

生产环境，一般仅采用RDB模式。

RDB
AOF （类似Binglog row模式）
混合模式：RDB+AOF

O(n)指令

keys *
hgetall
smembers
sunion
...

建议在集合大小不确定的时候，使用scan hscan sscan zscan 替代。另外，像keys这种危险命令，最好使用RENAME指令给屏蔽掉。

性能优化

unlink删除key -> 异步避免阻塞
pipeline批量传输，减少网络RTT ->减少频繁网络交互
多值指令（mset，hmset）-> 减少频繁网络交互
关掉aof -> 避免io_wait

扩展方式

lua
redis-module

module模式知道的人比较少，属于比较底层的开发。

2. 问题排查

monitor指令回显所有执行的指令。可以使用grep配合过滤
keyspace-events 订阅某些Key的事件。比如，删除某条数据的事件，底层实现基于pubsub
slow log 顾名思义，满查询，非常有用
--bigkeys启动参数 Redis大Key健康检查。使用的是scan的方式执行，不用担心阻塞
memory usage key、memory stats 指令
info指令，关注instantaneous_ops_per_sec、used_memory_human、connected_clients
redis-rdb-tools rdb线下分析

3. 淘汰策略

如果你应聘的是redis dba，这道题答不出来，直接淘汰。

被动删除 (只有被get到的时候，删除并返回NIL 属于惰性删除）
主动删除 (100ms运行一次，随机删除持续25ms，类似Cron）
->内存使用超过maxmemory，触发主动清理策略

针对于第三种情况，有8种策略。注意，redis已经有LFU了。

默认volatile-lru 从设置过期数据集里查找最近最少使用
volatile-ttl 从设置过期的数据集里面优先删除剩余时间短的Key
volatile-random 从设置过期的数据集里面任意选择数据淘汰
volatile-lfu 从过期的数据集里删除最近不常使用的数据淘汰
allkeys-lru
allkeys-lfu
allkeys-random 数据被使用频次最少的,优先被淘汰
no-enviction

如果不设置maxmemory,Redis将一直使用内存，直到触发操作系统的OOM-KILLER。

4. 集群模式

单机
单机多实例
主从（1+n）
主从（1+n）& 哨兵（3或者基数个）
Redis Cluster （推荐，但使用有限制）。

互联网建议使用Redis Cluster，外包、项目随意。

具体搭建过程，请参考：

redis速度快，可靠性高，是互联网公司的标配。它有单机、主从、哨兵、Cluster等四种部署模式。

下面，仅从部署模式上，来说明一下它们的优缺点。

单机模式

单机模式的redis非常简单，你只需要启动一个单一的节点就可以了，安装过程不超过5分钟。

通过redis-benchmark测试简单的命令，QPS可达到10w以上，不得不说非常的让人惊艳了。

单机模式的问题也非常明显。缺乏高可用的机制！

假如redis进程死了，进程就只能够穿透到底层的数据库中，对业务来说非常的危险。如果你把redis当作数据存储来用，情况会更加严重，甚至会丢失数据。

主从模式

所以最基本的redis部署，都会增加一个或者多个slave（现在叫replication）。

当主redis发生问题的时候，能够选取一个slave顶上去。

非常可惜的是，这种模式和传统的MySQL主从一样，切换起来比较蛋疼，需要借助外部的工具，比如keepalived等辅助进行切换，部署和维护难度直接飙升。

keepalived是一个基于VRRP协议来实现的高可用方案，通过IP漂移实现高可用。从描述上就可以看出它需要网络管理员的参与，和我们轻量级的redis背道而驰。

哨兵模式

哨兵模式就是使用额外的进程来替换keepalived的功能，对redis进程的存活性进行判断。在哨兵模式下，一旦主节点宕机，从节点作为主节点的备份可以随时顶上来。

但哨兵模式一个最大的问题，就是哨兵的数量太多，至少需要3个节点。

对redis进行仲裁的时候，需要n/2+1个节点投票才能确认，这也是分布式系统的一般做法 (quorum)。和Zookeeper类似，哨兵节点做成奇数个，是非常合适的。

哨兵模式可以通过sentinel monitor配置同时检测多套集群，在集群数量适中的时候，还是比较好用的。

但哨兵模式有很多隐藏的坑，比如哨兵的启动，必须在master存活的情况下才能正常运行；另外，如果你的redis配置文件中使用RENAME屏蔽了一些危险命令时，哨兵也不能够启动。

客户端在连接redis的时候，就不能再直接连接redis的实例，它需要从哨兵转上一圈，以便获取一些变更信息。

集群模式

集群模式可以说是这里面最优雅的方式了。你只需要部署多个对等的redis节点，然后使用客户端命令进行组群就可以了。

ip=192.169.0.23./bin/redis-cli --cluster create  $ip:7001 $ip:7002 $ip:7003 $ip:7004 $ip:7005 $ip:7006 --cluster-replicas 1

它对节点的要求也是比较多的，一般是采用6个节点，三主三从。当节点超过10个，它的协调性就不那么灵活了，所以单集群的存储和性能上限也很快能到达。

集群模式的一些缺点很隐蔽。它的服务端节点倒是非常稳定了，但有些命令会严重影响性能。比如mget,pipeline等。它们需要把请求分散到多个节点执行、再聚合。节点越多，性能越低。

其他方案

可以看到redis的这些集群模式，都不是完美的。应对小型的服务可能没有问题，如果是大型的集群和服务，这些部署方式对运维上，使用上来说，都有非常大的挑战。

使用客户端hash的方法，是大型互联网中常用的方式。现实中的路由规则，可能会相当复杂，但请求总能够精确的落在某个小的群组上面。

对于管理大型集群来说，我倒是倾向于主从模式，然后使用Java或者其他语言开发一个可以集中管控的哨兵系统，对上千个集群进行管理。

由于Redis是文本协议，协议非常简单，Netty甚至直接内置了它的解析器，所以开发这么一个哨兵系统是非常简单的。

一些中间层代理软件，也能分担一些路由工作，但由于是中间层，涉及到一层网络转发，对Redis这种以速度取胜的服务来说，就不是很实用。

变种有更多，比如下面这篇文章，使用的是Redis协议，但后端存储却是MySQL，所以你的命令会是被阉割的。

Redis能用是一回事，用好是另一回事。

你可能花了一天时间搭建了一个单节点的Redis；我可能花了一周时间写了个Java版的哨兵，还有很多BUG。这两者在不懂技术的领导眼里，是没有区别的--它们都满足了业务的需求。但也不必过分计较，现实一般都比较残酷，计算机系统也没有想象中的那么稳定，墨菲定律总有一个时间会教会他们做人。

当然，领导每天都在教我做人。

大规模

twemproxy
codis
基于Netty Redis协议自研
管理平台：CacheCloud

5. Redis常见问题

Redis使用场景

缓存（缓存一致性缓存穿透缓存击穿缓存雪崩）
分布式锁（redlock）
分布式限流
Session

API举例：

zset 排行榜，排序
bitmap 用户签到，在线状态
geo 地理位置，附近的人
stream 类似kafka的消息流
hyperloglog 每日访问ip数统计

缓存一致性

为什么有一致性问题?

写入。缓存和数据库是两个不同的组件，只要涉及到双写，就存在只有一个写成功的可能性，造成数据不一致。
更新。更新的情况类似，需要更新两个不同的组件。
读取。读取要保证从缓存中读到的信息是最新的，是和数据库中的是一致的。
删除。当删除数据库记录的时候，如何把缓存中的数据也删掉？

建议使用：Cache Aside Pattern

读请求：

先读cache，再读db

变更操作：

先操作数据库，再淘汰缓存

涉及到复杂的事务和回滚操作，可以把淘汰放在finally里。

问题：缓存淘汰失败！（概率很低，定时补偿）

缓存击穿

影响，轻微。

高流量下大量请求读取一个失效的Key -> Redis Miss -> 穿透到DB

解决方式：采用分布式锁，只有拿到锁的第一个线程去请求数据库，然后插入缓存

缓存穿透

影响，一般。

访问一个不存在的Key（恶意攻击）-> Redis Miss -> 穿透到DB

解决方式：

给相应的Key设置一个Null值，放在缓存中
BloomFilter预先判断

缓存雪崩

影响：严重。

大量Key同时失效｜ 2.Redis当机 -> Redis Miss -> 压力打到DB

解决方式：

给失效时间加上相对的随机数
保证Redis的高可用

分布式锁

redis的分布式锁，并不是那么简单。建议使用redisson的redlock。最基础的指令是setnx。

setnx-> SET key value [EX seconds|PX milliseconds|KEEPTTL] [NX|XX] [GET]

分布式锁关键点：

原子性
锁超时
死锁
读写锁
故障转移

最简单的Redis分布式锁代码（不严谨）。

java端代码模拟lock和unlock。

public String lock(String key, int timeOutSecond) {
    for (; ; ) {
        String stamp = String.valueOf(System.nanoTime());
        boolean exist = redisTemplate.opsForValue().setIfAbsent(key, stamp, timeOutSecond, TimeUnit.SECONDS);
        if (exist) {
            return stamp;
        }
    }
}
public void unlock(String key, String stamp) {
    redisTemplate.execute(script, Arrays.asList(key), stamp);
}

lua脚本unlock。

local stamp = ARGV[1]
local key = KEYS[1]
local current = redis.call("GET",key)
if stamp == current then
    redis.call("DEL",key)
    return "OK"
end

6. Redis使用

常用Java客户端

lettuce SpringBoot默认,基于Netty的事件驱动模型
jedis 老牌的客户端，使用commons-pool来完成线程池开发
redisson 非常丰富的分布式数据结构，包括锁，分布式Map等。大量使用Lua脚本️

使用规范

根据公司情况自定义裁剪，没有万能的规范。

使用连接池，不要频繁创建关闭客户端连接
消息大小限制消息体在10kb以下，可以使用snappy、msgpack等压缩
避免大key和hot key
不使用O(n)指令
不使用不带范围的Zrange指令
不使用database（容易覆盖数据）
不使用高级数据结构（使用基本的5种）
不使用事务操作
禁止长时间monitor

springboot cache redis

使用时更要注意规范性
cache层抽象层次太高，如需要操作底层的数据结构，直接使用redisTemplate

Redis是多线程？

要看哪个阶段。数据操作阶段，一直是单线程的，哪怕是redis6。

来来来，快速撸 Redis 一遍！