Redis基础知识点整理

文章目录

• Redis基础知识点整理
• • nosql概述
  • redis基础
  • 五大数据类型
  • 三种特殊数据类型
  • redis.conf
  • redis的持久化
  • redis的事务
  • redis 的发布订阅
  • redis的主从复制
  • 缓存穿透/雪崩/击穿
  • jedis
  • springboot整合redis
  • redis分布式锁
  • 实现限流的三种方式
  • 布隆过滤器

nosql概述

特点： 易拓展，大数据下高性能，多种灵活的数据类型，最终一致性，cap定理
几种数据库类型：键值对；列存储；图关系数据库；文档型数据库（mongodb）
cap：强一致性，可用性和分区容错性

redis基础

基于内存，单线程。100000+qps，默认16个数据库

五大数据类型

string类型:常规计数，粉丝数，微博数等
set，get，append，del，strlen，incr，decr，incrby，decrby，
getrange key 0 -1 （获取全部值）
setrange key 1 XX（替换值）‘
setnx（没有时插入，成功返回1）
setex key value expire（过期时间）
ttl key （查看过期时间）
mset/mget/msetnx
getset key value (没有旧值返回nil)

list 消息队列，栈, 消息排行
lpush/rpush/lrange/lpop/rpop/llen/lindex
ltrim key 1 2（截断list）
rpoplpush key1 key2 (删并插）
lset key index value
linsert key before/after pivot value

set 共同关注，二度好友，共同喜好
sadd，spop，smembers（返回全部成员）,sismember(判断元素是不是集合成员)，srem （移除元素），scard（元素个数），srandmember（返回集合里面的一个随机元素）
smove key1 key2 member(移动元素)
sdiff（差集）
sinter（交集）
sunion(并集)

hash和kv模式一样，但是value是一个键值对
hset，hget,hmset,hmget,hgetall,hdel,hlen
hkeys key
hvals key
hexists key key
hincrby key ket 10
hsetnx key key value

zset 在set的基础上加了一个score（set是k1 v1 v2 v3，zset是 k1 score1 v1 score2 v2）
zadd、zrange、zcard、zrem、zcount（制定分区成员数量）、zrank key value（获取排名）、zrevrank
zrangebyscore（取值病从小到大排序）
zrevrangebyscore（取值并从大到小排序）

三种特殊数据类型

geospatial用来存储地球上的城市（包含经纬度信息）。提供了计算两点之间距离，查询指定点给定半径内城市等方法
hyperloglog基数统计，提供了不精确的去重计算方案（0.8%），提供了计算基数，以及并集查询基数的方法
bitmap位存储，也叫位图，节约存储空间，可以存只有两种状态的数据，用01代表不同状态。如每天的打卡情况，提供了统计1的数量的方法

redis.conf

配置文件就在安装目录下，大小写不敏感

appendonly no //是否以append only模式作为持久化方式，默认使用的是rdb方式持久化，这种 方式在许多应用中已经足够用了
appendfilename “appendonly.aof” //appendfilename AOF 文件名称
appendfsync everysec //appendfsync aof持久化策略的配置

no表示不执行fsync，由操作系统保证数据同步到磁盘，速度最快。
always表示每次写入都执行fsync，以保证数据同步到磁盘。
everysec表示每秒执行一次fsync，可能会导致丢失这1s数据。

快照
save 900 1# 900秒（15分钟）内至少1个key值改变（则进行数据库保存–持久化）
save 300 10 # 300秒（5分钟）内至少10个key值改变（则进行数据库保存–持久化）
save 60 10000 # 60秒（1分钟）内至少10000个key值改变（则进行数据库保存–持久化）
stop-writes-on-bgsave-error yes # 持久化出现错误后，是否依然进行继续进行工作
rdbcompression yes # 使用压缩rdb文件 yes：压缩，但是需要一些cpu的消耗。no：不压 缩，需要更多的磁盘空间
rdbchecksum yes # 是否校验rdb文件，更有利于文件的容错性，但是在保存rdb文件的时 候，会有大概10%的性能损耗
dbfilename dump.rdb # dbfilenamerdb文件名称
dir ./ # dir 数据目录，数据库的写入会在这个目录。rdb、aof文件也会写在这个目录

常规
守护进程方式启动 daemonize yes
闲置多久关闭连接 timeout 300 //0表示不关闭
日志级别 loglevel verbose
设置当本机为slav服务时，设置master服务的IP地址及端口，在Redis启动时，它会自动从master
进行数据同步 slaveof
当master服务设置了密码保护时，slav服务连接master的密码 masterauth
设置同一时间最大客户端连接数 maxclients 128
指定Redis最大内存限制 maxmemory
开启关闭虚拟内存 vm-enabled no

redis的持久化

rdb 快照,恢复时是直接讲快照文件读入内存
Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程
都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的。
这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那
RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。
Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量，环境变量，程序计数器等）
数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程。
恢复方法:将备份文件（dump.rdb）移动到redis安装目录并启动服务即可
优缺点:
1、适合大规模的数据恢复
2、对数据完整性和一致性要求不高
1、在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改
2、Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑。

AOF文件追加的方式，文件会越来越大。aof有三种同步策略，每次修改同步，每秒同步，从不同步。
aof文件太大了会触发重写机制。
正常恢复：
启动：设置Yes，修改默认的appendonly no，改为yes
将有数据的aof文件复制一份保存到对应目录（config get dir）
修复： redis-check-aof --fix appendonly.aof 进行修复 //如果有损坏就执行
恢复：重启redis然后重新加载
重写机制：AOF 文件持续增长而过大时，会fork出一条新进程来将文件重写（也是先写临时文件最后再
rename），遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧
的aof文件，这点和快照有点类似！
优缺点：
1、每修改同步：appendfsync always 同步持久化，每次发生数据变更会被立即记录到磁盘，性能较差
但数据完整性比较好
2、每秒同步： appendfsync everysec 异步操作，每秒记录 ，如果一秒内宕机，有数据丢失
3、不同步： appendfsync no 从不同步
1、相同数据集的数据而言，aof 文件要远大于 rdb文件，恢复速度慢于 rdb。
2、Aof 运行效率要慢于 rdb，每秒同步策略效率较好，不同步效率和rdb相同。

如果只用redis做缓存，是不需要持久化的。aof，rdb两者一起用，会优先aof，因为更完整。drb适合备份数据库。drb一般设置15min一次。
修改重写触发的大小为5g，而不是默认的64m。过度重写会出现阻塞。不开启aof，只用主从复制也是可以的，但是一旦主从机一起死了，那就丢失了10几分钟的数据。

redis的事务

不保证原子性
就是按照顺序的执行一系列指令集
中间有错误的指令，其他正确的指令依旧会被执行
watch、unwatch 监视数据，发生变化事务执行失败（类似于乐观锁，出现问题再执行失败）

redis 的发布订阅

这是一种消息通讯模式（观察者模式，需要发布与订阅）

redis的主从复制

默认每台都是主节点，主节点可以有多个从节点，从节点只能有一个主节点。数据从主节点复制进从节点，是单向的。
作用：
数据冗余，故障恢复，负载均衡，高可用的基石（单台机器从容量，访问量压力，机构上都不太满足需求）
配置：配从不配主。要配置进cofn文件，否则每次都要重新配置
复制有全量复制和增量复制，连接到主机的时候就会进行一次全量复制

哨兵模式不需要人工干预主机的切换
通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。
当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服
务器，修改配置文件，让它们切换主机。
优点就是主从的优点，主从可以切换，故障可以转移，系统可用性更好。缺点是不容易在线扩容，配置繁琐。

缓存穿透/雪崩/击穿

缓存穿透：redis中没有查询到，从而访问了持久层数据库。布隆过滤器
缓存击穿：热点数据过期的时候，大量请求访问到持久层。解决的方法是不让热点数据过期，分布式锁
缓存雪崩：缓存集中失效，同上。解决办法：数据预热，redis高可用集群，限流降级

jedis

连接、基础api、事务

springboot整合redis

使用redisTemplate
写一个redisTemplate。redisTemplateredisAutoConfiguration会自动创建一个redisTemplate。但是我们需要自己写一个，设置好序列化与反序列化相关操作。
再写一个工具类，因为redisTemplate操作数据需要很多行代码

redis分布式锁

原理不想写了

https://blog.csdn.net/ugg/article/details/41894947 //这篇思路值得借鉴

实现限流的三种方式

多个setnx表示请求 + 过期时间，很不好用
zset，将请求全部放进去，请求时间戳作为score，value要保证唯一
令牌桶算法，定时持续往list中添加令牌，出队代表拿到令牌，表示还没有到限流

布隆过滤器

对可能的查询以hash形式存储，会进行一次校验，不满足的查询会被丢弃，减轻底层存储系统的压力.主要是怕出现空查询，先判断key是否存在。
原理：

1. 首先需要k个hash函数，每个函数可以把key散列成为1个整数
2. 初始化时，需要一个长度为n比特的数组，每个比特位初始化为0
3. 某个key加入集合时，用k个hash函数计算出k个散列值，并把数组中对应的比特位置为1
4. 判断某个key是否在集合时，用k个hash函数计算出k个散列值，并查询数组中对应的比特位，如果所有的比特位都是1，认为在集合中。

优点是不需要存储键值对，缺点是可能假命中，以及不能删除。