redis常见数据类型操作命令
Redis在网页开发中可以作为缓存使用，一个用户登录了某个网页可以将它的登陆信息写入到redis中，且可以进行持久化保存。

Redis 安装

安装C语言编译环境

yum install centos-release-scl scl-utils-build
yum install -y devtoolset-8-toolchain
scl enable devtoolset-8 bash
测试gcc版本
gcc --version

安装Redis

1.下载redis-6.2.1.tar.gz放/opt目录
2.解压
tar -zxvf redis-6.2.1.tar.gz
cd redis-6.2.1
3.编译
make
如果没有准备好C语言编译环境，make 会报错—Jemalloc/jemalloc.h：没有那个文件（解决方案）
make distclean
再次执行
make  编译
make install  安装

安装目录

启动和关闭

1. 前台启动：cd /usr/local/bin redis-service
2. 后台启动： ```shell 备份redis.conf cp /opt/redis-6.2.1/redis.conf /etc/redis.conf

vim /etc/redis.conf 把daemonize no 改成 yes，让服务在后台启动

后台启动redis redis-server /etc/redis.conf

用客户端访问 cd /usr/local/bin redis-cli

```shell
redis关闭
ps -ef | grep redis
找到redis进程号
kill -9 进程号

Redis基础

基本操作

字符串

String是Redis最基本的类型，你可以理解成与Memcached一模一样的类型，一个key对应一个value。 String类型是二进制安全的。意味着Redis的string可以包含任何数据。比如jpg图片或者序列化的对象。 String类型是Redis最基本的数据类型，一个Redis中字符串value最多可以是512M

列表

集合

Redis set对外提供的功能与list类似是一个列表的功能，特殊之处在于set是可以自动排重的，当你需要存储一个列表数据，又不希望出现重复数据时，set是一个很好的选择，并且set提供了判断某个成员是否在一个set集合内的重要接口，这个也是list所不能提供的。 Redis的Set是string类型的无序集合。它底层其实是一个value为null的hash表，所以添加，删除，查找的复杂度都是O(1)。 一个算法，随着数据的增加，执行时间的长短，如果是O(1)，数据增加，查找数据的时间不变

Hash

Redis hash 是一个键值对集合。 Redis hash是一个string类型的field和value的映射表，hash特别适合用于存储对象。 类似Java里面的Map 用户ID为查找的key，存储的value用户对象包含姓名，年龄，生日等信息，如果用普通的key/value结构来存储

主要有以下2种存储方式

Zset

Redis有序集合zset与普通集合set非常相似，是一个没有重复元素的字符串集合。 不同之处是有序集合的每个成员都关联了一个评分（score）,这个评分（score）被用来按照从最低分到最高分的方式排序集合中的成员。集合的成员是唯一的，但是评分可以是重复了 。 因为元素是有序的, 所以你也可以很快的根据评分（score）或者次序（position）来获取一个范围的元素。 访问有序集合的中间元素也是非常快的,因此你能够使用有序集合作为一个没有重复成员的智能列表。

Redis 配置文件介绍

vim /etc/redis.conf

Units单位

配置大小单位,开头定义了一些基本的度量单位，只支持bytes，不支持bit
大小写不敏感

INCLUDES包含

类似jsp中的include，多实例的情况可以把公用的配置文件提取出来

NETWORK 网络相关配置

默认情况bind=127.0.0.1只能接受本机的访问请求
不写的情况下，无限制接受任何ip地址的访问
生产环境肯定要写你应用服务器的地址；服务器是需要远程访问的，所以需要将其注释掉
如果开启了protected-mode，那么在没有设定bind ip且没有设密码的情况下，Redis只允许接受本机的响应

保存配置，停止服务，重启启动查看进程，不再是本机访问了。
ps -ef |grep redis
kill -9 进程号
redis-server /etc/redis.conf

protected-mode

将本机方位保护模式设置no

port

端口默认为6379

tcp-backlog

设置tcp的backlog，backlog其实是一个连接队列，backlog队列总和=未完成三次握手队列+ 已经完成三次握手队列。
在高并发环境下你需要一个高backlog值来避免慢客户端连接问题。
注意Linux内核会将这个值减小到/proc/sys/net/core/somaxconn的值（128），所以需要确认增大/proc/sys/net/core/somaxconn和/proc/sys/net/ipv4/tcp_max_syn_backlog（128）两个值来达到想要的效果

timeout

一个空闲的客户端维持多少秒会关闭，0表示关闭该功能。即永不关闭。

tcp-keepalive

对访问客户端的一种心跳检测，每个n秒检测一次。
单位为秒，如果设置为0，则不会进行Keepalive检测，建议设置成60

GENERAL通用

• daemonize ： 是否为后台进程，设置为yes。守护进程，后台启动
• pidfile ： 存放pid文件的位置，每个实例会产生一个不同的pid文件
• loglevel ：指定日志记录级别，Redis总共支持四个级别：debug、verbose、notice、warning，默认为notice，四个级别根据使用阶段来选择，生产环境选择notice 或者warning

• logfile ：设定库的数量默认16，默认数据库为0，可以使用SELECT 命令在连接上指定数据库id

• databases 16：设定库的数量默认16，默认数据库为0，可以使用SELECT 命令在连接上指定数据库id

  SECURITY安全

• 设置密码

访问密码的查看、设置和取消
在命令中设置密码，只是临时的。重启redis服务器，密码就还原了。
永久设置，需要再配置文件中进行设置。

config get requirepass 获取密码
config set requirepass "" 设置密码
auth "密码" 登陆，设置完密码后如果没有登陆将不能对redis进行操作

LIMITS限制

• maxclients：设置redis同时可以与多少个客户端进行连接
  • 默认情况下为10000个客户端。
  • 如果达到了此限制，redis则会拒绝新的连接请求，并且向这些连接请求方发出“max number of clients reached”以作回应。
• maxmemory
  • 建议必须设置，否则，将内存占满，造成服务器宕机
  • 设置redis可以使用的内存量。一旦到达内存使用上限，redis将会试图移除内部数据，移除规则可以通过maxmemory-policy来指定。
  • 如果redis无法根据移除规则来移除内存中的数据，或者设置了“不允许移除”，那么redis则会针对那些需要申请内存的指令返回错误信息，比如SET、LPUSH等。
  • 但是对于无内存申请的指令，仍然会正常响应，比如GET等。如果你的redis是主redis（说明你的redis有从redis），那么在设置内存使用上限时，需要在系统中留出一些内存空间给同步队列缓存，只有在你设置的是“不移除”的情况下，才不用考虑这个因素。
• maxmemory-policy
  • volatile-lru：使用LRU算法移除key，只对设置了过期时间的键；（最近最少使用）
  • allkeys-lru：在所有集合key中，使用LRU算法移除key
  • volatile-random：在过期集合中移除随机的key，只对设置了过期时间的键
  • allkeys-random：在所有集合key中，移除随机的key
  • volatile-ttl：移除那些TTL值最小的key，即那些最近要过期的key
  • noeviction：不进行移除。针对写操作，只是返回错误信息
• maxmemory-samples
  • 设置样本数量，LRU算法和最小TTL算法都并非是精确的算法，而是估算值，所以你可以设置样本的大小，redis默认会检查这么多个key并选择其中LRU的那个。
  • 一般设置3到7的数字，数值越小样本越不准确，但性能消耗越小

Redis的发布和订阅

Redis 发布订阅 (pub/sub) 是一种消息通信模式：发送者 (pub) 发送消息，订阅者 (sub) 接收消息。
Redis 客户端可以订阅任意数量的频道。
1、客户端可以订阅频道如下图

2、当给这个频道发布消息后，消息就会发送给订阅的客户端

发布订阅命令行实现

1. 打开一个客户端订阅channel1

SUBSCRIBE channel1

1. 打开另一个客户端，给channel1发布消息hello

publish channel1 hello

返回的1是订阅者数量

1. 打开第一个客户端可以看到发送的消息

发布的消息没有持久化，如果在订阅的客户端收不到hello，只能收到订阅后发布的消息

Redis新数据类型

Bitmaps

现代计算机用二进制（位）作为信息的基础单位，1个字节等于8位， 例如“abc”字符串是由3个字节组成， 但实际在计算机存储时将其用二进制表示， “abc”分别对应的ASCII码分别是97、98、99，对应的二进制分别是01100001、01100010和01100011

• 合理地使用操作位能够有效地提高内存使用率和开发效率。Redis提供了Bitmaps这个“数据类型”可以实现对位的操作：
  • Bitmaps本身不是一种数据类型，实际上它就是字符串（key-value） ， 但是它可以对字符串的位进行操作。
  • Bitmaps单独提供了一套命令， 所以在Redis中使用Bitmaps和使用字符串的方法不太相同。 可以把Bitmaps想象成一个以位为单位的数组， 数组的每个单元只能存储0和1， 数组的下标在Bitmaps中叫做偏移量。 | 指令 | 作用 | | —- | —- | | setbit | 设置Bitmaps中某个偏移量的值（0或1） | | getbit | 获取Bitmaps中某个偏移量的值 | | bitcount[start end] | 统计字符串从start字节到end字节比特值为1的数量 | | bitop and(or/not/xor) [key…] | bitop是一个复合操作， 它可以做多个Bitmaps的and、or、not、xor操作并将结果保存在destkey中。 |

案例1

每个独立用户是否访问过网站存放在Bitmaps中， 将访问的用户记做1， 没有访问的用户记做0， 用偏移量作为用户的id。
设置键的第offset个位的值（从0算起） ， 假设现在有20个用户，userid=1， 6， 11， 15， 19的用户对网站进行了访问， 那么当前Bitmaps初始化结果如图

unique:users:20201106代表2020-11-06这天的独立访问用户的Bitmaps

很多应用的用户id以一个指定数字（例如10000） 开头， 直接将用户id和Bitmaps的偏移量对应势必会造成一定的浪费， 通常的做法是每次做setbit操作时将用户id减去这个指定数字。
在第一次初始化Bitmaps时， 假如偏移量非常大， 那么整个初始化过程执行会比较慢， 可能会造成Redis的阻塞。

案例2

获取id=8的用户是否在2020-11-06这天访问过， 返回0说明没有访问过
getbit unique:user:20201106 8

案例3

计算2022-11-06这天的独立访问用户数量
bitcount unique:users:20201106 0 -1

案例4

计算出两天都访问过网站的用户数量
bitop and unique:users:and:20201104_03 unique:users:20201103 unique:users:20201104

Bitmaps与set对比

假设网站有1亿用户， 每天独立访问的用户有5千万， 如果每天用集合类型和Bitmaps分别存储活跃用户可以得到表

很明显，这种情况下使用Bitmaps能节省很多的内存空间， 尤其是随着时间推移节省的内存还是非常可观的

但Bitmaps并不是万金油， 假如该网站每天的独立访问用户很少， 例如只有10万（大量的僵尸用户） ， 那么两者的对比如下表所示， 很显然， 这时候使用Bitmaps就不太合适了， 因为基本上大部分位都是0。

HyperLogLog

在工作当中，我们经常会遇到与统计相关的功能需求，比如统计网站PV（PageView页面访问量）,可以使用Redis的incr、incrby轻松实现。 但像UV（UniqueVisitor，独立访客）、独立IP数、搜索记录数等需要去重和计数的问题如何解决？这种求集合中不重复元素个数的问题称为基数问题。 解决基数问题有很多种方案： （1）数据存储在MySQL表中，使用distinct count计算不重复个数 （2）使用Redis提供的hash、set、bitmaps等数据结构来处理 以上的方案结果精确，但随着数据不断增加，导致占用空间越来越大，对于非常大的数据集是不切实际的。 能否能够降低一定的精度来平衡存储空间？Redis推出了HyperLogLog Redis HyperLogLog 是用来做基数统计的算法，HyperLogLog 的优点是，在输入元素的数量或者体积非常非常大时，计算基数所需的空间总是固定的、并且是很小的。 在Redis 里面，每个 HyperLogLog 键只需要花费 12 KB 内存，就可以计算接近 2^64 个不同元素的基数。这和计算基数时，元素越多耗费内存就越多的集合形成鲜明对比。 但是，因为HyperLogLog 只会根据输入元素来计算基数，而不会储存输入元素本身，所以 HyperLogLog 不能像集合那样，返回输入的各个元素。

什么是基数? 比如数据集{1, 3, 5, 7, 5, 7, 8}， 那么这个数据集的基数集为 {1, 3, 5 ,7, 8}, 基数(不重复元素)为5。 基数估计就是在误差可接受的范围内，快速计算基数。

Geospatial

Redis 3.2 中增加了对GEO类型的支持。GEO，Geographic，地理信息的缩写。该类型，就是元素的2维坐标，在地图上就是经纬度。redis基于该类型，提供了经纬度设置，查询，范围查询，距离查询，经纬度Hash等常见操作。

实例1

添加城市坐标数据
geoadd china:city 121.47 31.23 shanghai
geoadd china:city 106.50 29.53 chongqing 114.05 22.52 shenzhen 116.38 39.90 beijing

两极无法直接添加，一般会下载城市数据，直接通过Java 程序一次性导入。
有效的经度从-180 度到 180 度。有效的纬度从 -85.05112878 度到 85.05112878 度。
当坐标位置超出指定范围时，该命令将会返回一个错误。
已经添加的数据，是无法再次往里面添加的。
获取城市坐标数据

获取北京和上海之间的直线距离

单位：
m 表示单位为米[默认值]。
km 表示单位为千米。
mi 表示单位为英里。
ft 表示单位为英尺。
如果用户没有显式地指定单位参数，那么GEODIST 默认使用米作为单位
获取经度110维度30的坐标半径1000km内的城市

Redis_Jedis测试

测试连接

1. 编辑redis配置文件

   vim /etc/redis.conf 
   vim /opt/redis-6.2.1/redis。conf
   修该内容如下
   注释掉bind 127.0.0.1 ,然后 protected-mode no
   

2. 开启端口 ```shell 在腾讯云官网开启6379端口

开服务器开启6379端口 firewall-cmd —zone=public —add-port=6379/tcp —permanent

ps-ef | grep redis 查看redis进程号 kill -9 进程号 # 杀死redis进程 redis-server /etc/redis.conf 重启redis

3. 导入依赖
```shell
<dependency>
    <groupId>redis.clients</groupId>
    <artifactId>jedis</artifactId>
    <version>3.2.0</version>
</dependency>

1. 编写测试程序 ```java package com.atguigu.jedis;

import redis.clients.jedis.Jedis;

public class JedisDemo1 { public static void main(String[] args) { //创建Jedis对象 Jedis jedis = new Jedis(“1.117.146.57”,6379); //测试 String ping = jedis.ping(); System.out.println(ping); jedis.close() } }

<a name="Xgr0J"></a>
## 测试相关数据类型
```java
package com.atguigu.jedis;

import redis.clients.jedis.Jedis;
import java.util.Set;

public class JedisDemo1 {
    public static void main(String[] args) {
        //创建Jedis对象
        Jedis jedis = new Jedis("1.117.146.57",6379);
        jedis.flushDB();
        jedis.set("name", "luck"); //字符串
        jedis.mset("k1","v1","k1","v2");  //字符串

        jedis.lpush("key1","1","2","3","4");// 列表
        jedis.sadd("set","set1","set2");//集合
        jedis.hset("user","name","lhd");//Hash
        jedis.zadd("zset",100,"math");//Zset
        Set<String> keys = jedis.keys("*");

        System.out.println(keys.toString());
    }
}

模拟验证码发送

要求：
1、输入手机号，点击发送后随机生成6位数字码，2分钟有效
2、输入验证码，点击验证，返回成功或失败
3、每个手机号每天只能输入3次

1. 生成随机的6位数字验证码
2. 把验证码放到redis里面，设置过期时间120秒
3. 判断验证码是否一致
4. incr每次发送之后+1，大于2的时候，提交不能发送，设置每次增长后的值过期时间为1天

Redis与SpringBoot整合

1. 导入依赖 ```shell org.springframework.boot spring-boot-starter-data-redis

org.apache.commons commons-pool2 2.6.0

2. application.properties配置redis配置
```shell
#Redis服务器地址
spring.redis.host=1.117.146.57
#Redis服务器连接端口
spring.redis.port=6379
#Redis数据库索引（默认为0）
spring.redis.database= 0
#连接超时时间（毫秒）
spring.redis.timeout=1800000
#连接池最大连接数（使用负值表示没有限制）
spring.redis.lettuce.pool.max-active=20
#最大阻塞等待时间(负数表示没限制)
spring.redis.lettuce.pool.max-wait=-1
#连接池中的最大空闲连接
spring.redis.lettuce.pool.max-idle=5
#连接池中的最小空闲连接
spring.redis.lettuce.pool.min-idle=0

1. 添加redis配置类 ```shell package com.example.demo.redis_springboot;

import com.fasterxml.jackson.annotation.JsonAutoDetect; import com.fasterxml.jackson.annotation.PropertyAccessor; import com.fasterxml.jackson.databind.ObjectMapper; import org.springframework.cache.CacheManager; import org.springframework.cache.annotation.CachingConfigurerSupport; import org.springframework.cache.annotation.EnableCaching; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; import org.springframework.data.redis.cache.RedisCacheConfiguration; import org.springframework.data.redis.cache.RedisCacheManager; import org.springframework.data.redis.connection.RedisConnectionFactory; import org.springframework.data.redis.core.RedisTemplate; import org.springframework.data.redis.serializer.Jackson2JsonRedisSerializer; import org.springframework.data.redis.serializer.RedisSerializationContext; import org.springframework.data.redis.serializer.RedisSerializer; import org.springframework.data.redis.serializer.StringRedisSerializer;

import java.time.Duration;

@EnableCaching @Configuration public class RedisConfig extends CachingConfigurerSupport {

@Bean
public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory factory) {
    RedisTemplate<String, Object> template = new RedisTemplate<>();
    RedisSerializer<String> redisSerializer = new StringRedisSerializer();
    Jackson2JsonRedisSerializer jackson2JsonRedisSerializer = new Jackson2JsonRedisSerializer(Object.class);
    ObjectMapper om = new ObjectMapper();
    om.setVisibility(PropertyAccessor.ALL, JsonAutoDetect.Visibility.ANY);
    om.enableDefaultTyping(ObjectMapper.DefaultTyping.NON_FINAL);
    jackson2JsonRedisSerializer.setObjectMapper(om);
    template.setConnectionFactory(factory);
    //key序列化方式
    template.setKeySerializer(redisSerializer);
    //value序列化
    template.setValueSerializer(jackson2JsonRedisSerializer);
    //value hashmap序列化
    template.setHashValueSerializer(jackson2JsonRedisSerializer);
    return template;
}

@Bean
public CacheManager cacheManager(RedisConnectionFactory factory) {
    RedisSerializer<String> redisSerializer = new StringRedisSerializer();
    Jackson2JsonRedisSerializer jackson2JsonRedisSerializer = new Jackson2JsonRedisSerializer(Object.class);
            //解决查询缓存转换异常的问题
    ObjectMapper om = new ObjectMapper();
    om.setVisibility(PropertyAccessor.ALL, JsonAutoDetect.Visibility.ANY);
    om.enableDefaultTyping(ObjectMapper.DefaultTyping.NON_FINAL);
    jackson2JsonRedisSerializer.setObjectMapper(om);
            // 配置序列化（解决乱码的问题）,过期时间600秒
    RedisCacheConfiguration config = RedisCacheConfiguration.defaultCacheConfig()
            .entryTtl(Duration.ofSeconds(600))
            .serializeKeysWith(RedisSerializationContext.SerializationPair.fromSerializer(redisSerializer))
            .serializeValuesWith(RedisSerializationContext.SerializationPair.fromSerializer(jackson2JsonRedisSerializer))
            .disableCachingNullValues();
    RedisCacheManager cacheManager = RedisCacheManager.builder(factory)
            .cacheDefaults(config)
            .build();
    return cacheManager;
}

}

4. 测试
```shell
package com.example.demo.controller;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.ResponseBody;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class RedisTestController {
    @Autowired
    private RedisTemplate redisTemplate;

    @ResponseBody
    @GetMapping("/hello")
    public String testRedis(){
        //设置值到redis程序
        redisTemplate.opsForValue().set("name1","lhd");
        String name1 = (String) redisTemplate.opsForValue().get("name1");
        System.out.println("+++++"+name1);
        return name1;
    }
}

Redis事务、锁机制、秒杀

Redis事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断

从输入Multi命令开始，输入的命令都会依次进入命令队列中，但不会执行，直到输入Exec后，Redis会将之前的命令队列中的命令依次执行。
组队的过程中可以通过discard来放弃组队。
事务的错误处理

• 组队中某个命令出现了报告错误，执行时整个的所有队列都会被取消。
• 如果执行阶段某个命令报出了错误，则只有报错的命令不会被执行，而其他的命令都会执行，不会回滚。

  事务的冲突问题

  

  悲观锁

  
  悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。

  乐观锁

  
  乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量。Redis就是利用这种check-and-set机制实现事务的。

• 在执行multi之前，先执行watch key1 [key2],可以监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断。
• 取消WATCH 命令对所有key 的监视。如果在执行WATCH 命令之后，EXEC 命令或DISCARD 命令先被执行了的话，那么就不需要再执行UNWATCH 了。

并发模拟器

1. 安装yum install httpd-tools
2. ab -n 2000 -c 200 -k -p ~/postfile -T application/x-www-form-urlencoded http://192.168.2.115:8081/Seckill/doseckill ```shell -n requests Number of requests to perform 请求数量 -c concurrency Number of multiple requests to make at a time 请求并发数量 -t timelimit Seconds to max. to spend on benchmarking

            This implies -n 50000
   

   -s timeout Seconds to max. wait for each response

            Default is 30 seconds
   

   -b windowsize Size of TCP send/receive buffer, in bytes -B address Address to bind to when making outgoing connections -p postfile File containing data to POST. Remember also to set -T 提交参数 -u putfile File containing data to PUT. Remember also to set -T -T content-type Content-type header to use for POST/PUT data, eg. 提交类型

            'application/x-www-form-urlencoded'
            Default is 'text/plain'
   

   -v verbosity How much troubleshooting info to print -w Print out results in HTML tables -i Use HEAD instead of GET -x attributes String to insert as table attributes -y attributes String to insert as tr attributes -z attributes String to insert as td or th attributes -C attribute Add cookie, eg. ‘Apache=1234’. (repeatable) -H attribute Add Arbitrary header line, eg. ‘Accept-Encoding: gzip’

            Inserted after all normal header lines. (repeatable)
   

   -A attribute Add Basic WWW Authentication, the attributes

            are a colon separated username and password.
   

   -P attribute Add Basic Proxy Authentication, the attributes

            are a colon separated username and password.
   

   -X proxy:port Proxyserver and port number to use -V Print version number and exit -k Use HTTP KeepAlive feature -d Do not show percentiles served table. -S Do not show confidence estimators and warnings. -q Do not show progress when doing more than 150 requests -g filename Output collected data to gnuplot format file. -e filename Output CSV file with percentages served -r Don’t exit on socket receive errors. -h Display usage information (this message) -Z ciphersuite Specify SSL/TLS cipher suite (See openssl ciphers) -f protocol Specify SSL/TLS protocol

<a name="aRxkx"></a>
# 持久化
<a name="aH6Xl"></a>
## RDB
> 在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里
> Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能 如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。**RDB的缺点是最后一次持久化后的数据可能丢失**。

**Fork**
> l Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程
> l 在Linux程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会exec系统调用，出于效率考虑，Linux中引入了“**写时复制技术**”
> **一般情况父进程和子进程会共用同一段物理内存**，只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程。

**持久化流程**<br />![image.png](https://cdn.nlark.com/yuque/0/2021/png/2442606/1628219694237-9fddf0f9-15df-49be-b343-94d5284f121f.png#clientId=ua2105144-e28d-4&from=paste&height=321&id=u1ab5d4c0&margin=%5Bobject%20Object%5D&name=image.png&originHeight=321&originWidth=461&originalType=binary&ratio=1&size=32580&status=done&style=none&taskId=u91e291c5-332a-4ed3-9abf-71a3cb35419&width=461)

- 在redis.conf中配置文件名称，持久化文件默认为dump.rdb
- rdb文件的保存路径，也可以修改。默认为Redis启动时命令行所在的目录下dir  ./

**配置文件中默认的快找配置**
> - **3600秒内有1个key发生变化，触发持久化操作**

![image.png](https://cdn.nlark.com/yuque/0/2021/png/2442606/1628220084704-8fc2cfd3-a8a9-480f-966e-50ea6adae074.png#clientId=ua2105144-e28d-4&from=paste&height=212&id=u62b08d34&margin=%5Bobject%20Object%5D&name=image.png&originHeight=212&originWidth=743&originalType=binary&ratio=1&size=21528&status=done&style=none&taskId=u1c6e1ccc-117c-4d53-84a4-f373b7e63bc&width=743)

- 当Redis无法写入磁盘的话，直接关掉Redis的写操作。推荐yes.

![image.png](https://cdn.nlark.com/yuque/0/2021/png/2442606/1628220261021-8d126f7d-5683-47d8-9b48-dc5257ad7261.png#clientId=ua2105144-e28d-4&from=paste&height=128&id=u83d853e3&margin=%5Bobject%20Object%5D&name=image.png&originHeight=128&originWidth=693&originalType=binary&ratio=1&size=21948&status=done&style=none&taskId=u583c24d6-0aba-4405-b024-3394b9085b2&width=693)

- 对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能。推荐yes.

![image.png](https://cdn.nlark.com/yuque/0/2021/png/2442606/1628220290330-516dfc8b-e70a-4910-af16-1bb43f8def3c.png#clientId=ua2105144-e28d-4&from=paste&height=124&id=u9540541d&margin=%5Bobject%20Object%5D&name=image.png&originHeight=124&originWidth=693&originalType=binary&ratio=1&size=23031&status=done&style=none&taskId=u43cfc14e-9647-4258-89c0-7b393fda319&width=693)

- 在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能，推荐yes.
<a name="HaF8t"></a>
### 优势

- 适合大规模的数据恢复
- 对数据完整性和一致性要求不高更适合使用
- 节省磁盘空间
- 恢复速度快
<a name="s3dW6"></a>
### 劣势

- Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑
- 虽然Redis在fork时使用了**写时拷贝技术**,但是如果数据庞大时还是比较消耗性能。
- 在备份周期在一定间隔时间做一次备份，所以如果Redis意外down掉的话，就会丢失最后一次快照后的所有修改。

![image.png](https://cdn.nlark.com/yuque/0/2021/png/2442606/1628220935812-a2e1416b-7b46-458e-b8b0-f13e4edfd72d.png#clientId=ua2105144-e28d-4&from=paste&height=457&id=uda1e84a6&margin=%5Bobject%20Object%5D&name=image.png&originHeight=457&originWidth=695&originalType=binary&ratio=1&size=221754&status=done&style=none&taskId=u4a841c07-fd44-48b8-8555-a7277fcf4d9&width=695)
<a name="PcUck"></a>
## AOF
> 以**日志**的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来(**读操作不记录**)， **只许追加文件但不可以改写文件**，redis启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

<a name="KVCOc"></a>
### AOF持久化流程
（1）客户端的请求写命令会被append追加到AOF缓冲区内；<br />（2）AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中；<br />（3）AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；<br />（4）Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的；<br />![image.png](https://cdn.nlark.com/yuque/0/2021/png/2442606/1628224863544-5705787d-3920-4b0d-a881-2d336ca3ccc2.png#clientId=ua2105144-e28d-4&from=paste&height=479&id=u7a3d5716&margin=%5Bobject%20Object%5D&name=image.png&originHeight=479&originWidth=292&originalType=binary&ratio=1&size=29544&status=done&style=none&taskId=u9de90504-89d1-439a-89fb-e9fb1bf8373&width=292)
<a name="Ip7XV"></a>
### AOF基本配置

- AOF默认不开启可以在redis.conf中配置文件名称，默认为 appendonly.aofAOF文件的保存路径，同RDB的路径一致。
- AOF和RDB同时开启，系统默认取AOF的数据（数据不会存在丢失）

<a name="xRh8n"></a>
### AOF启动/修复/恢复
> AOF的备份机制和性能虽然和RDB不同, 但是备份和恢复的操作同RDB一样，都是拷贝备份文件，需要恢复时再拷贝到Redis工作目录下，启动系统即加载。

- 正常恢复
   - 修改默认的appendonly no，改为yes
   - 将有数据的aof文件复制一份保存到对应目录(查看目录：config get dir)
   - 恢复：重启redis然后重新加载
- 异常恢复
   - 修改默认的appendonly no，改为yes
   - 如遇到**AOF文件损坏**，通过/usr/local/bin/**redis-check-aof--fix appendonly.aof**进行恢复
   - 备份被写坏的AOF文件
   - 恢复：重启redis，然后重新加载
<a name="xNeyG"></a>
### AOF同步频率设置
appendfsync always  ： 始终同步，每次Redis的写入都会立刻记入日志；性能较差但数据完整性比较好<br />appendfsync everysec  ： 每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。<br />appendfsync no  ： redis不主动进行同步，把同步时机交给操作系统。

<a name="REP6R"></a>
### Rewrite压缩
> AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制, 当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩， 只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof

<a name="PBD0f"></a>
#### 重写原理
AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，redis4.0版本后的重写，是指上就是把rdb 的快照，以二级制的形式附在新的aof头部，作为已有的历史数据，替换掉原来的流水账操作。<br />no-appendfsync-on-rewrite：<br />如果no-appendfsync-on-rewrite=yes ,不写入aof文件只写入缓存，用户请求不会阻塞，但是在这段时间如果宕机会丢失这段时间的缓存数据。（降低数据安全性，提高性能）<br />如果no-appendfsync-on-rewrite=no,  还是会把数据往磁盘里刷，但是遇到重写操作，可能会发生阻塞。（数据安全，但是性能降低）
<a name="ZDfBW"></a>
#### 触发机制
Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发<br />重写虽然可以节约大量磁盘空间，减少恢复时间。但是每次重写还是有一定的负担的，因此设定Redis要满足一定条件才会进行重写。 <br />auto-aof-rewrite-percentage：设置重写的基准值，文件达到100%时开始重写（文件是原来重写后文件的2倍时触发）<br />auto-aof-rewrite-min-size：设置重写的基准值，最小文件64MB。达到这个值开始重写。<br />**例如：**文件达到70MB开始重写，降到50MB，下次什么时候开始重写？100MB<br />系统载入时或者上次重写完毕时，Redis会记录此时AOF大小，设为base_size,如果Redis的AOF当前大小>= base_size +base_size*100% (默认)且当前大小>=64mb(默认)的情况下，Redis会对AOF进行重写。 
<a name="GkBXK"></a>
#### 重写流程
（1）bgrewriteaof触发重写，判断是否当前有bgsave或bgrewriteaof在运行，如果有，则等待该命令结束后再继续执行。<br />（2）主进程fork出子进程执行重写操作，保证主进程不会阻塞。<br />（3）子进程遍历redis内存中数据到临时文件，客户端的写请求同时写入aof_buf缓冲区和aof_rewrite_buf重写缓冲区保证原AOF文件完整以及新AOF文件生成期间的新的数据修改动作不会丢失。<br />（4）1).子进程写完新的AOF文件后，向主进程发信号，父进程更新统计信息。2).主进程把aof_rewrite_buf中的数据写入到新的AOF文件。<br />（5）使用新的AOF文件覆盖旧的AOF文件，完成AOF重写。
<a name="P8ecr"></a>
### 优势
![image.png](https://cdn.nlark.com/yuque/0/2021/png/2442606/1628225311344-bbc596ea-acc8-4651-a7b3-e191a2b1ffb2.png#clientId=ua2105144-e28d-4&from=paste&height=133&id=u68a3b5f0&margin=%5Bobject%20Object%5D&name=image.png&originHeight=133&originWidth=670&originalType=binary&ratio=1&size=81060&status=done&style=none&taskId=u024c9d72-281f-4c8c-9457-bb7de505a90&width=670)

- 备份机制更稳健，丢失数据概率更低。
- 可读的日志文本，通过操作AOF稳健，可以处理误操作。
<a name="pcGFe"></a>
### 劣势

- 比起RDB占用更多的磁盘空间。
- 恢复备份速度要慢。
- 每次读写都同步的话，有一定的性能压力。
- 存在个别Bug，造成恢复不能。


![image.png](https://cdn.nlark.com/yuque/0/2021/png/2442606/1628225354779-e0b29739-f6f4-4b05-8839-9265c612ce42.png#clientId=ua2105144-e28d-4&from=paste&height=390&id=ua056c389&margin=%5Bobject%20Object%5D&name=image.png&originHeight=390&originWidth=688&originalType=binary&ratio=1&size=185123&status=done&style=none&taskId=ua1bd64bd-0d24-4840-bc5f-9390a235936&width=688)

<a name="fpUQz"></a>
## 总结
> 官方推荐两个都启用。
> 如果对数据不敏感，可以选单独用RDB。
> 不建议单独用AOF，因为可能会出现Bug。
> 如果只是做纯内存缓存，可以都不用。



- RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储
- AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾. 
- Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大
- 只做缓存：如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式.
- 同时开启两种持久化方式
- 在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据, 因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.
- RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢？ 
- 建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段。
- 性能建议
| 因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。<br /><br />如果使用AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了。<br />代价,一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。<br />只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。<br />默认超过原大小100%大小时重写可以改到适当的数值。 |
| --- |

<a name="Ppacl"></a>
# 主从复制

1. 当从服务器连接上主服务器后，从服务器向主服务发送进行数据同步的消息
1. 主服务器接到从服务器发送过来同步的消息，把主服务器数据进行持久化，rdb文件，把rdb文件发送从服务器，从服务器拿到rdb进行读取
1. 每次主服务器进行写操作之后，和从服务器进行数据同步

![image.png](https://cdn.nlark.com/yuque/0/2021/png/2442606/1628225929516-e3cc3514-84f6-494c-a858-1a45bc716918.png#clientId=ua2105144-e28d-4&from=paste&height=258&id=ud11d2f4c&margin=%5Bobject%20Object%5D&name=image.png&originHeight=258&originWidth=405&originalType=binary&ratio=1&size=91803&status=done&style=none&taskId=u5e9c3536-df8d-445b-89aa-1aa953152b1&width=405)
<a name="Eyz72"></a>
## 实现案例
```shell
1.复制配置文件
cp /etc/redis.conf /home/lhd/myredis/redis.conf 

1.1 修改配置文件内容为
daemonize yes
appendonly no

2.配置一主两从，创建三个配置文件
redis6379.conf
redis6380.conf
redis6381.conf

3.在三个配置文件中写入如下内容，端口号改为对应的
include /myredis/redis.conf
pidfile /var/run/redis_6379.pid
port 6379
dbfilename dump6379.rdb

4.启动三个redis服务
redis-server redis6379.conf
redis-server redis6380.conf
redis-server redis6381.conf

5.启动服务器
redis-cli -p 6379
redis-cli -p 6380
redis-cli -p 6381

6.查看主从信息
info replication

7.在从机上执行命令，挂载到主服务器
slaveof 127.0.0.1 6379

8.再次查看主从信息可以看到主机上挂载着两部从机了
9.搭建成功后只能在主机进行写操作

常用3招

一主二仆

• 当从服务器挂掉了再重新启动会，改从服务器不会被挂载到主服务器中，如果需要继续做从服务器需要重新挂载
• 主服务器挂掉了从服务器还是从服务器

薪火相传

上一个Slave可以是下一个slave的Master，Slave同样可以接收其他slaves的连接和同步请求，那么该slave作为了链条中下一个的master, 可以有效减轻master的写压力,去中心化降低风险。
用slaveof
中途变更转向:会清除之前的数据，重新建立拷贝最新的
风险是一旦某个slave宕机，后面的slave都没法备份
主机挂了，从机还是从机，无法写数据了

反客为主

当一个master宕机后，后面的slave可以立刻升为master，其后面的slave不用做任何修改。
用slaveof no one 将从机变为主机。

哨兵模式

反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库

1. 设置哨兵，填写内容（在自定义的/home/lhd/myredis目录下新建sentinel.conf文件，名字不能写错）
填写如下内容，其中mymaster为监控对象起的服务器名称， 1 为至少有多少个哨兵同意迁移的数量，6379为主服务器的端口号
sentinel monitor mymaster 127.0.0.1 6379 1

2.启动哨兵
cd /usr/local/bin
redis-sentinel  /home/lhd/myredis/sentinel.conf 

3.当主机挂掉，从机选举中产生新的主机，原主机重启后会变成从机
(选举规则：①.根据优先级级别，在配置文件中slave-priority 100
②.选择偏移量最大的，获取原主机数据最全的
③.选择runid最小的从服务，每个redis实例启动后都会随机生成一个40位的runid)

private static JedisSentinelPool jedisSentinelPool=null;

public static  Jedis getJedisFromSentinel(){
if(jedisSentinelPool==null){
            Set<String> sentinelSet=new HashSet<>();
            sentinelSet.add("192.168.11.103:26379");

            JedisPoolConfig jedisPoolConfig =new JedisPoolConfig();
            jedisPoolConfig.setMaxTotal(10); //最大可用连接数
            jedisPoolConfig.setMaxIdle(5); //最大闲置连接数
            jedisPoolConfig.setMinIdle(5); //最小闲置连接数
            jedisPoolConfig.setBlockWhenExhausted(true); //连接耗尽是否等待
            jedisPoolConfig.setMaxWaitMillis(2000); //等待时间
            jedisPoolConfig.setTestOnBorrow(true); //取连接的时候进行一下测试 ping pong

            jedisSentinelPool=new JedisSentinelPool("mymaster",sentinelSet,jedisPoolConfig);
            return jedisSentinelPool.getResource();
            }else{
            return jedisSentinelPool.getResource();
                   }
}

集群

容量不够，redis如何进行扩容？ 并发写操作，redis如何分摊？ 另外，主从模式，薪火相传模式，主机宕机，导致ip地址发生变化，应用程序中配置需要修改对应的主机地址、端口等信息。 之前通过代理主机来解决，但是redis3.0中提供了解决方案。就是无中心化集群配置。

Redis 集群实现了对Redis的水平扩容，即启动N个redis节点，将整个数据库分布存储在这N个节点中，每个节点存储总数据的1/N。
Redis 集群通过分区（partition）来提供一定程度的可用性（availability）：即使集群中有一部分节点失效或者无法进行通讯，集群也可以继续处理命令请求。

集群搭建步骤

1. 将rdb,aof文件都删除掉
rm -rf *.rdb
rm -rf *.aof
2.制作6个实例：6379,6380,6381,6389,6390,6391
vim /home/lhd/myredis/redis6379.conf
3. 添加如下内容 :%s/6379/6380 指令可以集体替换

include /home/lhd/myredis/redis.conf
pidfile "/var/run/redis_6391.pid"
port 6391
dbfilename "dump6391.rdb"
# 打开集群模式
cluster-enabled yes
# 设定节点配置文件名
cluster-config-file nodes-6391.conf
# 设置节点失联时间，超过该事件，集群自动进行主从切换
cluster-node-timeout 15000

4.启动六个节点的服务
redis-server redis6379.conf
...

5.查看服务是否都开启
ps -ef | grep redis

6.合体(--replicas 1 采用最简单的方式配置集群，一台主机，一台从机，正好三组)
cd /opt/redis-6.2.1/src
redis-cli --cluster create --cluster-replicas 1 127.0.0.1:6379 127.0.0.1:6380 127.0.0.1:6381 127.0.0.1:6389 127.0.0.1:6390 127.0.0.1:6391

7.采用集群策略连接，设置数据会自动切换到相应的写主机
redis-cli -c -p 6379

8.查看集群信息
cluster nodes

什么是slots

一个Redis 集群包含 16384 个插槽（hash slot），数据库中的每个键都属于这16384 个插槽的其中一个，
集群使用公式CRC16(key) % 16384 来计算键 key 属于哪个槽，其中CRC16(key) 语句用于计算键key 的CRC16 校验和。
集群中的每个节点负责处理一部分插槽。举个例子，如果一个集群可以有主节点，其中：
节点A 负责处理 0 号至5460 号插槽。
节点B 负责处理 5461 号至10922 号插槽。
节点C 负责处理 10923 号至16383 号插槽。

在集群中录入值

在redis-cli每次录入、查询键值，redis都会计算出该key应该送往的插槽，如果不是该客户端对应服务器的插槽，redis会报错，并告知应前往的redis实例地址和端口。
redis-cli客户端提供了 –c 参数实现自动重定向。
如redis-cli -c –p 6379 登入后，再录入、查询键值对可以自动重定向。

• 不在一个slot下的键值，是不能使用mget,mset等多键操作。

• 可以通过{}来定义组的概念，从而使key中{}内相同内容的键值对放到一个slot中去。

查询集群中的值

CLUSTER GETKEYSINSLOT 返回 count 个 slot 槽中的键

故障恢复

如果主节点下线？从节点能否自动升为主节点？注意：15秒超时

主节点恢复后，主从关系会如何？主节点回来变成从机。

如果所有某一段插槽的主从节点都宕掉，redis服务是否还能继续?
如果某一段插槽的主从都挂掉，而cluster-require-full-coverage 为yes ，那么，整个集群都挂掉
如果某一段插槽的主从都挂掉，而cluster-require-full-coverage 为no ，那么，该插槽数据全都不能使用，也无法存储。
redis.conf中的参数 cluster-require-full-coverage

集群的Jedis开发

即使连接的不是主机，集群会自动切换主机存储。主机写，从机读。
无中心化主从集群。无论从哪台主机写的数据，其他主机上都能读到数据。

public class JedisClusterTest {
  public static void main(String[] args) { 
     Set<HostAndPort>set =new HashSet<HostAndPort>();
     set.add(new HostAndPort("192.168.31.211",6379));
     JedisCluster jedisCluster=new JedisCluster(set);
     jedisCluster.set("k1", "v1");
     System.out.println(jedisCluster.get("k1"));
  }
}

集群的不足

多键操作是不被支持的
多键的Redis事务是不被支持的。lua脚本不被支持
由于集群方案出现较晚，很多公司已经采用了其他的集群方案，而代理或者客户端分片的方案想要迁移至redis cluster，需要整体迁移而不是逐步过渡，复杂度较大。