redis-基本概念01

一、redis介绍

1、特性

1〉速度快，数据放在内存中，官方给出的读写性能 10 万/S，与机器性能也有关
a,数据放内存中是速度快的主要原因
b,C 语言实现，与操作系统距离近
c,使用了单线程架构，预防多线程可能产生的竞争问题
2〉键值对的数据结构服务器
3〉丰富的功能：见上功能
4〉简单稳定：单线程
5〉持久化：发生断电或机器故障，数据可能会丢失，持久化到硬盘
6〉主从复制：实现多个相同数据的 redis 副本
8〉高可用和分布式：哨兵机制实现高可用，保证 redis 节点故障发现和自动转移
9〉客户端语言多：java php python c c++ nodejs 等

2、redis使用场景

1、缓存数据库
2、排行榜
3、计数器应用
4、社交网络
5、消息队列

3、redis配置、启动、操作、关闭

二、redis基本通讯模型

1、单线程架构

三个客户端同时执行命令
客户端 1：set name test
客户端 2：incr num
客户端3：incr num
执行过程：发送指令－〉执行命令－〉返回结果
执行命令：单线程执行，所有命令进入队列，按顺序执行，使用IO多路复用解决I/O问题（使用select/poll/epoll/kqueue 这些 I/O 多路复用函数库，解决了一个线程处理多个连接的问题）
单线程快原因：纯内存访问， 单线程避免线程切换和竞争产生资源消耗，RESP协议简单。
存在问题：如果某个命令执行慢，会造成其它命令的阻塞

通常java api发送一条redis指令(tcp连接)，实际上就是将指令打包成RESP协议发送给redis
RESP:比如： set name clock,转成RESP协议如下：
*3 ----->表示有3组数据
$3 ------->下面跟的指令长度为3
set -------->所根指令
$4 ------->下面跟的指令长度为5
name
$5 ------->下面跟的指令长度为5
clock
RESP协议包含：数据组数，指令长度，指令
问题：如果某个命令执行慢，会造成其它命令的阻塞

三、redis缓存雪崩与穿透

1、什么是雪崩

前提：为节约内存，redis一般会做定期清除工作
1）查询key=test值时，此时redis中没有数据
2）如查有5000用户并发来查询key=test,全到mysql中去查询，mysql会挂掉，导致雪崩
解决方案：
1）设置热点数据永远不过期
2）加互斥锁，代码如下

public static String getData(String key){
   //从缓存获取数据
   String result = getDateFromRedis(key);
   //缓存中不存在数据
   if(null == result){
      //去获取锁，获取锁成功，去数据中查找数据
      if(reenLock.tryLock()){
          result = getDataFromDB(key);
          if(null == result){
             setDataToRedis(key,result);
          }
          //释放锁
          reenLock.unlock();
      }else{
         //获取锁失败，暂停100ms，再去获取数据
         Thread.sleep(100);
         result = getData(key)'
      }
   }
   return result;
}

2、什么是缓存穿透

前提：查询一个不存在的订单号
1、redis中无此值
2、mysql中也无些值，但一直被查询

解决方案：
1、订单表所有数据查询来放到布隆过滤器，经过布隆过滤器处的数据很小（只存0或1）
2、每次查订单前，先到布隆过滤器里查询当前订单状态是0还是1，0的话代表数据库中没有数据，直接拒绝查询

四、redis持久化

redis 支持 RDB 和 AOF 两种持久化机制，持久化可以避免因进程退出而造成数据丢 失；

1、RDB持久化

RDB 持久化把当前进程数据生成快照（.rdb）文件保存到硬盘的过程，有手动触发 和自动触发

‘1)手动触发有 save 和 bgsave 两命令’

1. save命令：
   阻塞当前 Redis，直到 RDB 持久化过程完成为止，若内存实例比较大 会造成长时间阻塞，线上环境不建议用它
2. bgsave 命令：
   redis 进程执行 fork 操作创建子线程，由子线程完成持久化，阻塞时 间很短（微秒级），是 save 的优化,在执行 redis-cli shutdown 关闭 redis 服务时，如果没有开 启 AOF 持久化，自动执行 bgsave;
   bgsave运行流程：
   

2、RDB文件操作

命令：config set dir /usr/local //设置 rdb 文件保存路径
备份：bgsave //将 dump.rdb 保存到 usr/local 下
恢复：将 dump.rdb 放到 redis 安装目录与 redis.conf 同级目录，重启 redis 即可
优点：1，压缩后的二进制文，适用于备份、全量复制，用于灾难恢复
2，加载 RDB 恢复数据远快于 AOF 方式
缺点：1，无法做到实时持久化，每次都要创建子进程，频繁操作成本过高
2，保存后的二进制文件，存在老版本不兼容新版本 rdb 文件的问题

3、AOF持久化

AOF rewirte过程如下：

针对 RDB 不适合实时持久化，redis 提供了 AOF 持久化方式来解决
开启： redis.conf 设置：appendonly yes (默认不开启，为 no)
默认文件名： appendfilename “appendonly.aof”
流程说明：

• 1，所有的写入命令(set hset)会 append 追加到 aof_buf 缓冲区中
• 2，AOF 缓冲区向硬盘做 sync 同步
• 3，随着 AOF 文件越来越大，需定期对 AOF 文件 rewrite 重写，达到压缩
• 4，当 redis 服务重启，可 load 加载 AOF 文件进行恢复

AOF持久化流程： 命令写入(append),文件同步(sync),文件重写(rewrite),重启加载(load)

redis 的 AOF 配置详解：

appendonly yes //启用 aof 持久化方式
# appendfsync always //每收到写命令就立即强制写入磁盘，最慢的，但是保证完全 的持久化，不推荐使用
appendfsync everysec //每秒强制写入磁盘一次，性能和持久化方面做了折中，推荐 
# appendfsync no //完全依赖 os，性能最好,持久化没保证（操作系统自身的同步） no-appendfsync-on-rewrite yes //正在导出 rdb 快照的过程中,要不要停止同步 aof auto-aof-rewrite-percentage 100 //aof 文件大小比起上次重写时的大小,增长率 100%时,重写 auto-aof-rewrite-min-size 64mb //aof 文件,至少超过 64M 时,重写

如何从 AOF 恢复？

1. 设置 appendonly yes；
2. 将 appendonly.aof 放到 dir 参数指定的目录；
3. 启动 Redis，Redis 会自动加载 appendonly.aof 文件。

redis 重启时恢复加载 AOF 与 RDB 顺序及流程：

1. 当 AOF 和 RDB 文件同时存在时，优先加载
2. 若关闭了 AOF，加载 RDB 文件
3. 加载 AOF/RDB 成功，redis 重启成功
4. AOF/RDB 存在错误，redis 启动失败并打印错误信息