Redis

初识Redis

docker ``exec` `-it docker-redis ``/bin/bash

Linux安装Redis

1. 官网下载Redis

2. 解压Redis安装包 程序放到opt下面

3. tar -zxvf 安装包

4. 进入解压后的文件

5. 安装基本的环境配置

   yum install gcc-c++
   
   make
   
   make install
   

6. redis 默认安装路径是usr/local/bin

7. redis默认不是后台启动；修改Redis配置文件

8. 启动Redis服务

9. 通过制定的配置文件启动服务redis-server redis.conf

10. 连接Redis服务;;
    使用Redis-cli进行连接测试
    

11. 查看Redis进程是否开启

    ps -ef | frep redis

12. 关闭Redis服务 shutdown exit；

Redis压力测试

测试100个并发连接，100000个请求

  redis-benchmark -h localhost -p 6379 -c 100 -n 10000

)]

压力测试结果

Redis基本知识说明

默认16个库

默认有16个数据库,从配置文件中可以得到，默认使用的第0个数据库

通过select 0来切换数据库

#切换数据库
select 3   

#查看db大小
DBSIZE

#查看数据库所有的key
keys *

#清除当前数据库
flushdb

#清除全部数据库内容
flushall

在docker中操作Redis

#输出docker日志
[root@hecs-x-medium-2-linux-20200921093101 home]# docker logs mydocker

#在容器中运行Redis CLI
#接着我们通过在容器中运行 redis-cli 来连接 redis 服务。我们将在运行中的容器中用 -it 选项来启动一个新的交互式会话，并使用它来运行 redis-cli：
docker exec -it docker-redis /bin/bash

#运行redis-cli
root@517350f4f2bb:/data# redis-cli

redis是单线程 的

明白Redis是很快的，官方表示Redis是基于内存操作，CPU不是Redis的性能操作的瓶颈，Redis的瓶颈是根据机器中的内存和网络带宽，既然可以使用单线程实现，就用单线程了。所以就是用了单线程了。

Redis为什么单线程还那么快？

Redis是C语言写的

1、误区1：很多人认为高性能的服务器一定是多线程的！

2、误区2：多线程（CPU上下文会切换）一定比单线程效率高！

核心：Redis是将所有的数据都放到了内存中，所以用单线程操作效率高，多线程（上下文切换：耗时的操作）,对于内存系统来说，如果没有上下文切换，效率就是最高的！多次读写都是在一个CPU上面操作的。在内存的情况下，这就是最佳的操作。

五大基本数据类型

说明

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-key

# set  key
set name xixin

#判断当前的key是否存在
EXISTS key

#移除当前的key
move key

#设置key 的过期时间，时间是秒
EXPIRE KEY 10(秒)

#查看当前key的剩余时间
TTL key

#储存一个key
SET key value

#获取一个key
GET key 

#查看key的类型
TYPE key

String(字符串)

#追加字符串 如果当前可以不存在，
#相当于set key
APPEND key  "值" 

#获取字符串长度
STRLEN key

#自增 1   比如设置浏览量，一些不是持久化的数据
INCR key 

#自减  1
DECR key

#设置步长，指定增量
INCRBY  KEY  length

#设置步长，指定减量
DECRBY  KEY   length

# range 范围

#截取字符串[0,3]
GETRANGE KEY 0 3 

#获取全部的字符串,和get key的效果是一样的
GETRANGE KEY 0 -1 

# 替换指定位置开始字符串
SETRANGE KEY 1 XXX 

#setex (set with excpire) 设置过期时间
#setnx (set if not excpire) 不存在设置（在分布式锁中会常常使用）

#设置key的值为 hello 30秒后过期
SETEX key 30 "hello" 

#如果mykey  不存在则创建  mykey 如果存在，则创建失败
SETNX mykey "redis"

MSET 
MGET
#同时设置多个值
MSET k1 v1 k2 v2 k3 v3

#同时获取多个值
MGET k1 k2 k3

#mestx是一个原子性操作。要么一起成功，要么一起失败
MESTX k1 v1 k4 v4


#对象

#设置一个user:1对象 值为json字符来保存一个对象！！
SET user:1{name :zhangsan,age:3}

#这里的一个key是一个巧妙的设计 user:{id}:{filed} 如此设计在Redis中是完全OK的

#储存一个值
MSET user:1:name zhangsna user:1:age 3

#GETSET

#先获取key的value如果不存在则返回nil ；；
#如果存在，获取原来的值，并设置新的值
GETSET key value

数据结构是想通的

String类似的使用场景：value除了可以是字符，还可以是我们的数字

• 计数器
• 统计多单位的数量
• 粉丝数
• 对象缓存存储

List（列表）

在Redis中，我们可以吧list玩成栈、队列、阻塞队列

所有的list命令都是以l开头的、

Redis不区分大小写

#讲一个值或多个值，插入到列表头部（左）
LPUSH list one

#获取list中的值
LRANGE list 0 -1

#通过区间获取具体的值
LRANGE list 0 1

#将一个值或者多个值插入到列表的尾部(右)
RPUSH list four


#移除列表的第一个元素
LPOP list 

#移除列表的最后一个元素
RPOP list

#通过下标获取值  Lindex
LINDEX KEY 0
LINDEX KEY 0

#获取list集合的长度
Llen key

# Lrem 移除list集合中指定个数的value，精确匹配
Lrem key number "值"

#Ltrim 通过下标截取指定的长度，这个list已经被改变了，只剩下了截取的元素
Ltrim key 1 2

#rpoplpush移除列表最后一个元素，将他移动到新的列表中
#将值从原有的列表中移除，添加到新的列表中，剪切 粘贴
rpoplpush key NewKey

#Lset  将列表中指定下标的值替换为另外一个值；更新操作
#判断这个列表的值是否存在
EXISTS key 
#如果存在，更新当前下标的值；如果不存在，则会报错；
LSET key index value

#Linsert将某个具体的value插入插入到列表中某个元素的前面或者后面
Linsert key before/after oldValue newValue

小结

• 他实际上是一个链表，before node after left right 都可以插入值
• 如果key不存在，创建新的链表
• 如果key存在，新增内容
• 如果移除了所有值，空链表，也代表不存在
• 在两边插入或者改动值，效率最高！中间元素，相对来说效率会低一点

消息队列（Lpush Rpop)栈（Lpush Lpop)

消息队列，从左边进去，从右边拿出去

栈：从那边进，就从那边出去

Set（集合）

set中的值不能够重复

无序不重复集合

#向set集合中添加一个值
sadd key value

#查看set中指定的值
SMEMBERS key 

#判断某一个元素是不是在set集合中
SISMEMBER key value

#获取set集合中的内容元素个数
SCARD key

#移除set集合中的指定元素
SREM key value

#随机抽取一个元素
SRANDMEMBER key 

#随机抽取出指定个数的元素
SRANDMEMBER key number

#随机删除一个set集合中的元素
SPOP key

#将一个set中的元素移到另一个set集合中
SMOVE oldKey newKey value

#差集
SDIFF key1 key2

#并集
SINTER key1 key2

#交集
SUNION key1 key2

Hash

Map集合，key—map 时候、这是一个map集合，本质和String类型没有太大的区别；还是一个简单的key-value

set Myhash field xinaxin

#set 一个字段值key-value
hset key field value

#同时set多个key-value
hmset key field1 value1 field2 value2

#获取多个字段值
hmget key field1 field2

#获取全部的数据(展示方式：key :  value  方式)
hgetall key

#删除hash指定的field  对应的value 值也就没有了
hdel key field

#获取这个hash表的字段数量
hlen key

#判断hash中指定字段是否存在
hexists key field

#只获得所有的field
hkeys key

#只获得所有的value
hvals key

#指定增量
hset key field3 number
HINCRBY key field3 number

#如果不存在则可以设置
hsetnx key field4 value

#如果存在则不可以设置
hsetnx key field4 value

hash变更数据 user name age，尤其是用户信息之类的，经常变动的信息！hash更适合与对象的存储，String更加适合字符串的存储；

Zset（有序集合）

在set的集合基础之上，增加了一个值；set k1 v1 zset k1 score1 v1

#添加一个值
zadd key score1 value

#添加多个值
zadd key score2 v2 score3 v3

#查看所有的值
zrange key 0 -1

#实现排序

#从小到大排序，显示所有的用户
ZRANGEBYSCORE key -inf +inf 

#从小到大排序，显示所有的用户以及薪资
ZRANGEBYSCORE key -inf +inf WITHSCORES

#从小到大排序，显示薪资小于2500部分用户的信息
ZRANGEBYSCORE key -inf 500 WIDTHSCORES

#从大到小进行排序
ZREVRANGE key 0 -1

#移除有序集合中的指定元素
zrem key value

#获取有序集合中的个数
zcard key

#获取指定区间的成员数量
acount key scores1 scores2

案例思路：set 排序 储存班级成绩表，工资排序表

【普通消息，重要消息，带权重进行判断

排行榜应用实现，取Top N 测试

三种特殊数据类型

geospatial

goadd

#geoadd  添加地理位置
#规则：两极无法直接添加，我们一般会下载城市数据，通过java程序一次性导入
#参数  key 值（经度、纬度、名称）
#有效的经度从 -180度到180度
#有效的纬度从-85.05112878度到85.05112878度
#当坐标位置超出上述范围是，该命令将会返回一个错误
geoadd china:city 经度  纬度 城市名

getpso

#获取指定城市的经度和纬度
GEOPOS china:city beijing

#获取多个城市的经度和纬度
GEOPOS china:city beijing shanghai

GEODIST

两人之间的距离

单位

• m表示单位为米
• km表示单位为千米
• mi表示单位为英里
• ft表示单位为英尺

#计算两个城市之间的距离
GEODIST china:city beijing shanghai km

GEORADIUS:以给定的经纬度为中心，找出某一半径内的元素

所有的数据都应该录入到China：city中才会让结果更加清晰准确

#以已知经纬度为中心，获取某半径内的城市信息 以110,30为例
GEORADIUS china:city 110 30 1000Km

#显示到中心的位置
GEORADIUS chian:city 110 30 50Km withdist

#显示城市的经度纬度(显示他人的定位信息)
GEORADIUS China:city 110 30 500km withcoord

#筛选出指定的结果
GEORADIUS China:city 110 30 500km withdist withcoord count 1

GEORANDIUSBYMEMBER

#找出位于指定元素周围的其他元素！！！
GEORADIUSBYMEMBER china:city beijing 1000 km

GEO底层实现原理其实就是Zset！我们可以使用Zset命令来操作geo

#移除指定的元素
zrem china:city beijing 

#查看地图中全部元素
ZRANGE china:xity 0 -1

hyperloglog

简介

Redis 2.8.9版本就更新了Hyperloglog 数据结构!
Redis Hyperloglog基数统计的算法!
优点:占用的内存是固定, 2^64不同的元素的技术,只需要废12KB内存!如果要从内存角度来比较的话Hyperloglog首选!

网页的UV (一个人访问一个网站多次,但是还是算作-个人! )
传统的方式，set 保存用户的id ,然后就可以统计set中的元素数量作为标准判断!
这个方式如果保存大量的用户id ,就会比较麻烦!我们的目的是为了计数,而不是保存用户id ;
0.81%错误率!统计UV任务,可以忽略不计的!

测试使用

127. 0.0.1:6379> PFadd mykey a b c d e f g h i j
#创建第一组元素mykey
(integer) 1
127.0.0.1:6379> PFCOUNT mykey # 统计mykey元素的基数数量
(integer) 10
127.0.0.1:6379> PFadd mykey2 i j z x c v b n m
#创建第二组元素mykey2
(integer) 1
127.0.0.1:6379> PFCOUNT mykey2
(integer) 9 
127.0.0.1:6379> PFMERGE mykey3 mykey mykey2 # 合并两组mykey mykey2 => mykey3 并集
OK
127.0.0.1:6379> PFCOUNT mykey3 # 看并集的数量!
(integer) 15

如果允许容错，那么一定可以使用hyperloglog；

如果不允许容错，那么就使用set数据类型即可；

Bitmap

位储存

统计用户信息,活跃,不活跃!登录、未登录!打卡, 365打卡!两个状态的,都可以使用Bitmaps !
Bitmaps位图,数据结构!都是操作二进制位来进行记录,就只有0和1两个状态!
365天= 365 bit 1字节=8bit 46 个字节左右!

测试

#储存值
setbit key 0 1

#取值
getbit key 6

#统计操作
bitcount key 

事务

Redis事务本质：一组命令的集合！一个事务中所有命令都会被序列化，在事务执行过程中，会按照顺序进行执行！

一致性、顺序性、排他性！1执行一些命令

------队列 set  set  set 执行------

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

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

Redis的事务：

• 开启事务（multi）
• 命令入队（…）
• 执行事务（exec）

正常执行事务

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

放弃事务

#开启事务
multi

#消息队列
set

#取消事务
DISCARD

#取消事务之后，事务队列中的命令都不会被执行

编译型异常（代码有问题！命令有错！！）事务中所有的命令都不会被执行！

运行时异常（1/0） 如果事务队列中存在语法性错误，那么执行命令的时候，其他命令是可以正常执行的，错误命令被抛出异常

悲观锁

• 很悲观，认为什么时候都会出问题，无论做什么都会加锁！

乐观锁

• 很乐观，认为什么时候都不会出问题，所以不会 上锁！更新数据的时候去判断一下，再此期间是否有人修改过这个数据
• 获取version
• 跟新的时候比较一下version

redis监控测试

正常执行成功

127.0.0.1:6379> set money 100
OK
127.0.0.1:6379> set out (
OK
127.0.0.1 :6379> watch money#监视money对象
OK
127.0.0.1:6379> mu1ti #事务正常结束，数据期间没有发生变动，这个时候就正常执行成功!
OK
127.0.0.1:6379> DECRBY money 20
QUEUED
127.0.0.1:6379> INCRBY out 20
QUEUED
127.0.0.1:6379> exec 
1) (integer) 80
2) (integer) 20

测试多线程修改值，使用watch可以当做Redis的乐观锁；

在执行之前，如果另外一个线程修改了我们的值，这个时候，就会导致事务执行失败

如果修改失败，获取最新的值就好

• 如果发现事务执行失败，就先解锁
• 获取最新的值，再此监视，select version
• 对比监视的值是否发生了变化，如果没有发生变化，那么可以执行成功，如果变化就执行失败；

Jedis

我们要使用java来操作Redis

什么是Je推荐的Java连接开发工具dis 是Redis官方提供的java连接工具！使用java操作radish中间件！如果使用java操作Redis；那么一定要对Jedis十分熟悉

测试

1、导入对应的依赖

<!-- https://mvnrepository.com/artifact/redis.clients/jedis -->
        <dependency>
            <groupId>redis.clients</groupId>
            <artifactId>jedis</artifactId>
            <version>3.3.0</version>
        </dependency>
        <dependency>
            <groupId>com.alibaba</groupId>
            <artifactId>fastjson</artifactId>
            <version>1.2.58</version>
        </dependency>

2、编码测试

• 连接数据库
• 操作命令
• 断开连接

public class JedisPing {
    public static void main(String[] args) {
        Jedis jedis = new Jedis("192.168.80.128",6379);
        System.out.println(jedis.ping());
    }
}

//输出PONG则连接成功

事务

Jedis jedis = new Jedis("192.168.80.128",6379);

        jedis.flushDB();

        JSONObject jsonObject = new JSONObject();
        jsonObject.put("hello","world");
        jsonObject.put("name","xin");
        String res = jsonObject.toString();
        /*开启事务*/
        Transaction multi = jedis.multi();
        try {
            multi.set("us1",res);
            multi.set("us2",res);
            multi.exec();//执行事务
        } catch (Exception e) {
            e.printStackTrace();
            multi.discard();//放弃事务
        } finally {
            System.out.println(jedis.get("us1"));
            System.out.println(jedis.get("us2"));
            System.out.println(jedis.flushDB());
            multi.close();//关闭事务
        }

Spring Boot整合

SpringBoot操作数据: spring-data jpa jdbc mongodb redis !

SpringData也是和SpringBoot齐名的项目!

说明:在SpringBoot2.x之后,原来使用的jedis被替换为了lettuce?

jedis :采用的直连,多个线程操作的话,是不安全的,如果想要避免不安全的,使用jedis pool 连接池!更像BIO 模式

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

application.properties

# SpringBoot所有的配置类，都有一个自动配置类  RedisAutoConfiguration
# 共自动配置类都会绑定一个 properties;配置文件 RedisProperties
spring.redis.host=192.168.80.128
spring.redis.database=1

链接测试

 @Autowired
    private RedisTemplate redisTemplate;

    @Test
    void contextLoads() {
        // redisTemplate操作不同的数据类型， api和我们的指令是一样的
        // opsForValue操作字符串 类似String
        // opsForlist 操作List类似ist
        // opsForSet
        // opsForHash
        // opsForZSet
        // opsForGeo
        // opsForHyperLogLog
        // 除了进本的操作，我们常用的方法都可以直接通过redisTemplate操作， 比如事务，和基本的CRUD

        redisTemplate.opsForValue().set("name","1123");
        System.out.println(redisTemplate.opsForValue().get("name"));
        //获取redis的链接对象
        RedisConnection connection = redisTemplate.getConnectionFactory().getConnection();
        connection.flushAll();
    }

序列化

在所有的企业中，pojo中的类都会被序列化；

@Component
@AllArgsConstructor
@NoArgsConstructor
@Data

//固定的模板，可以直接拿去使用
    //自定义一个Template
    @Bean
    @SuppressWarnings("all")
    public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory redisConnectionFactory) throws UnknownHostException {
        //我们为了开发方便，一般直接使用<string,Object>
        RedisTemplate<String, Object> template = new RedisTemplate();
        template.setConnectionFactory(redisConnectionFactory);

        //josn序列化
        Jackson2JsonRedisSerializer jackson2JsonRedisserializer = new Jackson2JsonRedisSerializer(java.lang.Object.class);
        ObjectMapper mapper = new ObjectMapper();
        mapper.setVisibility(PropertyAccessor.ALL, JsonAutoDetect.Visibility.ANY);
        mapper.enableDefaultTyping(ObjectMapper.DefaultTyping.NON_FINAL);
        jackson2JsonRedisserializer.setObjectMapper(mapper);

        //string序列化
        StringRedisSerializer stringRedisSerializer = new StringRedisSerializer();

        // key采用string的序列化方式
        template . setKeySerializer(stringRedisSerializer);
        // hash 的key也采来用string的序列化方式
        template . setHashKeySerializer(stringRedisSerializer);
        // value序列化方式采用jackson
        template . setValueSerializer(jackson2JsonRedisserializer);
        // hash的value序列化方式采用jackson
        template. setHashValueSerializer(jackson2JsonRedisserializer);
        template. afterPropertiesSet();

        return template;
    }

Redis.conf详解

单位

配置文件unit单位对大小写不敏感

包含

就好比我们spring中的import、include；可以导入外置的配置文件

网络

bind 192.168.80.128  #绑定的IP

protected-model yes  #保护模式

port 6379    #端口

通用 General

daemonize yes   #以守护进程的方式运行，默认是no，我们需要自己开启为yes

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

#日志
# specify the server verbosity leve1.
# This can be one of:
# debug (a 1ot of information, usefu1 for development/testing)
# verbose (many rarely useful info, but not a mess 1ike the debug 1eve1)
# notice(moderately verbose， what you want in production probab1y)  生产环境
# warning (on1y very important / critical messages are 1ogged)
1ogleve1 notice


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

databases 16  #默认数据库的数量

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

快照 SNAPSHOTTING

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

redis是内存数据库，如果没有持久化，那么数据断电即失；

#如果900s内， 如果至少有一个1 key进行了修改， 我们及进行持久化操作
save 900 1
#如果300s内，如果至少10 key进行了修改，我们及进行持久化操作
save 300 10
#如果60s内，如果至少10000 key进行 了修改，我们及进行持久化操作
save 60 10000
#我们之后学习持久化，会自己定义这个测试!


stop-wri tes -on-bgsave-error yes   #持久化如果出错，是否还需要继续工作!

rdbcompression yes #是否压缩rdb 文件，需要消耗- - 些cpu资源! 

rdbchecksum yes #保存rdb文件的时候，进行错误的检查校验!

dir ./ # rdb文件保存的目录!

SECURITY 安全

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

#设置密码
config set requirepass "123456"

#获取密码
config get requirepass

#登录验证密码
ping
auth 123456

限制 CLIENTS

maxclients 10000#设置能连接上redis的最大客户端的数量

maxmemory <bytes> # redis 配置最大的内存容量

maxmemory-policy noeviction # 内存到达上限之后的处理策略

    1、volatile-1ru: 只对设置了过期时间的key进行LRU (默认值)
    2、a11keys-1ru :删除1ru算法的key
    3、volatile-random: 随机删除即将过期key
    4、a11keys-random:随机删除
    5、volatile-tt1 :删除即将 过期的
    6、noeviction :永不过期，返回错误

APPEND ONLY 模式 aof配置

appendonly no  #默认是不开启aof模式的，默认是使用rdb方式持久化的，在大部分所有的情况下，rdb完全够用! 
appendfilename "appendonly.aof" # 持久化的文件的名字

# appendfsync always 	#每次修改都会sync。消耗性能

  appendfsync everysec	#每秒执行一次sync，可能会丢失这1s的数据!

# appendfsync no	#不执行sync,这个时候操作系统自己同步数据，速度最快!

Redis持久化

redis是内存数据库，如果不将内存中的数据库状态保存到磁盘中，那么一旦服务器进程退出，服务器中的数据库状态也会消失。所以Redis提供了持久化功能；

RDB(Redis DataBase)

什么是RDB

在指定的时间间隔内将内存中的数据集快照写入磁盘,也就是行话讲的Snapshot快照,它恢复时是将快照文件直接读到内存里。
Redis会单独创建( fork ) -个子进程来进行持久化,会先将数据写入到一-个临时文件中,待持久化过程都结束了, 再用这个临时文
件替换上次持久化好的文件。整个过程中, 主进程是不进行任何I0操作的。这就确保了极高的性能。如果需要进行大规模数据的恢
复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效。RDB的缺点是最后- -次持久化后的数据可能丢
失。我们默认的就是RDB , -般情况下不需要修改这个配置!

有时候在生产环境我们会将这个文件进行备份!

rdb保存的文件是dump.rdb都是在我们的配置文件中快照中进行配置的!

触发机制

1、save的规则满足的情况下,会自动触发rdb规则

2、执行flushall命令,也会触发我们的rdb规则!

3、退出redis ,也会产生rdb文件!

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

如何恢复rdb文件！

1、只需要将rdb文件放在我们redis启动目录就可以, redis启动的时候会自动检查dump.rdb恢复其中的数据!

2、查看需要存在的位置

127.0.0.1:6379> config get dir
1) "di r"
2) "/usr/1oca1/bin" # 如果在这个目录下存在dump.rdb 文件，启动就会自动恢复其中的数据

几乎就他自己的配置就够用了，但是我们还是需要去学习

优点

1. 适合大规模的数据恢复！
2. 对数据的完整性要求不高！

缺点

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

AOF(Append Only File)

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

是什么

以日志的形式来记录每个写操作,将Redis执行过的所有指令记录下来(读操作不记录) , 只

许追加文件但不可以改写文件, redis启动之初会读取该文件重新构建数据,换言之, redis

重启的话就根据日志文件的内容将写指令从前到后执行一-次以完成数据的恢复

工作

AOF保存的是appendonly.aof文件

appernd

默认是不开启的，我们需要手动进行配置!我们只需要将appendonly改为yes就开启了aof !

重启, redis就可以生效了!

如果这个aof文件有错位,这时候redis 是启动不起来的吗,我们需要修复这个aof文件

redis给我们提供了一个工具redis-check-aof --fix

如果文件正常，则重启就可以恢复了

重写规则说明

Aof默认就是文件无限追加；

如果aof文件大于64M，太大了fork一个新的进程来将我们的文件进行重写！

优点

1. 每一次修改都同步，让文件的完整性更加的好
2. 每秒同步一次，就可能会丢失一秒的数据
3. 从不同步，效率最高

缺点

1. 相对于数据文件来说，aof远远大于rdb，修复的速度也比rdb慢
2. Aof运行效率也要比aof慢，所以我们Redis默认的配置就是rdb持久化

扩展

1、RDB 持久化方式能够在指定的时间间隔内对你的数据进行快照存储

2、AOF 持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命

令来恢复原始的数据, AOF命令以Redis协

议追加保存每次写的操作到文件末尾, Redis还能对AOF文件进行后台重写,使得AOF文件

的体积不至于过大。

3、只做缓存,如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久

化

4、同时开启两种持久化方式

●在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情

况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。

●RDB的数据不实时,同时使用两者时服务器重启也只会找AOF文件，那要不要只使用AOF

呢?作者建议不要，因为RDB更适合用于备份数据库( AOF在不断变化不好备份) ,快速重

启,而且不会有AOF可能潜在的Bug ,留着作为- -个万一-的手段。

5、性能建议

●因为RDB文件只用作后备用途,建议只在Slave.上持久化RDB文件,而且只要15分钟备份

一 次就够了,只保留save 9001这条规则。

●如果Enable AOF ,好处是在最恶劣情况下也只会丢失不超过两秒数据,启动脚本较简单只

load自己的AOF文件就可以了,代价-是带来了持续的I0 ,二是AOF rewrite的最后将rewrite

过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可,应该尽量

减少AOF rewrite的频率, AOF重写的基础大小默认值64M太小了,可以设到5G以上,默认超

过原大小100%大小重写可以改到适当的数值。

●如果不Enable AOF , 仅靠Master-Slave Repllcation实现高可用性也可以,能省掉一大笔

I0 ,也减少了rewrite时带来的系统波动。代价是如果Master/Slave 同时倒掉,会丢失十几

分钟的数据,启动脚本也要比较两个Master/Slave中的RDB文件,载入较新的那个,微博就是

这种架构。

Redis发布订阅

Redis发布订阅(pub/sub)是一种消息通信模式:发送者(pub)发送消息,订阅者(sub)接收消

息。微信、微博、关注系统!

Redis客户端可以订阅任意数量的频道。

订阅/发布消息图:

第一个:消息发送者I第二个:频道第三个:消息订阅者!

下图展示了频道channel1，以及订阅这个频道的三个客户端

)]

当有新消息通过PUBLISH命令发送给频道channel1时，这个消息就会被发送给订阅它的三个客户端:

命令

这些命令被广泛应用于实时通信应用，比如网络聊天室（chatrooom）场景、实时提醒

测试

订阅端

#订阅一个频道
SUBSCRIBE 频道
#读取消息的形式
	#消息
	#那个频道的消息
	#消息的具体内容

发送端

#发布者发布消息频道
PUBLISH 频道 消息

原理

Redis是使用C实现的,通过分析Redis源码里的pubsub.c文件，了解发布和订阅机制的底层实现,籍此加深对Redis的理解。

Redis通过PUBLISH、SUBSCRIBE 和PSUBSCRIBE等命令实现发布和订阅功能。

通过SUBSCRIBE命令订阅某频道后, redis-server 里维护了- -个字典,字典的键就是一个个channel ,而字典的值则是一个链

表,链表中保存了所有订阅这个channel的客户端。

SUBSCRIBE 命令的关键,就是将客户端添加到给定channel的订阅链表中。通过PUBLISH命令向订阅者发送消息, redis-server 会使用给定的频道作为键,在它所维护的channel字典中查找记录了订阅这个频道的所有客户端的链表,遍历这个链表,将消息发布给所有订阅者。

Pub/Sub从字面上理解就是发布( Publish )与订阅( Subscribe ) , 在Redis中,你可以设定对某一个key值进行消息发布及消息

订阅，当一个key值上进行了消息发布后,所有订阅它的客户端都会收到相应的消息。这一功能最明显的用法就是用作实时

消息系统,比如普通的即时聊天,群聊等功能。

应用

1. 实时聊天系统
2. 实时消息系统
3. 订阅，关注都是可以的

主从复制

概念

主从复制,是指将一台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。

电商网站上的商品，-般都是一次上传,无数次浏览的,说专业点也就是"多读少写"。

对于这种场景,我们可以使如下这种架构:

主从复制,读写分离! 80% 的情况下都是在进行读操作!减缓服务器的压力! 架构中经常使用! -主二从!

只要在公司中,主从复制就是必须要使用的,因为在真实的项目中不可能单机使用Redis !

环境配置

只配置从库，不配置主库

127.0.0.1:6379> info repTication # 查看当前库的信息
# Rep1ication
role:master #角色
maste r
connected_ slaves:0 #没有从机
master_ replid:b63c90e6c501143759cb0e7f450bd1eb0c70882a
master_ rep1i d2 : 0000000000000000000000000000000000000000
master_ rep1_ offset:0
second_ rep1_ _offset:-1
rep1_ back1og_ _active:0
rep1_ back7og_ size :1048576
rep1_ back7og_ first_ byte_ offset:0
rep1_ back7og_ histlen:0

一主二从

默认情况下每一台Redis服务器都是主节点；我们一般情况下，只用配置从机就行了；

认老大一主(79) 二从(80,81)

#找谁当自己的老大
SLAVEOF  主机地址  端口号

#查看当前库信息
info replication

真实的主从配置是在配置文件写的，这样的配置是永久的；命令写的只是暂时的；

细节

主机可以写，从机不能写，只能读；主机中所有的信息都会被自动保存在从机中；

测试

主机断开连接，从机依旧是连接到主机的；但是没有写操作的；

主机回来，从机依旧可以获取写的信息；

从机断开，如果是使用命令行编写的配置文件；那么需要重新来配置主从配置；修改配置文件则不需要；

复制原理

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

Master接到命令,启动后台的存盘进程,同时收集所有接收到的用于修改数据集命令,在后台进程执行完毕之后, master将传

送整个数据文件到slave ,并完成一次完全同步。

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

增量复制: Master继续将新的所有收集到的修改命令依次传给slave ,完成同步

但是只要是重新连接master , - -次完全同步(全量复制)将被自动执行

如果没有老大，这个时候需要手动选择出来一个老大

如果主机断开连接，我们可以使用 SLAVEOF no one 让自己变成主机！其他的节点就可以手动连接到最新的主机节点（手动）

哨兵模式

自动选举老大的模式

概述

主从切换技术的方法是:当主服务器宕机后,需要手动把一台从服务器切换为主服务器,这就需要人工干预,费事费力,还会造成

一段时间内服务不可用。这不是一-种推荐的方式 ,更多时候,我们优先考虑哨兵模式。Redis从2.8开始正式提供Sentinel(哨

兵)架构来解决这个问题。

谋朝篡位的自动版,能够后台监控主机是否故障,如果故障了根据投票数自动将从库转换为主库。

哨兵模式是一种特殊的模式 ,首先Redis提供了哨兵的命令,哨兵是一-个独立的进程,作为进程,它会独立运行。其原理是哨兵

通过发送命令,等待Redis服务器响应,从而监控运行的多个Redis实例。

这里的哨兵有两个作用

●通过发送命令,让Redis服务器返回监控其运行状态,包括主服务器和从服务器。

●当哨兵监测到master宕机,会自动将slave切换成master ,然后通过发布订阅模式通知其他的从服务器,修改配置文件,让它

们切换主机。

然而一一个哨兵进程对Redis服务器进行监控,可能会出现问题,为此,我们可以使用多个哨兵进行监控。各个哨兵之间还会进

行监控,这样就形成了多哨兵模式。

假设主服务器宕机,哨兵1先检测到这个结果,系统并不会马上进行failover过程,仅仅是哨兵1主观的认为主服务器不可用,这

个现象成为主观下线。当后面的哨兵也检测到主服务器不可用,并且数量达到一定值时,那么哨兵之间就会进行一次投票,投

票的结果由一一个哨兵发起,进行failover[故障转移]操作。切换成功后,就会通过发布订阅模式,让各个哨兵把自己监控的从

服务器实现切换主机，这个过程称为客观下线。

测试

1、配置哨兵模式sentinel.conf

# sentine1 monitor 被监控的名称host  port 1
sentine1 monitor myredis 127.0.0.1 6379 1

后面的这个数字1 ,代表主机挂了, slave投票看让谁接替成为主机,票数最多的,就会成为主机!

2、启动哨兵!

如果主机死后又回来了，只能归并到新的主机下面；当做从机，这就是哨兵模式的规则

哨兵模式的优缺点

1、优点

• 哨兵集群，基于主从复制模式，所有主从配置优点，他都有；
• 主从可以切换，故障可以转移，系统的可用性就会更好；
• 哨兵模式就是主从模式的升级版，手动到自动，更加健壮

2、缺点

• Redis不好在线扩容，集群容量一旦达到上限，在扩充就会十分麻烦；
• 哨兵模式配置很麻烦，里面有很多的选择；

缓存穿透与雪崩

保证服务器的三高！！！！

高可用

高性能

高并发

在这里我们不会详细的区分析解决方案的底层!

Redis缓存的使用,极大的提升了应用程序的性能和效率,特别是数据查询方面。但同时,它也带来了一些问题。 其中,最要害

的问题,就是数据的一致性问题，从严格意义上讲,这个问题无解。如果对数据的一致性要求很高,那么就不能使用缓存。

另外的一些典型问题就是,缓存穿透、缓存雪崩和缓存击穿。目前,业界也都有比较流行的解决方案。

缓存的穿透（查询不到）

概念

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

解决方案

布隆过滤器

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

缓存空对象

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

但是这种方法会存在两个问题:

1、如果空值能够被缓存起来,这就意味着缓存需要更多的空间存储更多的键,因为这当中可能会有很多的空值的键;

2、即使对空值设置了过期时间,还是会存在缓存层和存储层的数据会有一-段时间窗口的不一致,这对于需要保持一致性的业务会有影响。

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

概述

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

当某个key在过期的瞬间,有大量的请求并发访问,这类数据一般是热点数据 ,由于缓存过期,会同时访问数据库来查询最新数据,并且回写缓存,会导使数据库瞬间压力过大。

解决方案

设置热点数据永不过期

从缓存层面个看，没有设置过期时间，所以不会出现热点key过期后产生的问题。

加互斥锁

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

缓存雪崩

概念

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

产生雪崩的原因之- - ,比如在写本文的时候,马上就要到双十二零点,很快就会迎来一波抢购,这波商品时间比较集中的放入了缓存,假设缓存一一个小时。 那么到了凌晨- -点钟的时候 ,这批商品的缓存就都过期了。而对这批商品的访问查询,都落到了数据库上,对于数据库而言,就会产生周期性的压力波峰。于是所有的请求都会达到存储层,存储层的调用量会暴增,造成存储层也会挂掉的情况。

实集中过期,倒不是非常致命,比较致命的缓存雪崩,是缓存服务器某个节点宕机或断网。因为自然形成的缓存雪崩, -定是在
某个时间段集中创建缓存,这个时候,数据库也是可以顶住压力的。无非就是对数据库产“生周期性的压力而已。而缓存服务节点的宕机,对数据库服务器造成的压力是不可预知的,很有可能瞬间就把数据库压垮。

解决方案

Redis高可用

这个思想的含义是,既然redis有可能挂掉,那我多增设几台redis ,这样一台挂掉之 后其他的还可以继续工作,其实就是搭建的集群。

限流降级

这个解决方案的思想是, 在缓存失效后,通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一一个线程查询数据和写缓存,其他线程等待。

数据预热

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

层先进行校验,不符合则丢弃,从而避免了对底层存储系统的查询压力;

[外链图片转存中…(img-v6oQtB56-1615206260895)]

缓存空对象

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

[外链图片转存中…(img-qgwSi9Zr-1615206260895)]

但是这种方法会存在两个问题:

1、如果空值能够被缓存起来,这就意味着缓存需要更多的空间存储更多的键,因为这当中可能会有很多的空值的键;

2、即使对空值设置了过期时间,还是会存在缓存层和存储层的数据会有一-段时间窗口的不一致,这对于需要保持一致性的业务会有影响。

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

概述

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

当某个key在过期的瞬间,有大量的请求并发访问,这类数据一般是热点数据 ,由于缓存过期,会同时访问数据库来查询最新数据,并且回写缓存,会导使数据库瞬间压力过大。

解决方案

设置热点数据永不过期

从缓存层面个看，没有设置过期时间，所以不会出现热点key过期后产生的问题。

加互斥锁

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

缓存雪崩

概念

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

产生雪崩的原因之- - ,比如在写本文的时候,马上就要到双十二零点,很快就会迎来一波抢购,这波商品时间比较集中的放入了缓存,假设缓存一一个小时。 那么到了凌晨- -点钟的时候 ,这批商品的缓存就都过期了。而对这批商品的访问查询,都落到了数据库上,对于数据库而言,就会产生周期性的压力波峰。于是所有的请求都会达到存储层,存储层的调用量会暴增,造成存储层也会挂掉的情况。

实集中过期,倒不是非常致命,比较致命的缓存雪崩,是缓存服务器某个节点宕机或断网。因为自然形成的缓存雪崩, -定是在
某个时间段集中创建缓存,这个时候,数据库也是可以顶住压力的。无非就是对数据库产“生周期性的压力而已。而缓存服务节点的宕机,对数据库服务器造成的压力是不可预知的,很有可能瞬间就把数据库压垮。

解决方案

Redis高可用

这个思想的含义是,既然redis有可能挂掉,那我多增设几台redis ,这样一台挂掉之 后其他的还可以继续工作,其实就是搭建的集群。

限流降级

这个解决方案的思想是, 在缓存失效后,通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一一个线程查询数据和写缓存,其他线程等待。

数据预热

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

小结