Redis基础知识总结

STARRY
245 阅读19分钟

Redis 是一个开源（BSD许可）的，内存中的数据结构存储系统，它可以用作数据库、缓存和消息中间件。 它支持多种类型的数据结构，如 字符串（strings）， 散列（hashes）， 列表（lists）， 集合（sets）， 有序集合（sorted sets） 与范围查询， bitmaps， hyperloglogs 和 地理空间（geospatial） 索引半径查询。 Redis 内置了 复制（replication），LUA脚本（Lua scripting）， LRU驱动事件（LRU eviction），事务（transactions） 和不同级别的 磁盘持久化（persistence）， 并通过 Redis哨兵（Sentinel）和自动 分区（Cluster）提供高可用性（high availability）。

Redis在6.0版本之后是多线程，6.0版本之前对用户而言是单线程操作，而内部是多线程操作。

Redis是一个开源的、用C写的、基于内存的亦可进行持久化操作的、key-value型的数据库、支持多种编程语言的API

Linux安装Redis

  1. 下载安装包
  2. 将安装包移动到与home同级的/opt根目录下
  3. 解压文件，sudo tar -zxvf redis-6.0.9.tar.gz

  1. 安装gcc（如果没有安装）
sudo apt update
sudo apt install build-essential
gcc --version
  1. 执行make命令
sudo make
sudo make install

  1. redis默认安装路径：/usr/local/bin

  2. 将redis.conf文件（解压路径下的）复制到redis默认安装路径下的自定义文件夹（yconfig）中

  1. redis默认不是后台启动，需要修改配置文件

  1. 启动redis服务

  1. 关闭redis服务

在redis-cli客户端输入shutdown

Redis基础知识

redis有16个数据库，默认使用的是第0号数据库

select num   	#选择数据库
DBSIZE    		#查看数据库大小
flushdb			#清空当前数据库
flushall		#清空所有数据库
exists	name	#查看当前key是否存在
move name 1 	#移除当前key
expire name 10 	#设置key的过期时间
ttl	name		#查看当前key的剩余时间
type name		#查看当前key的类型

Redis是基于内存操作的，CPU不是Redis性能的瓶颈、机器的内存和网络带宽才是。

redis是单线程为什么还那么快？

答：redis是将全部数据都放在内存中处理，所以通过单线程操作才是最快的；而多线程的话，CPU上下文会切换（这是耗时的）。

三种特殊数据类型

geospatial（地理位置）

使用场景：定位、测距离

只有六个命令

#geoadd 添加地理位置
#规则：地球两极坐标无法添加 
#参数：key 值(纬度 经度 名称)
GEOADD china:city 116.40 39.90 beijing 
GEOPOS china:city 名称  #获取指定位置的经纬度
geodist china:city beijing shanghai #获取两点之间的距离
#georadius 以给定的经纬度为中心，找出某一半径内的元素
georadius china:city 110 30 1100 km
georadiusbymember china:city beijing 100 km #找出指定位置范围内的符合条件的元素
geohash

GEO底层原理就是使用了sort sets

bitmaps

位存储 ，若一件事物只有两种状态则可以用bitmaps来存储

setbit
getbit

hyperloglog

Redis2.8.9版本更新了hyperloglog的数据结构

hyperloglog是基数统计的算法（如果允许容错的话则可由使用hyperloglog来统计访问量）

PFADD mykey a b c d e
PFCOUNT mykey
PFMERGE mykey3  mykey1 mykey2

事务

Redis事务本质就是一组命令的集合，这些命令都会被序列化，而且在事务执行的过程会保证一次性、顺序性、排他性！

Redis单条命令保证原子性，但Redis中的事务却不能保证原子性。

Redis事务没有隔离级别的概念

所有的命令在事务中，没有直接被执行，只有发起执行命令的时候才会被执行。Exec

Redis事务分为三个阶段：

  1. 开启事务（multi）
  2. 命令入队（）
  3. 执行事务（exec）
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set k1 v1
QUEUED
127.0.0.1:6379> set k2 v2
QUEUED
127.0.0.1:6379> set k3 v3
QUEUED
127.0.0.1:6379> get k2
QUEUED
127.0.0.1:6379> exec
1) OK
2) OK
3) OK
4) "v2"

用discard来取消事务，事务队列中的命令都不会被执行。

编译型异常，事务中的所有命令都不会被执行。

运行时异常，事务中出错的命令不会被执行，其他的命令正常执行。

悲观锁：顾名思义，认为什么时候都可能会出现问题，所以无论做什么都会加锁

乐观锁：很乐观，认为什么时候都不会出现问题，所以不会上锁，更新数据的时候会判断一下，在此期间是否有人修改过数据。

  • 通过version来进行验证
  • 获取version
  • 更新的时候比较version

通过watch命令来实现Redis乐观锁操作，unwatch来解锁。

watch作用于事务时，如果发现被监听的对象已经被修改则事务会执行失败，解决方法就是

  • 第一步先通过unwatch解锁
  • 第二步获取最新的值，并通过watch执行监听操作
  • 第三部是通过exec执行事务。

Jedis

如果用Java来操作redis则用jedis的依赖包

测试：

  1. 连接数据库
  2. 操作命令
  3. 断开连接

测试代码

public class TestPing {
    public static void main(String[] args) {
        //1. new 一个jedis对象
        Jedis jedis = new Jedis("127.0.0.1", 6379);
        //之前学习过的命令在这里都成了一个个方法
        System.out.println(jedis.ping());
    }
}

输出结果为PONG则验证测试成功

jedis操作事务

public class TestPing {
    public static void main(String[] args) {
        //1. new 一个jedis对象
        Jedis jedis = new Jedis("127.0.0.1", 6379);
        jedis.flushDB();
        JSONObject jsonObject = new JSONObject();
        jsonObject.put("hello","world");
        jsonObject.put("name","yang");
        String s = jsonObject.toJSONString();
        //之前学习过的命令在这里都成了一个个方法
        //开启事务
        Transaction multi = jedis.multi();
        try {
            multi.set("user1",s);
            multi.set("user2",s);
            multi.exec();//执行事务
        }catch (Exception e){
            e.printStackTrace();
            multi.discard();//若果有错则关闭事务
        }finally {
            System.out.println(jedis.get("user1"));;
            System.out.println(jedis.get("user2"));;
            jedis.close();//关闭连接
        }
    }
}

SpringBoot整合redis

在SpringBoot2.x之后，原来使用的jedis被替换为了lettuce。

jedis：底层采用的直连，多个线程操作的话是不安全的，如果想要避免不安全，则使用jedis pool连接池，更像BIO模式。

lettuce：采用netty,实例可以在多个线程中共享，不存在线程不安全的情况。可以减少线程数据，更像NIO模式。

  1. 导入相关依赖

            <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-data-redis</artifactId>
        </dependency>

  2. 配置连接

    spring:
  redis:
    host: 127.0.0.1
    port: 6379

  3. 测试

            //opsForValue操作字符串
/*        redisTemplate.opsForValue();
        redisTemplate.opsForZSet();
        RedisConnection connection = redisTemplate.getConnectionFactory().getConnection();
        connection.flushDb();*/
        redisTemplate.opsForValue().set("gg","gameover");
        System.out.println(redisTemplate.opsForValue().get("mykey"));
        System.out.println(redisTemplate.opsForValue().get("gg"));
        redisTemplate.getConnectionFactory().getConnection().flushDb();
        System.out.println(redisTemplate.opsForValue().get("gg"));

自定义RedisTemplate

待补充

Redis.conf解析

Redis服务是通过配置文件启动的

unit对大小写不敏感

像Spring配置文件中可以通过import导入其他配置xml文件，redis通过includ导入。

网络NETWORK

bind 127.0.0.1   #绑定的ip地址
protected-mode yes	#保护模式
port 6379		#端口号设置

通用GENERAL

daemonize yes	#以守护进程的方式运行，默认是no，我们需要手动设置为yes

pidfile /var/run/redis_6379.pid	#如果以后台的方式运行，我们则需要指定一个pid文件

#日志
# Specify the server verbosity level.
# This can be one of:
# debug (a lot of information, useful for development/testing)
# verbose (many rarely useful info, but not a mess like the debug level)
# notice (moderately verbose, what you want in production probably)
# warning (only very important / critical messages are logged)
loglevel notice

logfile ""  #日志的文件位置名

databases 16	#数据库的数量，默认是16个数据库

always-show-logo yes	#是否总是显示logo

快照

持久化，在规定时间内执行了多少次操作则持久化到文件，.rdb .aof

redis是内存数据库，如果不持久化那么断电数据即失。

save 900 1  #如果900秒内，至少有一个key进行了修改，那么就进行持久化操作，
save 300 10 #同上
save 60 10000

stop-writes-on-bgsave-error yes	#持久化如果出错，是否还继续工作

rdbcompression yes	#是否压缩rdb文件，默认开启

rdbchecksum yes		#保持rdb文件的时候进行检查校验

dir ./		#rdb文件保存的路径，默认是当前目录下

安全

可以设置redis的密码，redis默认是没有密码的

config get requirepass #获取redis密码
config set requirepass "123456"  #设置密码为12456
#设置密码后要进行验证
auth 123456

客户端

maxclients 10000 #设置能连接上redis的最大客户端数量
maxmemory <bytes> #redis配置最大的内存容量
maxmemory-policy noeviction	#内存达到上限之后的处理策略 有6种
1、volatile-lru：只对设置了过期时间的key进行LRU（默认值） 
2、allkeys-lru ： 删除lru算法的key   
3、volatile-random：随机删除即将过期key   
4、allkeys-random：随机删除   
5、volatile-ttl ： 删除即将过期的   
6、noeviction ： 永不过期，返回错误

APPEND ONLY MODE（AOF配置）

appendonly no 	#默认不开启aof模式，默认是使用rdb方式持久化

appendfilename "appendonly.aof"	#持久化文件的名字

# appendfsync always	#每次修改都会同步，消耗性能
appendfsync everysec	#每秒执行一次同步，
# appendfsync no

Redis持久化

RDB（Redis DataBase）

什么是RDB？

在指定的时间间隔内将内存中的数据集体快照写入磁盘，它恢复时是将快照文件直接读取到内存中。

Redis会单独创建（fork）一个字进程来进行持久化操作，会先将数据写入到一个临时文件中，等持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的。这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。我们默认的就是RDB，一般情况下不需要修改这个配置! rdb保存的文件是dump.rdb

触发rdb机制的条件

  1. save的规则满足的情况下会触发rdb规则
  2. 执行flushall命令，也会触发rdb规则
  3. 退出redis，也会产生rdb文件

备份就自动生成一个dump.rdb文件

如何恢复rdb文件

只需要rdb文件放在我们redis启动目录下就可以了，redis启动的时候会自动读取dump.rdb恢复其中的数据。

查看需要存在的位置

127.0.0.1:6379> config get dir
1) "dir"
2) "/usr/local/bin"		#如果在这个文件下存在dump.rdb文件那么启动时会自动恢复
127.0.0.1:6379>

优点：

  1. 是和大规模的数据恢复
  2. 对数据的完整性要求不高

缺点：

  1. 需要一定的时间间隔进程操作，如果redis宕机了，那么最后一次修改数据的机会就没有了。
  2. fork进程的时候会占用一定的内存

AOF（Append Only File）

将我们的所有命令都记录下来，恢复的时候就把这个记录命令的文件全都执行一遍

以日志的形式来记录每个写操作，将Redis执行过的所有指令都记下来（不记读操作），只许追加文件但不能改写文件，redis启动之初会读取该文件重新构建数据。换言之，redis重启的话就是根据日志文件的内容将所有的写指令整个按序执行一遍以完成对数据的恢复工作。

AOF保存的文件是appendonly.aof文件

如果AOF和RDB同时开启，Redis采用哪种策略？

AOF是基于命令追加,而RDB是基于快照,根据策略每隔一段时间保存一份数据快照,相比较之下，AOF更新频率更，数据更加完整,所以如果AOF和RDB同时存在的时候,Redis会优先使用从AOF文件来还原数据库状态,如果AOF关闭状态时,则从RDB中恢复。

如果aof文件有错误，redis是无法启动的。我们需要redis-check-aof --fix命令来修复出错的aof文件。

Redis发布订阅

三要素：发布者 队列 订阅者

测试

#订阅者
127.0.0.1:6379> subscribe kuangshenshuo  #订阅一个频道 kuangshenshuo
1) "subscribe"
2) "kuangshenshuo"
3) (integer) 1
1) "message"    #监听、读取发布者推送的信息
2) "kuangshenshuo"
3) "hellokuang"
1) "message"   #消息
2) "kuangshenshuo"	#来自哪个频道
3) "hello,redis"	#消息内容

#发布者
127.0.0.1:6379> publish kuangshenshuo "hellokuang"
(integer) 1
127.0.0.1:6379> publish kuangshenshuo "hello,redis" #在指定频道发布信息
(integer) 1
127.0.0.1:6379>

原理

Redis通过subscribe、psubscribe、publish等命令实现发布订阅功能。

通过subscribe命令订阅某个频道后，redis-server里维护了一个字典，字典的键就是一个一个频道，值就是一个链表，链表中保存了所有订阅这个channel的客户端。subscribe命令的关键就是将客户端添加到对应channel的订阅链表中。

Redis主从复制

概念

主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(master/leader)，后者称为从节点(slave/follower);==数据的复制是单向的，只能由主节点到从节点==。Master以写为主，Slave以读为主。

默认情况下，每台Redis服务器都是主节点;且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点。

主从复制的作用主要包括: 1、数据冗余︰主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。 2、故障恢复︰当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复;实际上是一种服务的冗余。 3、负载均衡∶在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载;尤其是在写少读多的场景下，通过多个从节点分担读负载可以大大提高Redis服务器的并发量。 4、高可用基石︰除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。

一般来说，要将Redis运用于工程项目中,只使用一台Redis是万万不能的(宕机) , 原因如下: 1、从结构上,单个Redis服务器会发生单点故障,并且-台服务器需要处理所有的请求负载,压力较大; 2、从容量上,单个Redis服务器内存容量有限,就算一台Redis服务器内存容量为256G ,也不能将所有内存用作Redis存储内存，一般来说 ,单台Redis最大使用内存不应该超过20G.

电商网站上的商品，- -般都是一次上传,无数次浏览的,说专业点也就是”多读少写"。 对于这种场景,我们可以使如下这种架构:|

环境配置

只配置从库，不用配置主库。

#查看当前库的信息
127.0.0.1:6379> info replication
# Replication
role:master  #角色 主机
connected_slaves:0  #从机个数  0  
master_replid:d345a13ec64eb0821ca44c66703aeb10e99ea35d
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

复制3个配置文件（redis.conf），修改对应的信息

  1. 端口号

  2. pid名字

  3. log文件名字

  4. dump.rdb文件名字

修改完毕之后启动3个redis服务器

从机中配置对应主机，在命令行中输入

slaveof  主机ip地址 主机端口号

真实的主从配置应该是在配置文件中配置，这样的话才是永久的。我们这个是命令配置是暂时的。

细节

  • 主机可以写，从机只能读。
  • 主机中的所有数据都会自动被从机保存
  • 主机断开连接后，从机依然连着主机。等主机从新启动后，写的数据依然可以从从机客户端读取到
  • 如果使用的是命令行方式进行主从配置，那么从机断开后，就会被变成主机。如果再变成从机，那么主机的数据又可以立马读取到。

复制原理

Slave启动成功连接到master后会发送一个sync命令

master接到命令，启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将整个数据文件传送到slave，并完成一次完全同步。

全量复制：而slave服务在接受到数据库文件数据后，将其存盘并加载到内存中。

增量复制：master继续将新的所有收集到的修改命令依次传给slave，完成同步。

但只要是重新连接master，一次完全同步（全量复制）将被自动执行

可以使用slaveof no one使从机变为主机

哨兵模式

redis2.8提供了哨兵模式来解决手动切换主从库，sentinel能够自动在后台监控主机是否故障，如果故障了根据投票数自动将从库转为主库。

哨兵模式是一种特殊的模式，首先redis提供了哨兵的命令，哨兵是一个独立运行的进程。其原理是哨兵通过发送命令，等待redis服务器响应，从而监控运行的多个redis实例。

哨兵的作用：

  • 通过发送命令，让redis服务器返回监控其运行状态，包括主、从服务器。
  • 当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。

然后一个哨兵进程对redis服务器监控是不够的，所以使用多个哨兵来进行互相监控。这样就形成了多哨兵模式。

假设主服务器当即，哨兵1先检测到这个结果，系统并不会立即进行failover操作，仅仅是哨兵1主观认为当前主服务器不可用，这个现象称为主观下线。当后面的哨兵也检测到主服务器不可用时，并且数量达到一定值时，哨兵之间会进行一次投票选取其他从机当选主服务器（投票由任意一个哨兵发起），根据投票结果，哨兵进行failover（故障转移）操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。

1.配置哨兵配置文件sentinel.conf

#sentinel monitor 被监控的名称 host port  1  
#数字1代表如果主机挂了，那么根据投票结果，票数最多的那个从机当选成主机
sentinel monitor myredis 127.0.0.1 6379 1

2.启动哨兵

像启动redis服务器一样，通过redis-sentinel yconfig/sentinel.conf命令来启动

哨兵模式规则：如果主机挂了，那么从从机中根据投票结果选出胜任的主机。如果主机在选票完成后回来了，那么只能归并到新的主机下当从机。

优点：

  1. 哨兵集群，基于主从复制模式，所有主从配置的优点它都有
  2. 主从可以自动切换，故障可以转移，系统可用性提高
  3. 哨兵模式就是主从模式的升级，手动到自动

缺点：

  1. redis不好在线扩容
  2. 哨兵模式配置较麻烦

Redis缓存穿透和雪崩

缓存穿透（查不到）

概念

用户想要查询一个数据，发现redis内存数据库没有，也就是缓存没有命中，于是去数据库中查询，发现也没有。于是本次查询失败，当用户很多的时候，缓存都没有命中，于是都去请求了持久层数据库，这会给持久层数据库很大的压力，当数据库顶不住的时候，这时候就相当于出现了缓存穿透。

解决方案

1.布隆过滤器

布隆过滤器是一种数据结构，对所有可能查询的参数以hash形式存储，在控制层先进行校验，不符合则丢弃，从而避免了对底层存储系统的查询压力。

2.缓存空对象

当存储层不命中后，即使返回的空对象也将其缓存起来，同时会设置一个过期时间，之后再访问这个数据会从缓存中获取，保护了后端数据源。

这个方法也存在以下问题：

  1. 如果空值被缓存起来，就意味着缓存需要更多的空间来存储键，而这些键中可能大部分是空值。
  2. 即使对空值设置了过期时间，还是会存在缓存层和存储层的数据会有一段时间窗口的不一致，这对于需要保持一致性的业务有影响。

缓存击穿（查询量太大，缓存过期）

缓存击穿是指一个key非常热门（热点数据），再不停地扛着大并发，大并发集中对这一个key进行访问，当这个key在失效的瞬间，持续的大并发就会穿破缓存，直接请求数据库，查询最新的数据并写回缓存，这回导致数据库瞬间压力过大，就像在一个屏障上凿开了一个洞。

解决方法

1.设置热点数据用不过期

从缓存层面看，没有设置过期时间，所以不会出现热点key过期导致的问题

2.加互斥锁

分布式锁：使用分布式锁，保证对于每个key同时只有一个线程去查询后端服务，其他线程没有获得分布式锁的权限，因此只需要等待即可。这种方式将高并发的压力转移到了分布式锁，这对分布式锁的考验很大。

缓存雪崩

缓存雪崩指的是在某一个时间段，缓存集体过期失效。

解决方案

1.redis高可用

多增设几台redis服务器（集群）

2.限流降级

在缓存失效后，通过加锁或者队列来控制读取数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其他线程等待。专注于几项主要功能，停止其他功能的服务。

3.数据预热

在正式部署之前，先把可能访问的数据访问一遍，这样就会使数据加载到缓存中，在即将发生大并发访问前手动触发加载缓存不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀。

avatar
文章
阅读
粉丝