Redis学习笔记

redis相关内容

• 默认端口6379

• 默认16个数据库，初始默认使用0号库

• 使用select 切换数据库

• 统一密码管理，所有库密码相同

• dbsize：查看当前库key的数量

• flushdb：清空当前库

• flushall：清空全部库

• redis是单线程 + 多路IO复用技术

  • **多路复用：**使用一个线程来检测多个文件描述符（socket）的就绪状态，比如调用select和poll函数，传入多个文件描述符，如果有一个文件描述符就绪，则返回，否则阻塞到超时，得到就绪状态后进行真正的操作可以在同一个线程里执行，也可以启动线程执行（比如使用线程池）

• 串行 vs 多线程+锁（memcached） vs 单线程+多路复用（redis）

  • （与memcache三不同：支持多数据类型，支持持久化，单线程+多路复用）
  • redis6.0中提供了多线程，命令解析和io数据读写这部分采用了多线程，而命令的执行还是采用的是单线
    程，多个客户端发送来的命令会在同一个线程去执行，相当于排队执行，效率极高

数据类型

这里的数据类型指value数据类型，key类型都是字符串

redis键（key）

• keys *：查看当前库所有的key
• exists key：判断某个key是否存在
• type key：查看你的key是什么类型
• del key：删除指定的key数据
• unlink key：根据value删除非阻塞删除，仅仅将keys从keyspace元数据中删除，真正的删除会在后续异步中操作。
• expire key 10：为指定的key设置有效期10秒
• ttl key：查看指定的key还有多少秒过期，-1：表示永不过期，-2：表示已过期
• select dbindex：切换数据库【0-15】，默认为0
• dbsize：查看当前数据库key的数量
• flushdb：清空当前库
• flushall：通杀全部库

redis字符串（String）

String是Redis最基本的类型 ，一个key对应一个value。是二进制安全的。意味着Redis的string可以包含任何数据（eg：jpg图片或者序列化的对象），一个Redis中字符串value最多可以是512M 。

常用命令

• set：添加键值对
  • NX：当数据库中key不存在时，可以将key-value添加到数据库
  • XX：当数据库中key存在时，可以将key-value添加数据库，与NX参数互斥
  • EX：key的超时秒数
  • PX：key的超时毫秒数，与EX互斥
  • value中若包含空格、特殊字符，需用双引号包裹
• get：获取值
• apend：追加值：将给定的值追加到原值的末尾
• strlen：获取值的长度
• setnx：key不存在时，设置key的值
• incr：原子递增，将key中存储的值增1，只能对数字值操作，如果key不存在，则会新建一个，值为1
• decr：原子递减1，将key中存储的值减1，只能对数字值操作，如果为空，新增值为-1
• incrby/decrby：递增或递减指定的数字
• mset：同时设置多个key-value
• mget：获取多个key对应的值
• msetnx：当多个key都不存在时，则设置成功 。原子性的，要么都成功，或者都失败
• getrange：获取值的范围，类似java中的substring
• setrange：覆盖指定位置的值
• setex：设置键值&过期时间（秒
• getset：以新换旧，设置新值同时返回旧值

数据结构

简单动态字符串，是可以修改的字符串，采用分配冗余空间的方式来减少内存的频繁分配 。内部为当前字符串实际分配的空间capacity一般要高于实际字符串长度len。当字符串长度小于1M时，扩容都是加倍现有的空间，如果超过1M，扩容时一次会多扩容1M的空间。

redis列表（List）

单键多值，双向链表实现。

命令

• lpush/rpush：从左边或者右边插入一个或多个值
• lrange：从列表左边获取指定范围内的值
• lpop/rpop：从左边或者右边弹出多个元素
• rpoplpush：从一个列表右边弹出一个元素放到另外一个列表中
• lindex：获取指定索引位置的元素（从左到右）
• llen：获得列表长度
• linsert：在某个值的前或者后面插入一个值
• lrem：删除指定数量的某个元素
• lset：替换指定位置的值

数据结构

快速链表quickList

多个zipList使用双向指针串起来使用

redis集合（Set）

set是可以自动排重的，底层实际是一个value为null的hash表，收益添加，删除，查找复杂度都是O(1)

命令

• sadd：添加一个或多个元素
• smembers：取出所有元素
• sismember：判断集合中是否有某个值
• scard：返回集合中元素的个数
• srem：删除多个元素
• spop：随机弹出多个值
• srandmember：随机获取多个元素，不会从集合中删除
• smove：将某个原创从一个集合移动到另一个集合
• sinter：取多个集合的交集
• sinterstore：将多个集合的交集放到一个新的集合中
• sunion：取多个集合的并集，自动去重
• sunionstore：将多个集合的并集放到一个新的集合中
• sdiff：取多个集合的差集
• sdiffstore：将多个集合的差集放到一个新的集合中

数据结构

set数据结构是字典，字典是用hash表实现的。内部使用hash结构，所有的value都指向同一个内部值。

redis哈希（hash）

Redis hash是一个键值对集合，是一个string类型的field和value的映射表，hash特别适合用于存储对象

常用命令

• hset：设置多个field的值
• hget：获取指定filed的值
• hgetall：返回hash表所有的域和值
• hexists：判断给定的field是否存在，1：存在，0：不存在
• hkeys：列出所有的filed
• hvals：列出所有的value
• hlen：返回filed的数量
• hincrby：filed的值加上指定的增量
• hsetnx：当filed不存在的时候，设置filed的值

数据结构

Hash类型对应的数据结构是2种：ziplist（压缩列表），hashtable（哈希表）。
当field-value长度较短个数较少时，使用ziplist，否则使用hashtable。

redis有序集合zset（sorted set）

redis有序集合zset是一个没有重复元素的字符串集合。有序集合的每个成员都关联了一个评分（score），这个评分（score）被用来按照从最低分到最高分的方式排序集合中的成员。集合的成员是唯一的，但是评分是可以重复的。

常用命令

• zadd：添加元素
• zrange：score升序，获取指定索引范围的元素
• zrevrange：score降序，获取指定索引范围的元素
• zrangebyscore：按照score升序，返回指定score范围内的数据
• zrevrangebyscore：按照score降序，返回指定score范围内的数据
• zincrby：为指定元素的score加上指定的增量
• zrem：删除集合中多个元素
• zremrangebyrank：根据索引范围删除元素
• zremrangebyscore：根据score的范围删除元素
• zcount：统计指定score范围内元素的个数
• zrank：按照score升序，返回某个元素在集合中的排名
• zrevrank：按照score降序，返回某个元素在集合中的排名
• zscore：返回集合中指定元素的score

数据结构

• hash表
  • 类似于java中的Map，key为集合中的元素，value为元素对应的score，可以用来快速定位元素定义的score，时间复杂度为O(1)
• 跳表
  • 跳表在原来的有序链表上加上了多级索引，实现简单，插入、删除、查找的复杂度均为O(logN)
  • 有序链表基础上增加“跳跃”功能
  • 空间换时间
  • 层：就是我们假设的抽象出来的新链表。

Bitmaps:位操作字符串

可以实现对位的操作：

• Bitmaps本身不是一种数据类型， 实际上它就是字符串（key-value） ， 但是它可以对字符串的位进行操作，字符串中每个字符对应1个字节，也就是8位，一个字符可以存储8个bit位信息。
• Bitmaps单独提供了一套命令， 所以在Redis中使用Bitmaps和使用字符串的方法不太相同。 可以把Bitmaps想象成一个以位为单位的数组， 数组的每个单元只能存储0和1， 数组的下标在Bitmaps中叫做偏移量。

常用命令

• setbit：设置某个偏移量的值（0或1）
• getbit：获取某个偏移位的值
• bitcount：统计bit位都为1的数量
• bittop：对一个多个bitmaps执行位操作

bitmaps与set比较

• set 和 Bitmaps 存储一天活跃用户对比
  • 使用 Bitmaps 能节省很多的内存空间， 尤其是随着时间推移节省的内存还是非常可观的。
• set 和 Bitmaps 存储独立用户空间对比
  • 假如该网站每天的独立访问用户很少， 例如只有 10 万（大量的僵尸用户）， 那么两者的对比如下表所示， 很显然， 这时候使用 Bitmaps 就不太合适了， 因为基本上大部分位都是 0。

HyperLoglog

是用来做基数统计的算法，HyperLogLog 的优点是：在输入元素的数量或者体积非常非常大时，计算基数所需的空间总是固定的、并且是很小的。

命令

• pfadd：添加多个元素
• pfcount：获取多个HLL合并后元素的个数
• pfmerge：将多个HLL合并后元素放入另外一个HLL

Geographic

该类型，就是元素的 2 维坐标，在地图上就是经纬度，redis基于该类型，提供了经纬度设置、查询、范围查询、距离查询，经纬度Hash等常见操作。

命令

• geoadd：添加多个位置的经纬度
• geopos：获取多个位置的坐标值
• geodist：获取两个位置的直线距离
• georadius：以给定的经纬度为中心，找出某一半径内的元素

发布和订阅

发布和订阅

消息通信模式：

• 发布者发布消息
• 订阅者接收消息

redis发布和订阅

• 客户端订阅频道：客户端A,B,C—订阅 —>channel1频道
• 当给这个频道发布消息后，消息就会发送给订阅的客户端

发布和订阅的命令行实现

• 订阅命令：subscribe channel1
• 给channel1发布消息hello：publish channel1 helloworld
• 切换到订阅窗口即可看到

发布和订阅常用命令

• subscribe：订阅一个或者多个频道
  • 订阅msg和chat_room两个频道：subscribe msg chat_root
• publish：发布消息到指定的频道
  • publish msg “hello”
• psubscribe：订阅一个或多个符合给定模式的频道
  • 每个模式以 * 作为匹配符，eg:it* 匹配以it开头的频道
  • psubscribe news.* tweet.*

Jedis

maven

<dependency>
    <groupId>redis.clients</groupId>
    <artifactId>jedis</artifactId>
    <version>2.9.3</version>
</dependency>

api

package jedis;

import org.junit.After;
import org.junit.Before;
import org.junit.Test;
import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisPubSub;

import java.util.List;
import java.util.Map;
import java.util.Set;
import java.util.concurrent.TimeUnit;

/**
 * @author： 308158
 * @description: TODO
 * @date: Created in 2023-8-17 13:58
 */
public class JedisDemo {


    Jedis jedis;

    @Before
    public void before(){
        this.jedis = new Jedis("1.1.1.1", 6379);
    }

    @After
    public void after(){
        //关闭jedis
        this.jedis.close();
    }

    /** 测试redis是否连通 */
    @Test
    public void test1(){
        String ping = jedis.ping();
        System.out.println(ping);
    }

    /** string类型测试 */
    @Test
    public void stringTest(){
        jedis.set("site", "http://");
        System.out.println(jedis.get("site"));
        System.out.println(jedis.ttl("site"));
    }

    /** list类型测试 */
    @Test
    public void listTest(){
        jedis.rpush("courses", "java", "spring", "springmvc");
        List<String> courses = jedis.lrange("courses", 0, -1);
        for (String course : courses) {
            System.out.println(course);
        }
    }

    /** set类型 */
    @Test
    public void setTest(){
        jedis.sadd("users","tom","jack","ready");
        Set<String> users = jedis.smembers("users");
        for (String user : users) {
            System.out.println(user);
        }
    }

    /** hash类型测试 */
    @Test
    public void hashTest() {
        jedis.hset("user:1001", "id", "1001");
        jedis.hset("user:1001", "name", "张三");
        jedis.hset("user:1001", "age", "30");
        Map<String, String> userMap = jedis.hgetAll("user:1001");
        System.out.println(userMap);
    }

    /** zset类型测试 */
    @Test
    public void zsetTest() {
        jedis.zadd("languages", 100d, "java");
        jedis.zadd("languages", 95d, "c");
        jedis.zadd("languages", 70d, "php");
        Set<String> languages = jedis.zrange("languages", 0, -1);
        System.out.println(languages);
    }

    /** 订阅消息 */
    @Test
    public void subscribeTest() throws InterruptedException {
        //subscribe(消息监听器,频道列表)
        jedis.subscribe(new JedisPubSub() {
            @Override
            public void onMessage(String channel, String message) {
                System.out.println(channel + ":" + message);
            }
        }, "sitemsg");
        TimeUnit.HOURS.sleep(1);
    }

    /** 发布消息*/
    @Test
    public void publishTest() {
        jedis.publish("sitemsg", "hello redis");
    }

}

springboot整合redis

maven配置

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
    <version>1.5.22.RELEASE</version>
</dependency>

配置信息

#redis服务器ip
spring.redis.host=192.168.1.1
#redis服务器端口
spring.redis.port=6379
#redis密码
spring.redis.password=root
#连接超时时间
spring.redis.timeout=6000
#redis默认情况下有16个分片，默认0
spring.redis.database=0

RedisTemplate工具类操作redis

package jedis;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

import java.util.HashMap;
import java.util.List;
import java.util.Map;
import java.util.Set;

/**
 * @author： 308158
 * @description: TODO
 * @date: Created in 2023-8-17 14:17
 */
@RestController
@RequestMapping("/redis")
public class RedisController {

    @Autowired
    private RedisTemplate<String, String> redisTemplate;

    @RequestMapping("/stringTest")
    public String stringTest() {
        this.redisTemplate.delete("name");
        this.redisTemplate.opsForValue().set("name", "路人");
        return this.redisTemplate.opsForValue().get("name");
    }

    @RequestMapping("/listTest")
    public List<String> listTest() {
        this.redisTemplate.delete("names");
        this.redisTemplate.opsForList().rightPushAll("names", "刘德华", "张学友", "郭富城", "黎明");
        return this.redisTemplate.opsForList().range("names", 0, -1);
    }

    @RequestMapping("setTest")
    public Set<String> setTest() {
        this.redisTemplate.delete("courses");
        this.redisTemplate.opsForSet().add("courses", "java", "spring", "springboot");
        return this.redisTemplate.opsForSet().members("courses");
    }

    @RequestMapping("hashTest")
    public Map<Object, Object> hashTest() {
        this.redisTemplate.delete("userMap");
        Map<String, String> map = new HashMap<>();
        map.put("name", "路人");
        map.put("age", "30");
        this.redisTemplate.opsForHash().putAll("userMap", map);
        return this.redisTemplate.opsForHash().entries("userMap");
    }

    @RequestMapping("zsetTest")
    public Set<String> zsetTest() {
        this.redisTemplate.delete("languages");
        this.redisTemplate.opsForZSet().add("languages", "java", 100d);
        this.redisTemplate.opsForZSet().add("languages", "c", 95d);
        this.redisTemplate.opsForZSet().add("languages", "php", 70);
        return this.redisTemplate.opsForZSet().range("languages", 0, -1);
    }
}
}

redis 事务

定义

• redis事务是一个单独的隔离操作，事务中的所有命令都会序列化、按顺序地执行，事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
• 主要作用：串联多个命令防止别的命令插队。

Multi，Exec，discard

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

redis事务分2个阶段：组队阶段、执行阶段

• 组队阶段：只是将所有命令加入命令队列
• 执行阶段：依次执行队列中的命令，在执行这些命令的过程中，不会被其他客户端发送的请求命令插队或者打断。

相关的命令

multi：标记一个事务块的开始

事务块内的多条命令会按照先后顺序被放进一个队列当中，最后由 exec 命令原子性(atomic)地执行

exec：执行所有事务块内的命令

假如某个(或某些) key 正处于 watch 命令的监视之下，且事务块中有和这个(或这些) key 相关的命令，那么 exec 命令只在这个(或这些) key 没有被其他命令所改动的情况下执行并生效，否则该事务被打断(abort)。

返回值：
事务块内所有命令的返回值，按命令执行的先后顺序排列。
当操作被打断时，返回空值 nil 。

discard：取消事务

取消事务，放弃执行事务块内的所有命令。

返回值：总是返回ok

事务的错误处理

case1：组队中命令有误，导致所有命令取消执行

组队中某个命令出现了错误报告，执行时整个队列中所有的命令都会被取消

case2：组队中没有问题，执行中部分成功部分失败

事务冲突的问题

悲观锁

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

乐观锁

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

watch key [key…]

在执行multi之前，先执行watch key1 [key2 …]，可以监视一个或者多个key，若在事务的exec命令之前这些key对应的值被其他命令所改动了，那么事务中所有命令都将被打断，即事务所有操作将被取消执行 。

unwatch:取消监视

如果在执行 WATCH 命令之后， EXEC 命令或 DISCARD 命令先被执行了的话，那么就不需要再执行UNWATCH 了。
因为 EXEC 命令会执行事务，因此 WATCH 命令的效果已经产生了；而 DISCARD 命令在取消事务的同时也会取消所有对 key 的监视，因此这两个命令执行之后，就没有必要执行 UNWATCH 了。

redis事务三特性

单独的隔离操作

事务中的所有命令都会序列化、按顺序地执行，事务在执行过程中，不会被其他客户端发送来的命令请求所打断

没有隔离级别的概念

队列中的命令没有提交（exec）之前，都不会实际被执行，因为事务提交前任何指令都不会被实际执行。

不能保证原子性

事务中如果有一条命令执行失败，后续的命令仍然会被执行，没有回滚。
如果在组队阶段，有1个失败了，后面都不会成功；如果在组队阶段成功了，在执行阶段有那个命令失败就这条失败，其他的命令则正常执行，不保证都成功或都失败。

redis持久化–RDB

定义

在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是键快照文件直接读到内存里。

备份如何执行

• Redis会单独创建（fork）一个子进程进行持久化，将数据写入到一个临时文件中，待持久化过程都结束后，再用这个临时文件替换上次持久化好的文件。
• 整个过程中，主进程是不进行任何IO操作的，如果需要进行大规模的恢复，且对数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。
• 缺点是最后一次持久化后的数据可能丢失。

Fork

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

RDB持久化流程

bgsave命令给到父进程

• 如果有其他子进程正在执行直接返回
• 否则，fork一个子进程，生成rdb文件并通知父进程

配置

• 指定备份文件的名称：redis.conf中，默认为dump.rdb
• 指定备份文件存放的目录：redis.conf中，默认dir ./
• 触发rdb备份
  • 自动备份，需配置备份规则：redis.conf
    • save用来配置备份的规则：格式：save 秒钟 写操作次数
  • 手动执行命令备份
    • save：只管保存，其他不管，全部阻塞，手动保存，不建议使用
    • bgsave：后台异步进行快照操作，快照同时还可以相应客户端情况，可以通过lastsave命令获取最后一次成功生成快照时间
  • flushall命令
    • 执行flushall命令，也会产生dump.rdb文件，但里面是空的，无意义
• stop-writes-on-bgsave-error：当磁盘满时，是否关闭redis的写操作
• rdbcompression：rdb备份是否开启压缩
• rdbchecksum：是否检查rdb备份文件的完整性

rdb备份和恢复

• rdb备份
  • 通过config get dir 查询rdb文件的目录
  • 然后将rdb的备份文件*.rdb文件拷贝到别的地方
• rdb的恢复
  • 关闭redis
  • 先把备份的文件拷贝到工作目录
  • 启动redis，备份数据直接加载，数据被恢复

优劣势

优势

• 适合大规模数据恢复
• 对数据完整性和一致性要求不高更适合使用
• 节省磁盘空间
• 恢复速度快

劣势

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

停止rdb

动态停止RDB：redis-cli config set save “” #save后给空值，表示禁用保存策略

redis事务三特性

单独的隔离操作

事务中的所有命令都会序列化、按顺序地执行，事务在执行过程中，不会被其他客户端发送来的命令请求所打断

没有隔离级别的概念

队列中的命令没有提交（exec）之前，都不会实际被执行，因为事务提交前任何指令都不会被实际执行。

不能保证原子性

事务中如果有一条命令执行失败，后续的命令仍然会被执行，没有回滚。
如果在组队阶段，有1个失败了，后面都不会成功；如果在组队阶段成功了，在执行阶段有那个命令失败就这条失败，其他的命令则正常执行，不保证都成功或都失败。

redis持久化–RDB

定义

在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是键快照文件直接读到内存里。

备份如何执行

• Redis会单独创建（fork）一个子进程进行持久化，将数据写入到一个临时文件中，待持久化过程都结束后，再用这个临时文件替换上次持久化好的文件。
• 整个过程中，主进程是不进行任何IO操作的，如果需要进行大规模的恢复，且对数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。
• 缺点是最后一次持久化后的数据可能丢失。

Fork

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

RDB持久化流程

bgsave命令给到父进程

• 如果有其他子进程正在执行直接返回
• 否则，fork一个子进程，生成rdb文件并通知父进程

配置

• 指定备份文件的名称：redis.conf中，默认为dump.rdb
• 指定备份文件存放的目录：redis.conf中，默认dir ./
• 触发rdb备份
  • 自动备份，需配置备份规则：redis.conf
    • save用来配置备份的规则：格式：save 秒钟 写操作次数
  • 手动执行命令备份
    • save：只管保存，其他不管，全部阻塞，手动保存，不建议使用
    • bgsave：后台异步进行快照操作，快照同时还可以相应客户端情况，可以通过lastsave命令获取最后一次成功生成快照时间
  • flushall命令
    • 执行flushall命令，也会产生dump.rdb文件，但里面是空的，无意义
• stop-writes-on-bgsave-error：当磁盘满时，是否关闭redis的写操作
• rdbcompression：rdb备份是否开启压缩
• rdbchecksum：是否检查rdb备份文件的完整性

rdb备份和恢复

• rdb备份
  • 通过config get dir 查询rdb文件的目录
  • 然后将rdb的备份文件*.rdb文件拷贝到别的地方
• rdb的恢复
  • 关闭redis
  • 先把备份的文件拷贝到工作目录
  • 启动redis，备份数据直接加载，数据被恢复

优劣势

优势

• 适合大规模数据恢复
• 对数据完整性和一致性要求不高更适合使用
• 节省磁盘空间
• 恢复速度快

劣势

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

停止rdb

动态停止RDB：redis-cli config set save “” #save后给空值，表示禁用保存策略

redis持久化 – AOF

定义

以日志的形式来记录每个写操作（增量保存），将redis执行过的所有写指令记录下来（读操作不记录），只允追加文件但不可改写文件，redis启动之初会读取该文件重新构造数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

持久化流程

• 客户端的请求写命令会被append追加到AOF缓冲区内
• AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中
• AOF文件大小超过重写策略或手动重写时，会对AOF文件进行重写（rewrite），压缩AOF文件容量
• redis服务器重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的

默认不开启

• redis.conf文件中对AOF进行配置
  • appendonly no # 是否开启AOF，yes：开启，no：不开启，默认为no
  • appendfilename “appendonly.aof” # aof文件名称，默认为appendonly.aof
  • dir ./ # aof文件所在目录，默认./，表示执行启动命令时所在的目录，比如在/opt目录中，去执行
  • redis-server /etc/redis.conf 来启动redis，那么dir此时就是/opt目录
• aof和rdf同时开启，系统默认取AOF数据（数据不会存在丢失）

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.config配置AOF同步的频率

• appendfsync always：每次写入立即同步
  • 始终同步，每次redis的写入都会立刻记入日志；性能较差但数据完整性比较好。
• appendfsync everysec：每秒同步
  • 每秒同步，每秒记录日志一次，如果宕机，本秒数据可能丢失；更新的命令会放在内存中AOF缓冲区，每秒将缓冲区的命令追加到AOF文件
• appendfsync no：不主动同步
  • redis不主动进行同步，把同步交给操作系统。

rewrite压缩

rewrite压缩

AOF采用文件追加方式，文件会越来越大，为了避免出现此情况，新增了重写机制。

重写机制：当AOF文件的大小超过锁审定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof触发重写

重写原理实现

AOF文件持续增长而过大时，会fork出一条新进程来将文件重写（也是先写临时文件，最后在rename替换旧文件），redis4.0版本后的重写，是指就把rdb的快照，以二进制的形式附在新的aof头部，作为已有的历史数据，替换掉原来的流水账操作。

触发机制 何时重写

bgrewriteaof：手动触发重写

从 Redis 2.4 开始， AOF 重写由 Redis 自行触发， bgrewriteaof 仅仅用于手动触发重写操作。
redis会记录上次重写的aof大小，默认配置是当aof文件大小是上次rewrite后大小的2倍且文件大于64M时触发。
重写虽然可以节约大量磁盘空间，减少恢复时间，但是每次重写还是有一定负担的，因此设置redis满足一定条件才会进行重新。

auto-aof-rewrite-percentage：设置重写基准值

设置重写的基准值，默认100，当文件达到100%时开始重写（文件是原来重写后文件的2倍时重写）。

auto-aof-rewrite-min-size：设置重写基准值

设置重写的基准值，默认64MB，AOF文件大小超过这个值开始重写。

重写流程

• 手动执行 bgrewriteaof 命令触发重写，判断是否当前有bgfsave或bgrewriteaof在运行，如果有，则等待该命令结束后再继续执行
• 主进程fork出子进程执行重写操作，保证主进程不会阻塞
• 子进程遍历redis内存中的数据到临时文件，客户端的写请求同时写入aof_buf缓冲区和aof_rewrite_buf重写缓冲区保证原AOF文件完整性以及新AOF文件生成期间的新的数据修改动作不会丢失
• 子进程写完新的AOF文件后，向主进程发送信号，父进程更新统计信息
• 主进程把aof_rewrite_buf中的数据写入到新的AOF文件
• 使用新的AOF文件覆盖旧的AOF文件，完成AOF重写

no-appendfsync-on-rewrite：重写时，不会执行appendfsync操作

• 该参数表示在正在进行AOF重写时不会将AOF缓冲区中的数据同步到旧的AOF文件磁盘，也就是说在进行AOF重写的时候，如果此时有写操作进来，此时写操作的命令会放在aof_buf缓存中（内存中），而不会将其追加到旧的AOF文件中，这么做是为了避免同时写旧的AOF文件和新的AOF文件对磁盘产生的压力。
• 默认是ON，表示关闭，即在AOF重写时，会对AOF缓冲区中的数据做同步磁盘操作，这在很大程度上保证了数据的安全性。但在数据量很大的场景，因为两者都会消耗磁盘IO，对磁盘的影响较大，可以将其设置为“yes”减轻磁盘压力，但在极端情况下可能丢失整个AOF重写期间的数据。
• 如果no-appendfsync-on-rewrite为yes，不写入aof文件，只写入缓存，用户请求不会阻塞，但是在这段时间如果宕机会丢失这段时间的缓存数据。（降低数据安全性，提高性能）如果no-appendfsync-on-rewrite为no，还是会把数据库往磁盘里刷，但是遇到重写操作，可能会发生阻塞。（数据安全，但是性能降低）

优劣势

优势

• 备份机制更稳健，丢失数据概率更低
• 可读的日志文本，通过操作AOF文件，可以处理误操作

劣势

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

总结

• AOF文件是一个只进行追加的日志文件
• Redis可以在AOF文件体积变得过大时，自动地在后台对AOF文件进行重写
• AOF文件有序地保存了对数据库执行的所有写入操作，这些写入操作以redis协议的格式保存，因此AOF文件的内容非常容易被人读懂，对文件进行分析也很轻松。
• 对于相同的数据集来说，AOF文件的体积通常要大于RDB文件的体积
• 根据所使用的fsync策略，AOF的速度可能会慢于RDB

redis主从复制

定义

主机更新后根据配置和策略，自动同步到备机的master/slave机制，Master以写为主，Slave以读为主。

作用

• 读写分离，性能扩展，降低主服务器的压力
• 容灾，快速恢复，主机挂掉时，从机变为主机

用法

配置1主2从

• master（主）：6379
• slave1（从）：6380
• slave2（从）：6381

配置主从

• 创建案例工作目录：master-slave
  • 执行下面命令创建 /opt/master-slave 目录，本次所有操作，均在 master-slave 目录进行。
• 将redis.conf复制到master-slave目录
• 创建master的配置文件：redis-6379.conf
• 创建slave1的配置文件：redis-6380.conf
• 创建slave2的配置文件：redis-6381.conf
• 启动master ：redis-server 命令
• 启动slave1
• 启动slave2
• 查看主机的信息 ：
  • 连接主机：redis-cli -h xx.xx.
  • 查看信息：info Repliacation
• 查看slave1的信息
• 同样查看slave2的信息
• 验证主从同步效果
  • flushdb
  • set name ready
  • 查看从机是否把数据同步过来了

主从复制原理

• slave启动成功连接到master后，会给master发送数据同步消息（发送sync命令）
• master接收到slave发来的数据同步消息后，把主服务器的数据进行持久化到rdb文件，同时会收集接收到的用于修改数据的命令，master将传rdb文件发送给你slave，完成一次完全同步
• 全量复制：而slave服务在接收到master发来的rdb文件后，将其存盘并加载到内存
• 增量复制：master继续将收集到的修改命令依次传给slave，完成同步
• 但是只要重新连接master，一次完全同步（全量复制）将会被自动执行

小结

• 主redis挂掉以后情况会如何？
  • 主机挂掉后，从机会待命
• 从挂掉后又恢复了，会继续从主同步数据么？
  • 会的，当从重启之后，会继续将中间缺失的数据同步过来。

常用的主从结构

一主二从

从机可以采用命令的方式配置

• 创建案例工作目录：master-slave
• 将redis.conf复制到master-slave
• 创建master的配置文件：redis-6379.conf
• 创建slave1的配置文件：redis-6380.conf
• 创建slave2的配置文件：redis-6381.conf
• 启动master ，slave1 ，slave2 :redis-server 命令
• 分别登陆3台机器，查看各自主从信息 ：info replication
• 配置slave1为master的从库
  • 连接到slave1：redis-cli
  • 设置master密码：config set
  • 指定slave1作为master从机：slaveof
• 配置slave2为master的从库
• 再来看看master的主从信息

注意：通过 slaveof 命令指定主从的方式，slave重启之后主从配置会失效，所以，重启后需要在slave上重新通过 slaveof 命令进行设置。中途通过 slaveof 变更转向，本地的数据会被清除，会从新的master重新同步数据。

薪火相传

若master下面挂很多slave，master会有压力，实际上slave下面也可以挂slave，配置和上面的类似。

反客为主

当master挂掉之后，可以从slave中选择一个作为主机。

• 执行命令：slaveof no one
• slave1就变成主机了，然后再去其他slave上面执行 slaveof 命令将其挂在slave1上。

缺点：需要手动去执行命令去操作，不是太方便。
其他方案：哨兵模式，主挂掉之后，自动从slave中选举一个作为主机，自动实现故障转移。

哨兵模式

定义

能够自动监控master是否发生故障，如果故障了会根据投票数从slave中挑选一个作为master，其他的slave会自动转向同步新的master，实现故障自动转义。

原理

• sentinel会按照指定的频率给master发送ping请求，看看master是否还活着
• 若master在指定时间内未正常响应sentinel发送的ping请求，sentinel则认为master挂掉了
• 存在误判：可能master并没有挂，只是sentinel和master之间的网络不通导致，导致ping失败。
• 为了避免误判，通常会启动多个sentinel，一般是奇数个，比如3个，那么可以指定当有多个sentinel都觉得master挂掉了，此时才断定master真的挂掉了，通常这个值设置为sentinel的一半，比如sentinel的数量是3个，那么这个量就可以设置为2个。
• 当多个sentinel经过判定，断定master确实挂掉了
• sentinel会进行故障转移：会从slave中投票选出一个服务器，将其升级为新的主服务器， 并让失效主服务器的其他从服务器slaveof指向新的主服务器；
• 当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器。

用法

需求：配置1主2从3个哨兵

最少有2个哨兵认为主的挂掉了，才进行故障转移。

• master：6379
• slave1:6380
• slave2:6381
• sentinel1:26379
• sentinel2:26380
• sentinel3:26381

步骤：

• 创建案例工作目录 sentinel
• 将redis.conf复制到sentinel目录
• 创建master的配置文件：redis-6379.conf
• 创建slave1的配置文件：redis-6380.conf
• 创建slave2的配置文件：redis-6381.conf
• 启动master、slave1、slave2
• 配置slave1为master的从库
• 配置slave2为master的从库
• 验证主从复制是否正常
• 创建sentinel1的配置文件：sentinel-26379.conf
• 创建sentinel2的配置文件：sentinel-26380.conf
• 创建sentinel3的配置文件：sentinel-26381.conf
• 启动3个sentinel
• 分别查看3个sentinel的信息 ：info sentinel
• 验证故障自动转移是否成功
  • step1：在master中执行下面命令，停止master ：shutdown
  • step2：等待2分钟，等待完成故障转移
    • sentinel中的配置：down-after-milliseconds：60 ：表示判断主机下线时间是60秒，所以等2分钟，让系统先自动完成故障转移
  • step3：查看slave1的主从信息 info replication
  • step4：查看slave2的主从信息
  • step5：验证下slave1和slave2是否同步
• 恢复旧的master：当旧的master恢复之后，会自动挂在新的master下面
  • step1：执行命令，启动旧的master ：redis-server
  • step2：执行命令，连接旧的master
  • step3：执行命令，查看其主从信息

springboot整合sentinel模式

配置

# redis sentinel主服务名称，这个可不是随便写的哦，来源于：sentinel配置文件中sentinel monitor后面跟的那个名称
spring.redis.sentinel.master=mymaster
# sentinel节点列表(host:port)，多个之间用逗号隔开
spring.redis.sentinel.nodes=192.168.200.129:26379,192.168.200.129:26380,192.168.200.129:26381
# sentinel密码
#spring.redis.sentinel.password=
# 连接超时时间（毫秒）
spring.redis.timeout=60000
# Redis默认情况下有16个分片，这里配置具体使用的分片，默认是0
spring.redis.database=0

@RequestMapping(value = "/info", produces = MediaType.TEXT_PLAIN_VALUE)
public String info() {
    Object obj = this.redisTemplate.execute(new RedisCallback