Redis学习

原创已于 2022-04-06 12:01:33 修改 · 432 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#redis

于 2022-04-06 11:59:14 首次发布

数据库同时被 2 个专栏收录

4 篇文章

订阅专栏

中间件学习

4 篇文章

订阅专栏

Redis

配置

bind 注解掉允许其他主机访问
关闭保护模式
tcp连接
Memcache

发布和订阅

发布者
订阅者

6379端口

String list set zset hash

单线程＋多路IO复用

默认16个数据库默认0号库

原子性：

原子操作，操作不会打断，得益于他是单线程
1. 不会出现多线程抢占并发问题

常用命令

设置取值
1. string
  1. set设置，get取值
    1. mset设置多值，mget取多值
  2. append在数据后面追加值
  3. Strlen获取值的长度
  4. incr让数值加一，decry数值减一
2. List
  1. lpush/rpush ,
    1. lpush从左边开始放
    2. rpush从右边开始放
  2. lpop/rpop;从左或者从右取值，取光键无
  3. rpoplpush右侧取值查到左侧
  4. lrange遍历所有链表
type 查看具体数据类型
删除
1. del 删除指定key数据
2. unlink 逻辑删除，后续异步操作，防止阻塞
3. flushdb清除当前库数据
4. flushall清除所有的数据
expire 设置过期时间 ttl 查看过期时间
select 切换库
dbsize查看库里面数据量

常用类型

string
1. 底层用数组实现
2. string类型是二进制安全的，意味着Redis的string可以包含任何的数据，
3. 一个redis的value最多可以存512M
4. 1M以内扩容两倍，超过1M之后每次扩容1M，最大不能超过512
List列表
1. 底层形式
  1. 如果元素较少的情况下，会用一块连续的内存存储，用的压缩链表
  2. 数据较多的时候才会改成quickList快速链表
2. 底层双向链表
Set集合无序
Hash
1. 适合存储对象
2. hash类型对应两种：数据少ziplist（压缩列表），数据大hashtable（哈希表）
3. $[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-o1EQvyNj-1649217479458)(C:\Users\admin\AppData\Roaming\Typora\typora-user-images\image-20210825201229096.png)]$
Zeset 有序集合
1. 顺序排名
2. hash方式存储
3. 跳跃表（跳表）
  1. $[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Pb5ZyfzY-1649217479460)(C:\Users\admin\AppData\Roaming\Typora\typora-user-images\image-20210825202347793.png)]$
  2. 从第二层开始查找，查找到中间然后进入下一层

新的数据类型

BItmaps
1. 本身不是数据类型，他是字符串，转换成ASCLL码然后转换成二进制存储
HyperLogLog
1. 统计网站 pv访问量，先去重，然后计数
2. 不会对重复增加的元素进行增加和计算，
Geoadd
1. 经度纬度范围Hash操作
2. 经度在-+180，纬度-+85

事物三大特性：

单独的隔离性
1. 将命令序列化，顺序执行，防止其它命令插队，串行化
没有隔离级别的概念
1. 队列中的命令没有提交之前都不会实际被执行，因为事物提交前任何指令都不会被执行
不保证原子性
1. 输入Multi命令开始，的命令都会进入队列中组队，但不会执行，输入Exec就会开始执行，但是可以通过discard放弃组队
  1. 事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚
  2. 在组队中错误，所有命令都无法执行，组队时未出现错误，但是运行时出现错误，该命令无法执行，其它命令可以执行//因为redis中只会进行语法检测不会进行语义检测。

Redis持久化

官方
1. RDB持久化方式能在指定的时间间隔对你的数据进行快照存储
2. AOF持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以redis协议追加保存每次写的操作到文件末尾
3. Redis还能对AOF进行后台重写，使得AOF文件的体积不至于过大
4. 如果只希望数据在服务器运行的时候存在，可以不使用任何持久化方式
5. 可以同时开启两种持久化方式
  1. 这种情况，redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整
RDB和AOF推荐
1. 官方推荐两个都启用
2. 如果对数据不敏感，可以选单独用RDB
3. 不建议单独用AOF，因为可能会出现Bug
4. 如果只是做纯内存缓存，可以都不用
RDB快照
1. 在指定的时间间隔内将内存中的数据集快照写入磁盘，
2. 可以通过快照的方式恢复数据
AOF日志
1. 优势/缺点
  1. 优势
    1. 备份机制更稳健，丢失数据概率更低
    2. 可读的日志文本，通过操作AOF稳健，可以处理误操作
  2. 缺点
    1. 比起RDB占用更多的磁盘空间
    2. 恢复备份速度要慢
    3. 每次读写都同步的话，有一定的性能压力
    4. 有部分bug
2. Rewite压缩
  1. 设置一个重写的基准值，大于这个基准值的两倍的时候，会发生重写，重写流程用的时写时复制技术
    1. AOF文件大小超过重写策略或者手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；
  2. 当文件过大的时候，redis就会启动AOF文件的内容压缩，只保留最小指令集
  3. 重写原理，会fork出一条新进程来将文件重写，
    1. redis4.0 之后的重写，以二进制的形式附在新的aof头部，作为已有的历史数据，替换掉原来的流水账操作
3. AOF持久化流程
  1. 客户端的请求命令会被append追加到AOF缓冲区内
  2. AOF缓冲区根据AOF持久化策略【always，everysec，no’】将操作sync同步到磁盘的AOF文件中
    1. 持久化策略
      1. always 始终同步，每次写入都会立即写入日志
      2. everysec 每秒同步，每秒计入日志一次，如果宕机，本秒数据可能丢失
      3. no 不主动进行同步，把同步时机交给操作系统
4. 以日志的形式来记录每个写的操作（增量保存）
5. 默认不开启，在redis.conf配置文件中修改配置
6. 开启之后redis默认听aof的
文件修复 redis-check-aof --fix修复

主从复制

Master/slave
好处
1. 主库写，从库读主从分离——一主多从
2. 容灾的快速恢复
  1. 集群配置多个一主多从服务器集群
    1. 从服务器挂掉之后再次启动会变成主服务器，需要重新加入
    2. 加入之后会复制所有数据
    3. **默认：**当主服务器挂掉之后，从服务器还是认主服务器，主服务器重新启动之后，依旧是主服务器
当从服务器连接上主服务器之后
1. 从服务器向主服务器发送同步消息，
2. 主服务器发送rdb文件给从服务器进行读取
3. 后续每次主服务器增加，从服务器都会进行同步
薪火相传
1. 主服务器同步到从服务器，从服务器在同步到其它从服务器，
  1. 缺点就是中间的从服务器挂掉，后面的服务器直接断掉
反客为主
1. 主服务器挂掉之后，从服务器替代主服务器成为主服务器slaveof no one 配置（可以用哨兵模式自动实现反客为主）
2. 哨兵模式：使用哨兵机制在主服务器挂掉之后，替换从服务器为主服务器
  1. 故障恢复
    1. 投票选择一个哨兵，由这个哨兵去选出新的主服务器
    2. 挑选出新的从服务器，成为主服务器，原先的主服务器变成从服务器。
    3. 选择优先级考前的
    4. 偏移量大最大的
    5. runid最小的从服务
  2. 使用sentinel.conf配置文件配置监听主机命令：sentinel mointor mymaster ip地址端口号 x
  3. x为一个数值，有多少个哨兵同意才可以开始切换
  4. redis.config配置文件中有一个配置值，值越小优先级最高

面试题的总结

Redis有什么特点？
1. 是一款内存高速缓存noSQL，由C语言编写
2. 每秒可以处理超过10万次读写
3. 内部用的是key—value储存结构，单个value最大的是1GB
4. 限制就是数据库容量容易受到物理内存的限制，不能作为海量数据的高性能读写，因此Redis适合场景主要在较小数据的高性能操作和运算上
为什么Redis要放到内存中
1. 为了达到最快的读写速度，所以将所有的数据都读取到内存中，
2. 并且通过异步的方式RDB和AOF存储到磁盘中，令数据持久化
3. 如果不放在内存中对磁盘的大量I/O操作将会严重影响Redis的性能
Redis的常见性能问题
1. 关于主服务器RDB快照持久化
  1. 使用Save命令创建快照，是让主线程去创建，如果写入时间太长，容易造成主线程的阻塞
  2. 执行bgsave命令，会创建一个子进程取生成RDB文件，避免主线程的阻塞
  3. 执行bgsave过程中，redis依旧可以继续执行操作命令，用的技术就是写时复制技术
2. 主服务器AOF持久化，
  1. 如果AOF文件非常大，就会对主服务器的重启恢复速度造成很大的影响，
  2. 如果某个数据比较关键的话，可以用一个从服务器进行AOF备份数据，然后在进行同步。
3. AOF的重写
  1. 主服务器重写AOF文件会占用大量的CPU和内存
4. Redis主从复制问题
  1. 为了主从复制的速度和连接的稳定性，Redis的主从服务器最好在一个局域网之内
Redis最合适的场景
1. 会话缓存
2. 全页缓存
3. 队列抢票
4. 排行榜
5. 发布订阅
6. 点赞
Reids有哪几种数据结构
1. String ：一种最简单的Key—Value结构
2. List：链表结构（redis使用的是双向链表）
3. Hash：字典，类似于我们客户端打包数据给我们的JSON字符串
4. Set：无序集合 Set就是一个集合，一堆不重复的值的组合
5. Sorted Set：有序集合
redis的持久化
1. RDB快照和AOF日志方式
  1. RDB快照记录的是某一个时间点的redis数据，比较详细，这种方式更加适合备份，非常适用于灾难的恢复
  2. AOF日志，是对每一次的命令操作进行记录，新的命令会追加在AOF文件的末尾，
  3. 如果同时开启AOF和RDB他将会优先使用AOF文件来还原数据集
雪崩和缓存穿透，缓存击穿
1. 雪崩：同一时间redis数据库中大量数据过期，然后导致大量访问数据库导致崩溃
  1. 解决：
    1. 每个属性过期都设置一个间隔，防止大量数据一起过期
2. 击穿：有一条指令过期，此时大量的请求发送过来，于是区数据库中请求这条数据并且加载到缓存，这个时候大量的请求可能会把数据库压垮
  1. 使用排他锁
3. 穿透：数据本来不存在，然后每次请求都会访问到数据源，从而压垮数据源
  1. 采用布隆过滤器，将所有可能用到大量数据存储到BitMap中，一个一定不存在的数据就用这个bitMap拦截掉，
  2. 直接返回一个空，缓存到redis，让其他请求去获取这个空数据