缓存之Redis超级详细学习笔记

一. NoSQL概述

1.1NoSQL适用场景

• 对数据高并发的读写
• 海量数据的读写
• 对数据搞可扩展性的

1.2 NoSQl不适用场景

• 需要事务的支持
• 基于sql的结构化查询储存,处理复杂的关系, 需要即席查询.

1.3 Memcache、Redis、MongoDB三种常见的NoSQL数据库

1.3.1 Memcache

• 很早出现的NoSql数据库
• 数据都在内存中， 一般不持久化
• 支持简单的key-value模式，支持类型单一
• 一般是作为缓存数据库辅助持久化的数据库

1.3.2 Redis

• 几乎覆盖了Memcache的绝大部分功能
• 数据都在内存中,支持持久化,主要用作备份恢复
• 除了支持简单呃key-value模式,还支持多种数据结构的存储,比如list、set、hash、zset等
• 一般是作为缓存数据库的辅助持久化的数据库

1.3.3 MongoDB

• 高性能、开源、模式自由的文档型数据库
• 数据都在内存中， 如果内存不足，把不常用的数据保存到硬盘
• 虽然都是key-value模式，但是对value（尤其是json
• 提供了丰富的查询功能
• 支持二进制数据及大型对象
• 可以根据数据的特点替代RDBMS，成为独立的数据库。或者配合RDBMS，存储特定的数据

二. Redis安装及使用

2.1 Redis概述

• Redis是一个开源的key-value存储系统。
• 和Memcached类似，它支持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合)、zset(sorted set --有序集合)和hash（哈希类型）。
• 这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。
• 在此基础上，Redis支持各种不同方式的排序。
• 与memcached一样，为了保证效率，数据都是缓存在内存中。
• 区别的是Redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件。
• 并且在此基础上实现了master-slave(主从)同步。

2.2 应用场景

2.2.1 配合关系型数据库做高速缓存

• 高频次， 热门访问的数据，降低数据库IO
• 分布式架构，做session共享

2.2.2 多样的数据结构存储持久化数据

2.3 Redis安装

Redis官方网站	Redis中文官方网站
http://redis.io	http://redis.cn/

2.3.1 准备工作：下载安装最新版的gcc编译器

安装C 语言的编译环境

yum install centos-release-scl scl-utils-build

yum install -y devtoolset-8-toolchain

scl enable devtoolset-8 bash

测试 gcc版本

gcc --version

下载redis-6.2.1.tar.gz放/opt目录

解压命令：tar -zxvf redis-6.2.1.tar.gz

解压完成后进入目录：cd redis-6.2.1

在redis-6.2.1目录下再次执行make命令（只是编译好）

如果没有准备好C语言编译环境，make 会报错—Jemalloc/jemalloc.h：没有那个文件

解决方案：运行make distclean

在redis-6.2.1目录下再次执行make命令（只是编译好）

跳过make test 继续执行: make install

2.3.2 安装目录：/usr/local/bin

查看默认安装目录：

redis-benchmark: 性能测试工具，可以在自己本机运行，看看自己本机性能如何

redis-check-aof： 修复有问题的AOF文件，rdb和aof后面讲

redis-check-dump： 修复有问题的dump.rdb文件

redis-sentinel： Redis集群使用

redis-server： Redis服务器启动命令

redis-cli： 客户端，操作入口

2.3.3 前台启动（不推荐）

前台启动，命令行窗口不能关闭，否则服务器停止

2.3.4 后台启动（推荐）

备份redis.conf

拷贝一份redis.conf到其他目录

cp /opt/redis-3.2.5/redis.conf /myredis

后台启动设置daemonize no改成yes

修改redis.conf(128行)文件将里面的daemonize no 改成 yes，让服务在后台启动

Redis启动

redis-server /myredis/redis.conf

1.1.4.4. 用客户端访问：redis-cli

1.1.4.5. 多个端口可以：redis-cli -p6379

1.1.4.6. 测试验证：ping

1.1.4.7. Redis关闭

单实例关闭：redis-cli shutdown

也可以进入终端后再关闭

多实例关闭，指定端口关闭：redis-cli -p 6379 shutdown

2.4 Redis介绍相关知识

• 默认16个数据库，类似数组下标从0开始，初始默认使用0号库
• 使用命令 select 来切换数据库。如: select 8
• 统一密码管理，所有库同样密码。
• dbsize 查看当前数据库的key的数量
• flushdb 清空当前库
• flushall 通杀全部库

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

多路复用是指使用一个线程来检查多个文件描述符（Socket）的就绪状态，比如调用select和poll函数，传入多个文件描述符，如果有一个文件描述符就绪，则返回，否则阻塞直到超时。得到就绪状态后进行真正的操作可以在同一个线程里执行，也可以启动线程执行（比如使用线程池）
串行 vs 多线程+锁（memcached） vs 单线程+多路IO复用(Redis)

2.5 常用五大数据类型

redis常见数据类型操作命令中文手册地址

2.5.1 Redis键(key)

keys 查看当前库所有key (匹配：keys *1)

exists key 判断某个key是否存在

type key 查看你的key是什么类型

del key 删除指定的key数据

unlink key 根据value选择非阻塞删除

仅将keys从keyspace元数据中删除，真正的删除会在后续异步操作。

expire key 10 10秒钟：为给定的key设置过期时间

ttl key 查看还有多少秒过期，-1表示永不过期，-2表示已过期

select 命令切换数据库

dbsize 查看当前数据库的key的数量

flushdb 清空当前库

flushall 通杀全部库

2.5.2 Redis字符串(String)

1.简介

String是Redis最基本的类型，你可以理解成与Memcached一模一样的类型，一个key对应一个value。

String类型是二进制安全的。意味着Redis的string可以包含任何数据。比如jpg图片或者序列化的对象。

String类型是Redis最基本的数据类型，一个Redis中字符串value最多可以是512M

2.常用命令

set key value添加键值对

NX：当数据库中key不存在时，可以将key-value添加数据库

XX：当数据库中key存在时，可以将key-value添加数据库，与NX参数互斥

EX：key的超时秒数

PX：key的超时毫秒数，与EX互斥

get key查询对应键值

append key value 将给定的 追加到原值的末尾

strlen key 获得值的长度

setnx key value 只有在 key 不存在时 设置 key 的值

原子操作

incr key 将 key 中储存的数字值增1, 只能对数字值操作，如果为空，新增值为1

decr key 将 key 中储存的数字值减1, 只能对数字值操作，如果为空，新增值为-1

incrby / decrby key <步长> 将 key 中储存的数字值增减。自定义步长。例如: incrby k1 10 ( 对k1+10操作 )

mset key1 value1 key2 value2 … 同时设置一个或多个 key-value对

mget key1 key2 key3 … 同时获取一个或多个 value

msetnx key1 value1 key2 value2 … 同时设置一个或多个 key-value 对，当且仅当所有给定 key 都不存在。

原子性，有一个失败则都失败

getrange key <起始位置><结束位置>

获得值的范围，类似java中的substring，前包，后包

setrange key <起始位置> value

用 value 覆写 key 所储存的字符串值，从<起始位置>开始 (索引从0开始)。

setex key <过期时间> value 设置键值的同时，设置过期时间，单位秒。

getset key value 以新换旧，设置了新值同时获得旧值。

3.数据结构

String的数据结构为简单动态字符串(Simple Dynamic String,缩写SDS)。是可以修改的字符串，内部结构实现上类似于Java的ArrayList，采用预分配冗余空间的方式来减少内存的频繁分配.

2.5.3 Redis列表(List)

1.简介

单键多值

Redis 列表是简单的字符串列表，按照插入顺序排序。你可以添加一个元素到列表的头部（左边）或者尾部（右边）。

它的底层实际是个双向链表，对两端的操作性能很高，通过索引下标的操作中间的节点性能会较差。

2.常用命令

lpush/rpush key value1 value2 value3 … 从左边/右边插入一个或多个值。

lpop/rpop key 从左边/右边吐出一个值。值在键在，值光键亡。

rpoplpush key1 key2 ， 从 key1 列表右边吐出一个值，插到 key2 列表左边。

lrange key start stop ：按照索引下标获得元素(从左到右)

lrange mylist 0 -1 ：0左边第一个，-1右边第一个，（0-1表示获取所有）

lindex key index ： 按照索引下标获得元素(从左到右)

llen key： 获得列表长度

linsert key before value newvalue： 在 value 的后面插入 newvalue 插入值

lrem key n value： 从左边删除n个value(从左到右)

lset key index value： 将列表key下标为index的值替换成value

3.数据结构

List的数据结构为快速链表quickList。

首先在列表元素较少的情况下会使用一块连续的内存存储，这个结构是ziplist，也即是压缩列表。

它将所有的元素紧挨着一起存储，分配的是一块连续的内存。

当数据量比较多的时候才会改成quicklist。

因为普通的链表需要的附加指针空间太大，会比较浪费空间。比如这个列表里存的只是int类型的数据，结构上还需要两个额外的指针prev和next。

Redis将链表和ziplist结合起来组成了quicklist。也就是将多个ziplist使用双向指针串起来使用。这样既满足了快速的插入删除性能，又不会出现太大的空间冗余。

2.5.4Redis集合(Set)

1.简介

Redis set对外提供的功能与list类似是一个列表的功能，特殊之处在于set是可以自动排重的，当你需要存储一个列表数据，又不希望出现重复数据时，set是一个很好的选择，并且set提供了判断某个成员是否在一个set集合内的重要接口，这个也是list所不能提供的。

Redis的Set是string类型的无序集合。它底层其实是一个value为null的hash表，所以添加，删除，查找的复杂度都是O(1)。

一个算法，随着数据的增加，执行时间的长短，如果是O(1)，数据增加，查找数据的时间不变

2.常用命令

sadd key value1 value2 …

将一个或多个 member 元素加入到集合 key 中，已经存在的 member 元素将被忽略

smembers key： 取出该集合的所有值。

sismember key value ：判断集合是否为含有该值，有1，没有0

scard key ：返回该集合的元素个数。

srem key value1 value2 … ：删除集合中的某个元素。

spop key ：随机从该集合中吐出一个值。

srandmember key n ：随机从该集合中取出n个值。不会从集合中删除 。

smove source destination value：把集合中一个值从一个集合移动到另一个集合

sinter key1 key2 ：返回两个集合的交集元素。

sunion key1 key2：返回两个集合的并集元素。

sdiff key1 key2 ：返回两个集合的差集元素(key1中的，不包含key2中的)

3.数据结构

Set数据结构是dict字典，字典是用哈希表实现的。

Java中HashSet的内部实现使用的是HashMap，只不过所有的value都指向同一个对象。Redis的set结构也是一样，它的内部也使用hash结构，所有的value都指向同一个内部值。

2.5.5 Redis哈希(Hash)

1.简介

Redis hash 是一个键值对集合。

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

类似Java里面的Map

用户ID为查找的key，存储的value用户对象包含姓名，年龄，生日等信息，如果用普通的key/value结构来存储

主要有以下2种存储方式：

每次修改用户的某个属性需要，先反序列化改好后再序列化回去。开销较大。	用户ID数据冗余
通过 key(用户ID) + field(属性标签) 就可以操作对应属性数据了，既不需要重复存储数据，也不会带来序列化和并发修改控制的问题

2.常用命令

hset  给集合中的 键赋值

hget  从集合取出 value 

hmset  ... 批量设置hash的值

hexists 查看哈希表 key 中，给定域 field 是否存在。 

hkeys  列出该hash集合的所有field

hvals  列出该hash集合的所有value

hincrby  为哈希表 key 中的域 field 的值加上增量 1  -1

hsetnx 将哈希表 key 中的域 field 的值设置为 value ，当且仅当域 field 不存在 .

3.数据结构

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

2.5.6 Redis有序集合zset(sorted set)

1.简介

Redis有序集合zset与普通集合set非常相似，是一个没有重复元素的字符串集合。

不同之处是有序集合的每个成员都关联了一个评分（score）,这个评分（score）被用来按照从最低分到最高分的方式排序集合中的成员。集合的成员是唯一的，但是评分可以是重复了 。

因为元素是有序的, 所以你也可以很快的根据评分（score）或者次序（position）来获取一个范围的元素。

访问有序集合的中间元素也是非常快的,因此你能够使用有序集合作为一个没有重复成员的智能列表。

2.常用命令

zadd … ：
将一个或多个 member 元素及其 score 值加入到有序集 key 当中。

zrange [WITHSCORES]:
升序排列，返回有序集 key 中，下标在start~stop之间的元素
带WITHSCORES，可以让分数一起和值返回到结果集。

zrevrange [WITHSCORES]
降序排列，返回有序集 key 中，下标在 之间的元素
带WITHSCORES，可以让分数一起和值返回到结果集。

zrangebyscore key minmax [withscores] [limit offset count]：
返回有序集 key 中，所有 score 值介于 min 和 max 之间(包括等于 min 或 max )的成员。有序集成员按 score 值递增(从小到大)次序排列。

zrevrangebyscore key maxmin [withscores] [limit offset count] ：
同上，改为从大到小排列。

zincrby ：为元素的score加上增量

zrem ：删除该集合下，指定值的元素

zcount ：统计该集合，分数区间内的元素个数

zrank ：返回该值在集合中的排名，从0开始。

3.数据结构

SortedSet(zset)是Redis提供的一个非常特别的数据结构，一方面它等价于Java的数据结构Map，可以给每一个元素value赋予一个权重score，另一方面它又类似于TreeSet，内部的元素会按照权重score进行排序，可以得到每个元素的名次，还可以通过score的范围来获取元素的列表。

2.6 Redis配置文件介绍

2.6.1 网络配置相关

2.6.1.1 bind

默认情况bind=127.0.0.1只能接受本机的访问请求, 不写的情况下，无限制接受任何ip地址的访问

生产环境肯定要写你应用服务器的地址；

服务器是需要远程访问的，所以需要将其注释掉

如果开启了protected-mode，那么在没有设定bind ip且没有设密码的情况下，Redis只允许接受本机的响应

2.6.1.2 protected-mode

将本机访问保护模式设置no

2.6.1.3 Port

端口号，默认 6379

2.6.1.4 timeout

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

2.6.1.5 tcp-keepalive

对访问客户端的一种心跳检测，每个n秒检测一次。

单位为秒，如果设置为0，则不会进行Keepalive检测，建议设置成60

2.6.2 GENERAL通用

2.6.2.1 daemonize

是否为后台进程，设置为yes ; 守护进程，后台启动

2.6.2.2 loglevel

指定日志记录级别，Redis总共支持四个级别：debug、verbose、notice、warning，默认为notice

四个级别根据使用阶段来选择，生产环境选择notice 或者warning

2.6.2.3 logfile

日志文件名称

2.6.3 SECURITY安全

2.6.3.1 设置密码

在命令中设置密码，只是临时的。重启redis服务器，密码就还原了。

永久设置，需要再配置文件中进行设置。

2.7 Redis与SpringBoot整合

1、 在pom.xml文件中引入redis相关依赖

<dependency>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-starter-data-redisartifactId>
dependency>


<dependency>
<groupId>org.apache.commonsgroupId>
<artifactId>commons-pool2artifactId>
<version>2.6.0version>
dependency>

2、 application.properties配置redis配置

#Redis服务器地址
spring.redis.host=192.168.140.136
#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

3、 添加redis配置类

@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;
    }
}

2.8 Redis 事务 锁机制

2.8.1 事务定义

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

Redis事务的主要作用就是串联多个命令防止别的命令插队。

2.8.2 Multi、Exec、discard

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

2.8.3 事务的错误处理

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

2.8.4 事务冲突问题

2.8.4.1 例如, 并发情况下:

一个请求想给金额减8000, 一个请求想给金额减5000, 一个请求想给金额减1000

2.8.4.2 悲观锁

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

2.8.4.3 乐观锁

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

2.8.4.4 WATCH key [key …]

在执行multi之前，先执行watch key1 [key2],可以监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断。

2.8.4.5 UNWATCH

取消 WATCH 命令对所有 key 的监视。

如果在执行 WATCH 命令之后，EXEC 命令或DISCARD 命令先被执行了的话，那么就不需要再执行UNWATCH 了。

2.8.5 Redis事务三特性

1. 单独的隔离操作

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

2. 没有隔离级别的概念

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

3. 不保证原子性

   ​ 事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚

2.9 Redis 持久化之RDB

Redis提供了两个不同的持久化的方式：

• RDB
• AOF

2.9.1 定义

在指定的时间间隔内将内存中的数据集快照写入磁盘，它恢复时再将快照文件直接读到内存中

2.9.2 备份是如何执行的

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

2.9.3 Fork

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

2.9.4 RDB持久化流程

（1）redis根据配置自己尝试去生成rdb快照文件
（2）fork一个子进程出来
（3）子进程尝试将数据dump到临时的rdb快照文件中
（4）完成rdb快照文件的生成之后，就替换之前的旧的快照文件
dump.rdb，每次生成一个新的快照，都会覆盖之前的老快照

在redis.conf中配置文件名称，默认为dump.rdb

rdb文件的保存路径，也可以修改。默认为Redis启动时命令行所在的目录下生成

2.9.5 配置文件中默认的快照配置

2.9.6 优势

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

2.9.7 劣势

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

2.9.8 小总结

3.0 Redis 持久化之AOF

AOF默认不开启，默认是打开RDB持久化，appendonly yes，可以打开AOF持久化机制，在生产环境里面，一般来说AOF都是要打开的，除非你说随便丢个几分钟的数据也无所谓； 可以在redis.conf中配置文件名称，默认为 appendonly.aof, AOF文件的保存路径，同RDB的路径一致。

3.0.1 定义

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

3.0.2 AOF持久化流程

（1）客户端的请求写命令会被append追加到AOF缓冲区内；

（2）AOF缓冲区根据AOF持久化策略【always，everysec，no】将操作sync同步到磁盘的AOF文件中；

• always： 每次写入一条数据，立即将这个数据对应的写日志fsync到磁盘上去，性能非常非常差，吞吐量很低; 确保说redis里的数据一条都不丢，那就只能这样了
• everysec：每秒将os cache中的数据fsync到磁盘，这个最常用的，生产环境一般都这么配置，性能很高，QPS还是可以上万的
• no： 仅仅redis负责将数据写入os cache就撒手不管了，然后后面os自己会时不时有自己的策略将数据刷入磁盘，不可控了

（3）AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；

（4）Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的；

3.0.3 AOF和RDB同时开启, redis 听谁的?

AOF和RDB同时开启，系统默认取AOF的数据（数据不会存在丢失）

3.0.4 AOF启动/修复/恢复

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

• 正常恢复

  ​ 修改默认的appendonly no，改为yes

  ​ 将有数据的aof文件复制一份保存到对应目录(查看目录：config get dir)

  ​ 恢复：重启redis然后重新加载

• 异常恢复

  ​ 修改默认的appendonly no，改为yes

  ​ 如遇到AOF文件损坏，找到bin目录,通过redis-check-aof --fix appendonly.aof命令进行恢复

  ​ 备份被写坏的AOF文件

  ​ 恢复：重启redis，然后重新加载

3.0.5 AOF同步频率设置

appendfsync always

==始终同步，每次Redis的写入都会立刻记入日志；==性能较差但数据完整性比较好

appendfsync everysec

每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。

appendfsync no

redis不主动进行同步，把同步时机交给操作系统。

3.0.6 优势

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

3.0.7 劣势

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

3.0.8 小总结

3.0.9 RDB与AOF持久化方式, 官方建议

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

• AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.

• Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大

• 只做缓存：如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式.

• 同时开启两种持久化方式

  （1）如果RDB在执行snapshotting(快照)操作，那么redis不会执行AOF rewrite; 如果redis再执行AOF rewrite，那么就不会执行RDB snapshotting(快照)
  （2）如果RDB在执行snapshotting(快照)，此时用户执行BGREWRITEAOF命令，那么等RDB快照生成之后，才会去执行AOF rewrite
  （3）同时有RDB snapshot文件和AOF日志文件，那么redis重启的时候，会优先使用AOF进行数据恢复，因为其中的日志更完整
  

• 在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据, 因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.

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

  建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)， 快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段。

• 性能建议

  因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。 如果使用AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了。 代价,一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。 只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。 默认超过原大小100%大小时重写可以改到适当的数值。

3.1 Redis 主从复制

3.1.1 定义

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

3.1.2 作用

• 读写分离，性能扩展
• 容灾快速恢复

3.1.3 主从复制步骤

拷贝多个redis.conf文件include(写绝对路径)

开启daemonize yes

Pid文件名字pidfile

指定端口port

Log文件名字

dump.rdb名字dbfilename

Appendonly 关掉或者换名字

3.1.3.1 新建redis6379.conf，填写以下内容

3.1.3.2 新建redis6380.conf，填写以下内容

3.1.3.3 新建redis6381.conf，填写以下内容

slave-priority 10

设置从机的优先级，值越小，优先级越高，用于选举主机时使用。默认100

3.1.3.4 启动三台redis服务器

3.1.3.5 查看系统进程，看看三台服务器是否启动

3.1.3.6 查看三台主机运行情况

进入各个服务器客户端, 输入命令：info replication 打印主从复制的相关信息

3.1.3.7 配置一主二从

slaveof 成为某个实例的从服务器

1、在6380和6381上分别执行: slaveof 127.0.0.1 6379, 让6380与6381端口服务器成为6379从服务器

2、当在主服务器中写入数据使, 都会将数据copy到所有从服务器中, 也就是说6380与6381两个从服务器都能读到主服务器刚存入的数据；但不能在两个从服务器中写入数据, 否则会出现如下错误:

3、主机挂掉，重启就行，一切如初

4、从机重启需重设：slaveof 127.0.0.1 6379

可以将配置增加到文件中。永久生效。

3.1.4 复制原理

• Slave启动成功连接到master后会发送一个sync命令
• Master(主机)接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令， 在后台进程执行完毕之后，master将传送整个数据文件到slave(从机),以完成一次完全同步
• 全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。
• 增量复制：Master继续将新的所有收集到的修改命令依次传给slave,完成同步
• 但是只要是重新连接master,一次完全同步（全量复制)将被自动执行

3.2 哨兵模式

3.2.1 定义

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

3.2.2 配置步骤

自定义的/myredis目录下新建sentinel.conf文件，名字绝不能错

配置哨兵模式, 填写内容: sentinel monitor mymaster 127.0.0.1 6379 1 ; 其中mymaster为监控对象起的服务器名称， 1 为至少有多少个哨兵同意迁移的数量。

3.2.3 启动哨兵

执行 redis-sentinel /myredis/sentinel.conf 命令

当主机挂掉，从机选举中产生新的主机, (大概10秒左右可以看到哨兵窗口日志，切换了新的主机)

哪个从机会被选举为主机呢？根据优先级别：slave-priority

原主机重启后会变为从机。

3.2.4 故障恢复

优先级在redis.conf中默认：slave-priority 100，值越小优先级越高

偏移量是指获得原主机数据最全的

每个redis实例启动后都会随机生成一个40位的runid

3.3 Redis应用问题解决

3.3.1 Redis缓存穿透

• 场景

​ 查询根本不存在的数据，使得请求直达存储层（数据库），导致其负载过大， 甚至宕机。

​ 例如：查询某个帖子的详细页面，查询帖子的Id为-1，Redis不可能缓存了数据库中更本不存在的数据，会导致跳过缓存层

• 解决方案

  一个一定不存在缓存及查询不到的数据，由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。

  解决:

  1. 缓存空对象

     如果一个查询返回的数据为空（不管是数据是否不存在），我们仍然把这个空结果（null）进行缓存，设置空结果的过期时间会很短，最长不超过五分钟

  2. 设置可访问的名单（白名单）

     使用bitmaps类型定义一个可以访问的名单，名单id作为bitmaps的偏移量，每次访问和bitmap里面的id进行比较，如果访问id不在bitmaps里面，进行拦截，不允许访问。

  3. 布隆过滤器

     将所有存在的key提前存入布隆过滤器，在访问缓存层前，先通过过滤器拦截，若请求的是不存在的key，则直接返回空值。

  4. 进行实时监控

     当发现Redis的命中率开始急速降低，需要排查访问对象和访问的数据，和运维人员配合，可以设置黑名单限制服务

3.3.2 Redis缓存击穿

• 场景

​ 某个热点数据，它的访问量非常大。在其缓存层失效瞬间，大量请求直达存储层，导致服务崩溃。

• 解决方案

key可能会在某些时间点被超高并发地访问，是一种非常“热点”的数据。这个时候，需要考虑一个问题：缓存被“击穿”的问题。

解决

1. 预先设置热门数据

在redis高峰访问之前，把一些热门数据提前存入到redis里面，加大这些热门数据key的时长。

2. 实时调整

现场监控哪些数据热门，实时调整key的过期时长

3. 加互斥锁

对数据的访问加互斥锁，当一个线程访问该数据时，其它线程只能等待。这个线程访问后，缓存中的数据将会被重建，届时其它线程就可以直接从缓存层取数据。

4. 永不过期

热点数据不设置过期时间，所以不会出现上述问题，这是“物理”上的永不过期。为 每个数据设置逻辑过期时间，把过期时间存在key对应的value里，如果发现要过期了，通过一个后台的异步线程进行缓存的构建，也就是“逻辑”过期。

详细流程：

（1） 就是在缓存失效的时候（判断拿出来的值为空），不是立即去load db。

（2） 先使用缓存工具的某些带成功操作返回值的操作（比如Redis的SETNX）去set一个mutex key

（3） 当操作返回成功时，再进行load db的操作，并回设缓存,最后删除mutex key；

（4） 当操作返回失败，证明有线程在load db，当前线程睡眠一段时间再重试整个get缓存的方法。

3.3.3 Redis缓存雪崩

• 场景

​ 由于某些原因，缓存层不能提供服务(存在多种情况,如:大量key同时过期/redis挂了)，导致所有的请求直达存储层，造成存储层宕机。

• 解决方案

1. 避免同时过期

   比如我们可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。

2. 构建高可用的Redis缓存

   部署多个Redis实例，个别节点宕机，依然可以保持服务的整体可用。

3. 构建多级缓存

   增加本地缓存，在存储层前多加一级屏障，降低请求直达存储层 的几率。

4. 启用限流和降级措施

   对存储层增加限流措施，当请求超出限制时，对其提供降级服务。

3.3.4 分布式锁

描述：随着业务发展的需要，原单体单机部署的系统被演化成分布式集群系统后，由于分布式系统多线程、多进程并且分布在不同机器上，这将使原单机部署情况下的并发控制锁策略失效，单纯的Java API并不能提供分布式锁的能力。为了解决这个问题就需要一种跨JVM的互斥机制来控制共享资源的访问，这就是分布式锁要解决的问题！

实现方案:

1. 基于数据库实现分布式锁
2. 基于缓存（Redis等）
3. 基于Zookeeper

每一种分布式锁解决方案都有各自的优缺点：

1. 性能方面：redis最高

2. 可靠性：zookeeper最高

使用redis实现分布式锁

redis命令：set sku:1:info “OK” nx px 5000

public R testLock(){
        //使用uuid防误删
        String uuid = UUID.randomUUID().toString();
        //1.上锁, (命令: setnx key val)
        Boolean lock = redisTemplate.opsForValue().setIfAbsent("lock", uuid, 3, TimeUnit.SECONDS);
        //2.上锁成功
        if (lock){
            Object o = redisTemplate.opsForValue().get("num");
            //2.1判断num为空
            if (StringUtils.isEmpty(o)){
                return R.ok().msg("值为空!");
            }
            //2.2转换成int类型
            Integer num = Integer.parseInt(o+"");
            //2.3把redis的num+1
            redisTemplate.opsForValue().set("num", ++num);
            //2.4释放锁, (命令del key)
            String lockVal = (String)redisTemplate.opsForValue().get("lock");
            //判断是否是自己持有锁
            if (uuid.equals(lockVal)){
                redisTemplate.delete("lock");
            }
            return R.ok().msg("操作成功!");

        }
        //3获取锁失败, 每隔0.1秒再获取
        try {
            Thread.sleep(100);
            //递归获取
            return testLock();
        }catch (InterruptedException e){
            e.printStackTrace();
            return R.error().msg(e.getMessage());
        }

 }

【问题】：删除操作缺乏原子性。

a在比较完uuid后，发现值一样，正准备执行 redisTemplate.delete(“lock”) 命令，锁刚好过期，线程b执行上b锁，做具体操作，此时a线程又把还未执行的删除锁的指令执行完，这样就导致a把b的锁给释放了

解决：使用LUA脚本保证删除的原子性

public R testLock(){
        //使用uuid防误删
        String uuid = UUID.randomUUID().toString();
    	String locKey = "lock";
        //1.上锁, (命令: setnx key val)
        Boolean lock = redisTemplate.opsForValue().setIfAbsent(locKey, uuid, 3, TimeUnit.SECONDS);
        //2.上锁成功
        if (lock){
            Object o = redisTemplate.opsForValue().get("num");
            //2.1判断num为空
            if (StringUtils.isEmpty(o)){
                return R.ok().msg("值为空!");
            }
            //2.2转换成int类型
            Integer num = Integer.parseInt(o+"");
            //2.3把redis的num+1
            redisTemplate.opsForValue().set("num", ++num);
            
            /*使用lua脚本来锁*/
            // 定义lua 脚本
            String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
            // 使用redis执行lua执行
            DefaultRedisScript<Long> redisScript = new DefaultRedisScript<>();
            redisScript.setScriptText(script);
            // 设置一下返回值类型 为Long
            // 因为删除判断的时候，返回的0,给其封装为数据类型。如果不封装那么默认返回String 类型，
            // 那么返回字符串与0 会有发生错误。
            redisScript.setResultType(Long.class);
            // 第一个要是script 脚本 ，第二个需要判断的key，第三个就是key所对应的值。
            redisTemplate.execute(redisScript, Arrays.asList(locKey), uuid);
            
            return R.ok().msg("操作成功!");

        }
        //3获取锁失败, 每隔0.1秒再获取
        try {
            Thread.sleep(100);
            //递归获取
            return testLock();
        }catch (InterruptedException e){
            e.printStackTrace();
            return R.error().msg(e.getMessage());
        }

 }