Redis 学习笔记
原文：硬核！16000 字 Redis 面试知识点总结，建议收藏！
Redis 基础知识
Redis C语言开发的一个开源的高性能键值对（key-value）内存数据库，可以用作数据库、缓存、消息中间件等。
- 性能优秀，直接内存操作，读写速度快，支持10W QPS 并发。
- 单进程、单线程，线程安全，采用IO多路复用，提高吞吐量。
- 丰富的数据类型： String， Hash， List， Set， Sorted Set。
- 支持数据持久化，主从复制，哨兵。
- 分布式锁、消息中间件，支持发布订阅。
Redis 数据类型
| 类型 | 简介 | 特性 | 场景 |
|---|---|---|---|
| String | 二进制安全，Value 可以是String，也可以是 数字。 String 最大能存储 512M。 | 可以包含任何数据，图片或者序列化对象 | -- |
| Hash | 键值对集合， map类型 | 适合存储对象，并且可以更新其中某一项属性 | 存储、读取、修改用户属性 |
| List | 通过双向链表实现，支持push、pop | 增删快，提高操作某一元素的API | 最新消息排行， 消息队列 |
| Set | hash表，元素不重复 | 添加、删除、查找复杂度都是O(1),提供交集、并集、差集操作 | 共同好友，统计访问网址的IP |
| Sorted Set | set中的元素新增一个score参数，有序排列。底层通过HashMap 和 跳跃表skipList实现 | 数据插入时天然排序 | 排行榜，带权重的消息队列 |
Redis 缓存
显示调用：RedisTemplate
默认只支持 RedisTemplate, 需要自定义模板。
redisCacheTemplate.opsForValue().set("userkey", new User(1, "张三", 25));
User user = (User) redisCacheTemplate.opsForValue().get("userkey");
隐式调用： 注解
@EnableCaching、@Cachable 、@CachePut、@CacheEvict
@Service
public class UserServiceImpl implements UserService{
public static Logger logger = LogManager.getLogger(UserServiceImpl.class);
private static Map userMap = new HashMap<>();
static {
userMap.put(1, new User(1, "肖战", 25));
userMap.put(2, new User(2, "王一博", 26));
userMap.put(3, new User(3, "杨紫", 24));
}
@CachePut(value ="user", key = "#user.id")
@Override
public User save(User user) {
userMap.put(user.getId(), user);
logger.info("进入save方法，当前存储对象：{}", user.toString());
return user;
}
@CacheEvict(value="user", key = "#id")
@Override
public void delete(int id) {
userMap.remove(id);
logger.info("进入delete方法，删除成功");
}
@Cacheable(value = "user", key = "#id")
@Override
public User get(Integer id) {
logger.info("进入get方法，当前获取对象：{}", userMap.get(id)==null?null:userMap.get(id).toString());
return userMap.get(id);
}
}
Redis 缓存问题
缓存 & 数据库 一致性问题
如果项目要求强一致性，建议不要使用缓存。
可以采取合适策略来降低数据不一致的概率：先更新数据库，然后及时更新缓存。 缓存失败后增加重试机制。
缓存雪崩
缓存雪崩：缓存同时大面积失效，导致某一时刻所有请求直接到数据库。
解决方案：Key失效时间增加一个随机值。将热点数据均匀分布在不同的Redis库。
缓存穿透
缓存穿透：是指缓存和数据库中都没有的数据，但仍让不断请求该数据。
例如请求 id = -1的数据，而系统的id都是大于0的。
解决方案：用户鉴权，参数检验，非法参数直接return。 布隆过滤器
缓存击穿
缓存击穿：一个Key非常热点，不停的扛着大量的请求。当某个失效的瞬间，大量的请求直接落到了数据库，这时就是缓存击穿了。
解决方案：热点数据设置永不过期，加上互斥锁。
public static String getData(String key) throws InterruptedException {
//从Redis查询数据
String result = getDataByKV(key);
//参数校验
if (StringUtils.isBlank(result)) {
try {
//获得锁
if (reenLock.tryLock()) {
//去数据库查询
result = getDataByDB(key);
//校验
if (StringUtils.isNotBlank(result)) {
//插进缓存
setDataToKV(key, result);
}
} else {
//睡一会再拿
Thread.sleep(100L);
result = getData(key);
}
} finally {
//释放锁
reenLock.unlock();
}
}
return result;
}
Redis 为何那么快
官方数据： 10万+ QPS
Redis 是单进程单线程的模型。
正常项目采用多线程模型的目的是在于提高CPU的利用率。因为Redis完全是基于内存操作，CPU不是瓶颈，其最有可能的瓶颈是机器内存的大小或者网络带宽。
为什么单线程的Redis可以那么快：
- Redis 完全基于内存，绝大部分请求是纯粹的内存操作，非常迅速。并且数据存在内存中类似 HashMap 的结构中， 所有查找和操作的时间复杂度是O(1).
- 数据结构简单，对数据操作也简单。
- 单线程，不需要上下文切换和竞争条件，所以不需要考虑各种锁的问题，不用切换CPU。
- 使用多路复用IO模型，非阻塞IO。
Redis 和 Mencached 区别：
| Redis | Memcached | |
|---|---|---|
| 存储方式 | 主要在内存中，部分在硬盘中，支持数据持久化 | 全部在内存中，数据不能超过内存大小 |
| 数据类型 | 支持5中数据类型 | 只支持简单的key-value |
| 底层模型 | 直接构建VM机制，因为调用系统函数比较耗时 | |
| Value 大小 | 1GB | 1MB |
Redis 淘汰策略
| 策略 | 描述 |
|---|---|
| volatile-lru | 从已设置过期时间的KV集中优先对最近最少使用（less recently used）的数据淘汰 |
| volatile-ttl | 从已设置过期时间的KV集中优先对剩余时间短（time to live）的数据淘汰 |
| volatile-random | 从已设置过期时间的KV集中随机选择数据淘汰 |
| allkeys-lru | 从所有KV集中优先对最近最少使用（less recently used）的数据淘汰 |
| allkeys-random | 从所有KV集中随机选择数据淘汰 |
| noeviction | 不淘汰策略，若超过最大内存，返回错误信息 |
| volatile-lfu | Redis 4.0新增：从已设置过期时间的KV集中优先对访问频率最低使用（least frequency used））的数据淘汰 |
| allkeys-lfu | Redis4.0新增：从所有KV集中优先对访问频率最低（least frequency used）的数据淘汰。 |
Reids 持久化
Redis 为了保证效率，数据缓存在内存中，但是会周期性的把更新的数据写入磁盘，或者把修改的操作写入追加的记录文件中，以保证数据的持久化。
Redis 数据持久化策略有两种：
- RDB：Redis DataBase，快照模式，有个单独的子进程在指定时间间隔内将内存的数据集快照写入磁盘dump.rdb文件。
Redis 默认的持久化方式是快照模式 RDB:
redis.conf
save
# save ""
save 900 1
save 300 10
save 60 10000
官方出厂配置默认是 900秒内有1个更改，300秒内有10个更改以及60秒内有10000个更改，则将内存中的数据快照写入磁盘。
若不想用RDB方案，可以把 save "" 的注释打开，下面三个注释。
- AOF：Append Only FIle，文件追加模式，把所有对Redis服务器进行修改的命令都存到 appendonly.aof 文件中 。
appendfsync yes
appendfsync always #每次有数据修改发生时都会写入AOF文件。
appendfsync everysec #每秒钟同步一次，该策略为AOF的缺省策略。
Redis 主从复制
主从配置结合哨兵模式能解决单点故障问题，提高 Redis 可用性。
哨兵：
哨兵的任务：
- 监控：不断检查主服务器和从服务器是否正常运行。
- 通知：当被监控的某个 Redis 服务器出现问题，Sentinel 通过 API 脚本向管理员或者其他应用程序发出通知。
- 自动故障转移：当主节点不能正常工作时，Sentinel 会开始一次自动的故障转移操作，它会将与失效主节点是主从关系的其中一个从节点升级为新的主节点，并且将其他的从节点指向新的主节点，这样人工干预就可以免了。
- 配置提供者：在 Redis Sentinel 模式下，客户端应用在初始化时连接的是 Sentinel 节点集合，从中获取主节点的信息。