Redis基础总结

之前一直都只知道redis是一种K,V 型数据库，存储在内存中较为方便，但是对其真正的实际应用却比较少，仅仅是简单的体验过，直到最近自己在一个SpringBoot的项目中运用redis作为缓存使用，才算真正体会到了redis的好用之处和优势。在这里记录下我的学习过程。

Redis基础

Redis应用场景

按照我的理解来说，用户每次从数据库中去存取数据库中存取，而数据库中的数据是持久化在硬盘上面的MySQL等数据库也有自己的缓存机制），这样每次的开销是非常的大的（对于数据库来说当QPS（qurey per second 超过2000即不再承受范围之内了，而最简单的单机redis缓存即可支持十万以内的QPS））。而对于在实际项目中一些不是特别重要和稀疏的数据，用数据库存是不合理的，所以借助redis来进行缓存，即把数据以key和value的形式存储在内存当中。初次之外，还可以借助redis进行会话管理，当进行负载均衡的时候，多个服务器判断同一个用户的cookies。也是十分方便的。（cookies天然具备的的过期机制）。
Redis典型的应用场景如下：

计数器

可以对 String 进行自增自减运算，从而实现计数器功能。是redis的String类型的inr等操作。

Redis 这种内存型数据库的读写性能非常高，很适合存储频繁读写的计数量。

缓存（常用）

将热点数据放到内存中，设置内存的最大使用量以及淘汰策略来保证缓存的命中率。

查找表

例如 DNS 记录就很适合使用 Redis 进行存储。

查找表和缓存类似，也是利用了 Redis 快速的查找特性。但是查找表的内容不能失效，而缓存的内容可以失效，因为缓存不作为可靠的数据来源。

消息队列

List 是一个双向链表，可以通过 lpush 和 rpop 写入和读取消息

不过最好使用 Kafka、RabbitMQ 等消息中间件。

会话缓存（常用）

可以使用 Redis 来统一存储多台应用服务器的会话信息。

当应用服务器不再存储用户的会话信息，也就不再具有状态，一个用户可以请求任意一个应用服务器，从而更容易实现高可用性以及可伸缩性。

分布式锁实现

在分布式场景下，无法使用单机环境下的锁来对多个节点上的进程进行同步。

可以使用 Redis 自带的 SETNX 命令实现分布式锁，除此之外，还可以使用官方提供的 RedLock 分布式锁实现。

Redis线程模型

参照下面这张图

可以看到其是一个I/O多路复用的模型，和之前学过的NIO十分的相像，来一个线程将其放入队列中，再由分派器进行分派。具体的实现细节我没有去细致看，不过大致流程和思想和NIO是一样的。简单来说，这是一个单线程的模型，避免了线程切换的开销。同时是一个纯内存的操作并基于I/O复用的同步非阻塞模型。

Redis和memcached的区别

memcached我并没有了解过，据说是早年互联网大公司使用的缓存模型。通过看各种面经和博客，总结出以下几点区别：

（1）：Redis是基于I/O多路复用的单线程非阻塞模型
（2）：Redis支持多种不同的数据类型
（3）：Redis支持集群

Redis数据结构和其基本用法

Redis的数据结构包括 string list hash set sortset五种，每一种数据结构都有其用处和意义，在实际项目中也确实如此。

比如string用来存简单的k,V还可自增自减，作计数器。
list作为一个双向队列，在考虑公平和顺序的应用场景中使用.
hash是一个字典，用来存一个对象中多个不同的属性十分方便。
set是无序唯一集合，用来做业务中的并，交，去重，尤其是类似于共同好友等功能具有十分好用。
sortset是一个带权重的set，常用来做排名等功能。

对于其具体的命令在官网上都可以查询的到，因为其是英文版本的，可能对一些同学来说比较吃力，推荐下面个地址进行相关命令的学习和巩固：http://www.redis.cn/commands.html
常用的命令：
String: set, get, rename,setex(设置过期时间,关键) ,del(删除key),incr(自增)，incrby,
list: lpush,lpop,lrange,lindex,llen,lrem
set: sadd,srem,sunion(并)，sinter(交)，slen,scard,smembers,sismember,sdiffer
hash: hset,hget,hgetall,hdel,hkeys,hvalues
sort set: zadd,zrange,zcount,zcard,zrem,zscore,zreverange

Redis 持久化机制

很多时候我们需要持久化数据也就是将内存中的数据写入到硬盘里面，大部分原因是为了之后重用数据（比如重启机器、机器故障之后恢复数据），或者是为了防止系统故障而将数据备份到一个远程位置。当我关机了后重启发现在redis目录下多出来了一个dump.rdb文件，就是持久化转储的一个快照。

Redis不同于Memcached的很重一点就是，Redis支持持久化，而且支持两种不同的持久化操作。Redis的一种持久化方式叫快照（snapshotting，RDB），另一种方式是只追加文件（append-only file,AOF）。这两种方法各有千秋，下面我会详细这两种持久化方法是什么，怎么用，如何选择适合自己的持久化方法。

快照（snapshotting）持久化（RDB）

Redis可以通过创建快照来获得存储在内存里面的数据在某个时间点上的副本。Redis创建快照之后，可以对快照进行备份，可以将快照复制到其他服务器从而创建具有相同数据的服务器副本（Redis主从结构，主要用来提高Redis性能），还可以将快照留在原地以便重启服务器的时候使用。

快照持久化是Redis默认采用的持久化方式，在redis.conf配置文件中默认有此下配置：

save 900 1           #在900秒(15分钟)之后，如果至少有1个key发生变化，Redis就会自动触发BGSAVE命令创建快照。

save 300 10          #在300秒(5分钟)之后，如果至少有10个key发生变化，Redis就会自动触发BGSAVE命令创建快照。

save 60 10000        #在60秒(1分钟)之后，如果至少有10000个key发生变化，Redis就会自动触发BGSAVE命令创建快照。

AOF（append-only file）持久化

与快照持久化相比，AOF持久化 的实时性更好，因此已成为主流的持久化方案。默认情况下Redis没有开启AOF（append only file）方式的持久化，可以通过appendonly参数开启：

appendonly yes

开启AOF持久化后每执行一条会更改Redis中的数据的命令，Redis就会将该命令写入硬盘中的AOF文件。AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的，默认的文件名是appendonly.aof。

在Redis的配置文件中存在三种不同的 AOF 持久化方式，它们分别是：

appendfsync always    #每次有数据修改发生时都会写入AOF文件,这样会严重降低Redis的速度
appendfsync everysec  #每秒钟同步一次，显示地将多个写命令同步到硬盘
appendfsync no        #让操作系统决定何时进行同步

为了兼顾数据和写入性能，用户可以考虑 appendfsync everysec选项 ，让Redis每秒同步一次AOF文件，Redis性能几乎没受到任何影响。而且这样即使出现系统崩溃，用户最多只会丢失一秒之内产生的数据。当硬盘忙于执行写入操作的时候，Redis还会优雅的放慢自己的速度以便适应硬盘的最大写入速度。
redis 设置过期时间
Redis中有个设置时间过期的功能，即对存储在 redis 数据库中的值可以设置一个过期时间。作为一个缓存数据库，这是非常实用的。如我们一般项目中的 token 或者一些登录信息，尤其是短信验证码都是有时间限制的，按照传统的数据库处理方式，一般都是自己判断过期，这样无疑会严重影响项目性能。

Redis设置过期时间

我们 set key 的时候，都可以给一个 expire time，就是过期时间，通过过期时间我们可以指定这个 key 可以存活的时间。

如果假设你设置了一批 key 只能存活1个小时，那么接下来1小时后，redis是怎么对这批key进行删除的？

定期删除+惰性删除。

通过名字大概就能猜出这两个删除方式的意思了。

定期删除：redis默认是每隔 100ms 就随机抽取一些设置了过期时间的key，检查其是否过期，如果过期就删除。注意这里是随机抽取的。为什么要随机呢？你想一想假如 redis 存了几十万个 key ，每隔100ms就遍历所有的设置过期时间的 key 的话，就会给 CPU 带来很大的负载！

惰性删除 ：定期删除可能会导致很多过期 key 到了时间并没有被删除掉。所以就有了惰性删除。假如你的过期 key，靠定期删除没有被删除掉，还停留在内存里，除非你的系统去查一下那个 key，才会被redis给删除掉。这就是所谓的惰性删除，也是够懒的哈！

但是仅仅通过设置过期时间还是有问题的。我们想一下：如果定期删除漏掉了很多过期 key，然后你也没及时去查，也就没走惰性删除，此时会怎么样？如果大量过期key堆积在内存里，导致redis内存块耗尽了。怎么解决这个问题呢？ redis 内存淘汰机制。具体的内存淘汰机制在后面的进阶部分再详细的介绍。