Redis

1、介绍

2、安装

Redis官方推荐使用的是Linux系统进行安装（win的Redis版本低，也没有维护了）所以这里是Linux的教程，Redis安装有几种，如宝塔面板（服务器）、手动按照等等。

手动安装

1）下载tar包

到官网进行下载

2）上传文件

把下载好的文件上传到Linux系统里（本身是Linux系统忽略本小结步骤直接看3）），可以使用xftp上传
注：建议把文件上传到/usr/local/redis，因为usr目录主要是存放应用程序和文件的目录

3）解压和安装

输入命令：

1. cd …/usr/local/redis（进入到usr/local/redis就对了）

2. tar -zxvf redis-6.0.3.tar.gz（解压，解压完成用ls命令查看，如下就是完成）

   

3. cd redis-6.0.3（进入redis目录）

4. yum -y install gcc-c++ （安装gcc）

   注意点：redis6.0以上需要升级gcc到5.3及以上，命令如下

   yum -y install centos-release-scl
   yum -y install devtoolset-9-gcc devtoolset-9-gcc-c++ devtoolset-9-binutils
   scl enable devtoolset-9 bash
   需要注意的是scl命令启用只是临时的，退出shell或重启就会恢复原系统gcc版本。
   如果要长期使用gcc 9.3的话：

   echo “source /opt/rh/devtoolset-9/enable” >>/etc/profile
   这样退出shell重新打开就是新版的gcc了

5. make （编译解压好的redis文件）

   拓展：

   编译出错时，清出编译生成的文件

   make distclean

   编译安装到指定目录下

   make PREFIX=/usr/local/redis install

   卸载

   make uninstal

6. make install （进行redis安装）

   

4）修改默认配置

偷懒方法：

1. 打开xftp

2. 复制/usr/local/redis/redis-6.0.3/redis.conf

3. 粘贴到sr/local/bin/myconf里（myconf就自己创建）

4. 然后双击myconf目录下的redis.conf修改内容，内容如下

   

命令方法：

会Linux的都应该知道怎么做了，效果和上面一样就行

5）测试

1. redis-server myconf/redis.conf（通过myconf/redis.conf的配置文件来启动redis-server）

2. redis-cli -p 6379（启动客户端，通过ip：localhost 端口：6379连接）

   ps: redis-cil --cluster create ip1:端口 ip2:端口 ip3:端口 …–cluster-replicas 1 客户端连接集群，后面课程

   指令选项详细点这里

3. ping（发送ping请求，回复PONG就是完成了）

   shutdwon （关闭redis服务端）

   quit或者exit（提出redis客户端）

4. http://c.biancheng.net/view/4507.html spring配置 https://docs.spring.io/spring-data/redis/docs/2.3.0.RELEASE/reference/html/#reference 官网

3、命令

1）基本命令

2）基本数据类型命令

3）特殊数据类型命令

geospatial：将指定的地理空间位置（纬度、经度、名称）添加到指定的key中，可以推算地理位置的信息，两地之间的距离，方圆几里的人，geo底层是zset集合（sortedset），注：无法添加两级

HyperLogLog：是一种算法，它提供了不精确的去重计数方案，优秀大佬博客

Bitmap：位存储，使用场景：打卡、活跃度、登入状态等等，只要0和1能表示的就行，只能存储0或1的值

4）集群

4、事务

1）事务

Redis单条命令是保存原子性的，但是事务不保证原子性且没有隔离级别的，Redis没有隔离级别（隔离性）

Redis事务本质：一组命令的集合，会按照先后顺序执行（队列），执行过程中是不会被干扰（其他客户端提交的命令请求不会插入到事务执行命令序列中）

事务执行过程：
开启事务（multi）命令后就会生成一个队列缓存，把我们接下来的命令进行存储（不执行），只有当执行事务（exec）命令时才开始执行。未执行事务时是可以放弃该次事务（discard）的

事务编译型异常：
代码有问题或命令有问题（类似于java编译性错误），在执行（exec）命令时所有存储的命令是不会执行的（也可以说是放弃掉）

事务运行时异常：
代码和命令没问题，但是存在逻辑不合法（语法性、命令性）问题，事务执行时只会放弃出问题的命令，其它的命令依然执行
如：在一个key里存储字符串，然后开启事务后让这个key自增加1（incr命令），虽然不会有报错但是语法却是不合法的，所有执行事务时这条命令会被放弃，其它的正常命令则正常执行

2）监控

在事务开启前监控要监控的目标，确保目标在事务完成过程中数据的一致性，如果目标被改变了则执行事务时执行失败

悲观锁：
介绍：很悲观，无论什么时候都会枷锁

乐观锁：
介绍：很乐观认为不会出错所以不上锁，只对数据更新时做一下比较，查看是否被修改过

场景：当一个线程在进行事务操作时，如果加了监控的key被其它线程改变了数据，则执行事务时就执行失败，注：再次监控，需要先解锁

5、配置

redis.conf的配置文件详解

6、持久化

Redis提供了将内存数据持久化到硬盘，以及用持久化文件来恢复数据库数据的功能。Redis 支持两种形式的持久化，一种是RDB快照（snapshotting），另外一种是AOF（append-only-file）

1）rdb

RDB：是Redis用来进行持久化的一种方式，只要满足快照的策略就把当前内存中的数据集写入磁盘（生成dump.rdb文件）

快照：策略内容就是指定时间内，key变化次数大于次数，就进行持久化保存，策略配置只需要修改redis.conf文件里的save属性即可

触发RDB方式：

1. 快照策略触发
2. save命令持久化（阻塞当前Redis服务器直到RDB过程完成为止）
3. bgsave命令持久化（RDB持久化过程由Redis服务器子进程负责）
4. flushall命令（也会产生dump.rdb但是是空的，因为命令清空数据库）
5. 正常退出

数据恢复：将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可，redis就会自动加载文件数据至内存了。Redis 服务器在载入 RDB 文件期间，会一直处于阻塞状态，直到载入工作完成为止。

数据丢失：如在已经满足save 60 1000快照条件下59秒时突然宕机，数据还没有持久化就不见了，就是数据丢失

注意点：当配合aof一起使用时，重启redis只会读取aof日志文件

RDB优点：

• 适合大规模的数据恢复
• 对数据的完整性要求不高
• RDB数据恢复的速度比 AOF要快
• 持久化工作是交给子进程进行的

RDB缺点：

• fork子进程时，会占用一定的内存空间和时间间隔（执行fork操作创建子进程，属于重量级操作，不采用压缩算法内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑，频繁执行成本过高影响性能）
• 老版本Redis服务无法兼容新版RDB格式的问题(版本不兼容)
• 在一定间隔时间做一次备份，如果意外宕机，会丢失最后一次快照后的所有修改

2）aof

AOF：aof持久化以日志的形式记录服务器所处理的每一个写和删除操作，但不记录查询操作，以文本的方式记录，可以打开文件看到详细的操作记录。生成的文件是appednonly.aof

AOF策略：aof持久化的记录策略，修改redis.conf里appendfsync属性实现

• appendfsync always
  每次有数据修改发生时都会写入AOF文件。
• appendfsync everysec
  每秒钟同步一次，该策略为AOF的缺省策略。
• appendfsync no
  从不同步。高效但是数据不会被持久化。

修复：redis通过了一个修复appednonly.aof文件的工具（redis-check-aof --fix命令），也就是说aof文件启动不了或错误时，可以通恢复进行修复

数据恢复：如果aof文件正常，启动时就会自动恢复

重写规则：如果aof文件大于指定的文件大小（默认64mb），就会就会fork新的进程来对文件进行重写（追加文件）（了解即可）

AOF优点：

• aop机制可以带来更高的数据安全性（看策略）
• 写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容
• 日志文件记录清晰、易于理解

AOF缺点：

• AOF持久化文件通常要大于RDB文件，数据恢复和修复速度慢
• AOF在运行效率上往往会慢于RDB（机制问题）

3）混合持久化

redis4.x后才出现，当aof和rdb都开启时，aof触发重写条件就会对aof进行重写，而重写使用了混合持久化方法

混合持久化：先清空当前aof文件，然后对进行一次rdb然后存入到aof文件里，最后aof文件继续记录后续的写操作

触发条件：
（一）没有BGSAVE命令（RDB持久化）/AOF持久化在执行（要求）
（二）没有BGREWRITEAOF在进行（要求）
（三）AOF文件大于server.aof_rewrite_min_size（默认为1MB）（触发机制）
（四）当前AOF文件和旧AOF文件之间大小的比率大于或等于指定比例（默认100%）（触发机制）

7、发布订阅

Redis 发布订阅(pub/sub)是一种消息通信模式：发送者(pub)发送消息，订阅者(sub)接收消息。发布者发布一条信息，所有的订阅者都会接受到（如：微信公众号，关注动态等等），优秀大佬博客

原理结构图：

pubsub_channels是一个字典（存储频道的字典），channel是频道、client是订阅者

当调用SUBSCRIBE命令时，如下粉色框新填的发布者

订阅 命令就很好理解，先在字典里遍历所有订阅频道，找到后直接把消息发给订阅者们

取消订阅命令，先在字典里遍历所有订阅频道，在把自己从频道抹去

8、主从复制

Redis虽然读取写入的速度都特别快，但是也会产生读压力特别大的情况。为了分担读压力，Redis支持主从复制，Redis的主从结构可以采用一主多从或者级联结构。
简单的说，就是将一台redis服务器的数据，复制到其它服务器。前者是主节点（master/leader），后者为从节点（slave/follower）；***数据的复制是单向的，只能由主节点到从节点。主节点以写为主，从节点只能读***，这样子可以实现负载均衡

全量同步：第一次接受同步请求，在Slave初始化阶段时Slave将Master上的所有数据都复制一份的动作
增量同步：是指Slave初始化完毕后开始正常工作时主服务器发生的***写操作同步到从服务器的动作***（写操作同步是指【主服务器】每执行一个写命令就向【从服务器】发送一个一样的命令并让其执行）

主：命令式的主从复制是暂时性的，重启就没有了，永久性的要修改配置文件

主从复制的作用：

• 高可用（集群）基石

  主从复制是哨兵模式和集群实施的基础

• 负载均衡

  配合读写分离，从节点负责读，主节点负责写

• 故障恢复

  主节点出故障，可以由从节点提供服务，实现快速修复，实际上是一种服务的冗余（因为全量复制）

哨兵模式：
没有哨兵模式前，主节点宕机了，从节点可以使用slaveof no one命令把自己当做主节点，但主节点恢复后，从节点还认为自己是主节点（除非再次服从），简单来说就类似于谋朝篡位，这种人工干预方式费时费力，所有redis2.8后出现了Sentinel（哨兵模式）

哨兵模式出现后，如果主节点故障，哨兵1检测到这个结果并不会直接进行failover（故障转移）而是认为服务器不可用（这种现象称为主观下线），只有哨兵（其它哨兵也出现主观下线）数量达到一定值，自动的在从节点里海选（海选过程每个哨兵随机投票，票多胜出）出新的主节点并进行failover（故障转移），切换成功后通过发布订阅模式，让各个哨兵把自己监控的从服务器切换到新的主服务器（这个过程称为客观下线）

注：（1）因为哨兵也可能故障所有需要多哨兵模式相互监控 （2）如果出故障的主节点恢复了，只能当从节点

创建：

配置哨兵配置文件sentinel.conf

# port 7505
# <master-name> <ip> <port> 监控的主节点的名字、IP和端口
# <count> 设置主观下线达到多少数量，才进行客观下线

常用命令：

9、缓存穿透和雪崩

1）缓存穿透

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

解决方法：

1. 布隆过滤器
2. 缓存空对象

2）缓存击穿

缓存击穿，是指一个key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，就像在一个屏障上凿开了一个洞

解决方法：

1. 分布式锁（互斥锁）

3）缓存雪崩

缓存因为断电、宕机等等导致缓存数据全部丢失引起一系列的问题就是雪崩

解决方法：

1. 限流降级（服务降级、服务限流）
2. 数据预热（提前加载数据）

Redis 回顾

1、工作流程

上图是redis在服务器的大致工作流程（还没用对redis进行细节规划）

使用和不使用io thread下的redis工作流程，ps：io thread是Reid4.x之后才有，需要手动开启

2、为什么选reids

redis：（1）不需要手写算法、序列化 （2）redis因为只有一条工作线程的原因保证了一致性 （3）redis的类型丰富可以根据不从场景选择最佳存储方案 （4）命令和api基本一致

3、数据结构图

sortedset

当存储的value较小时底层使用ziplist结构，较大时使用skiplist（下图就是skiplist结构图，ps：x是值）

4、单机问题

然后的单机服务器都会存在两个问题，单点故障****和压力过大/性能不高**

单点故障解决方法：主从复制（也叫全量集群或主备集群）
压力/性能解决方法：分区扩容（如把原本1t的数据，分为4分扩容到其它服务器，其实也是集群的一种），再给每个分区做主从复制（否则分区出现单点故障）

区别：单点故障（数据是全量拷贝），压力/性能（部分拷贝）

** spring boot 使用参考https://blog.csdn.net/qq_27790011/article/details/98344732**