狂神说redis课程链接
Redis
NoSQL的四大分类
KV键值对
- Redis
文档型数据库（bson格式，和json一样）
- MongoDB
- 基于分布式文件存储的数据库，主要用来处理大量的文件
- 介于关系型数据库和非关系型数据的中间产品，是非关系型数据库中功能最丰富，最像关系型数据库
- ConthDB
列存储数据库
- HBASE
- 分布式文件系统
图关系数据库
- 不是存图形，存放的是关系
- Neo4j
四种数据库的特点
Redis入门
Redis是什么？
Redis（Remote Dictionary Server）远程字典服务
开源的，使用ANSI C语言编写
持久化策略：RDB、AOF
Redis默认安装路径：/usr/local/bin
测试性能
redis-benchmark是一个压力测试工具
# 简单测试：100个并发连接 100000请求
redis-benchmark -h localhost -p 6379 -c 100 -n 100000
基础知识
Redis默认有十六个数据库，默认使用第0个数据库，可以使用select进行切换
select 3 # 切换第三个数据库
DBSIZE # 查看DB大小
Redis是单线程的，Redis是基于内存操作，CPU并不是Redis的性能瓶颈，Redis的瓶颈是机器的内存和网络带宽
Redis为什么单线程还这么快
- 误区1：高性能的服务器一定是多线程的
- 误区2：多线程（CPU上下文会切换）一定比单线程效率高
核心：Redis是将所有的数据全部放在内存中的，所以说使用单线程区操作效率就是最高的，多线程CPU上下文会切换，这是耗时的操作。对于内存系统来说，没有上下文切换效率就是最高的
基础操作
# 查看数据库所有的key
keys *
# 清除当前数据库
flushdb
# 清除全部数据库的内容
FLUSHALL
五大数据类型
redis-key
# 判断对应的Key是否存在
EXISTS keyName
# 从指定的数据库中移除key
move keyName DBNum
# 为key设置过期时间,单位为秒
EXPIRE keyName seconds
# 查看当前key剩余的时间
ttl keyName
# 查看当前key的类型
type keyName
# 设置值
set keyName value
# 获得值
get keyName
String
# 追加字符串，如果当前key不存在，就相当于set key
APPEND keyName value
# 获取字符串长度
STRLEN keyName
# 自增1
incr keyName
# 自减1
decr keyName
# 设置步长，指定增量
INCRBY keyName num
# 设置步长，指定减量
DECRBY keyName num
# 获取指定范围的字符串[start，end]
GETRANGE keyName start end
GETRANGE keyName 0 -1 ## 获取全部的字符串，和get key是一样的
# 用string1替换指定位置开始的字符串
SETRANGE keyName start string1
key2：12345678
SETRANGE key2 1 xx
key2: 1xx45678
# 设置过期时间
setex keyName seconds value
setex key3 30 "hello" ##设置key3的值为hello，30秒后过期
# 不存在再设置（分布式锁中常常使用）
setnx key value ##如果key不存在，创建key；如果存在，创建失败
# 批量设置和获取
mset key1 value1 key2 value2.......
mget key1 key2 key3
# 批量不存在再设置
msetnx key1 value1 key2 value2...... # 是一个原子性的操作，要么一起成功，要么一起失败
# 设置json对象
set key:num {}
set user:1 {name:zhangsan, age:3} #设置一个user:1对象，值为json格式来保存对象
这里的key是一个巧妙的设置，user:{id}:{filed}
#先get然后再set
getset keyName value ##如果值不存在，则返回null；如果存在，则获取原来的值，并设置新的值
使用场景：
- 计数器
- 统计多单位的数量
- 粉丝数
- 对象缓存存储
List
基本的数据类型，列表
# 将一个值或多个值插入到列表的头部（左）
LPUSH listName value1......
# 将一个值或者多个值插入到列表的尾部（右）
RPUSH listName value1......
# 获取list中的值
LRANGE listName 0 -1
# 获取指定区间的list的值[start,end]
LRANGE listName start end
#移除列表的第一个元素
LPOP listName
# 移除列表的最后一个元素
RPOP listName
#通过下标获取list中的某一个值
LINDEX listName num
# 返回列表的长度
LLEN listName
# 移除列表中指定个数的值
LREM listName num value
LREM list 1 one ## 移除list列表中的1个one
# 通过下标截取指定的长度，这个list已经被改变了，只剩下截取的元素[start,end]
LTRIM listName start end
# 移除列表中的最后一个元素，并将它移动到新的列表中
RPOPLPUSH listName newListName
# 将列表中指定下标的值替换为另外一个值。如果列表不存在就会报错；如果存在，则更新当前下标的值
LSET listName num newValue
# 将某个具体的value插入到列表中的某一个元素的前面或者后面
LINSERT listName before|after value newValue
使用场景：
- 消息排队
- 消息队列（Lpush Rpop）
- 栈（Lpush Lpop）
小结：
- List实际上是一个链表
- key不存在，创建新的
- key存在，新增内容
- 如果移除了所有值，空链表，也代表不存在
- 在两边插入或者改动值，效率最高
set（集合）
set中的值是不能重复，且无序的
# 向集合中添加元素
sadd setName value
# 查看指定set的所有值
SMEMBERS setName
# 判断某一个值是不是在set集合中
SISMEMBER setName value
# 获取集合中的元素个数
scard setName
# 移除中set集合中的指定元素
srem setName value
# 随机抽选一个元素
SRANDMEMBER setName
# 随机抽选出指定个数的元素
SRANDMEMBER setName num
# 随机删除集合中的元素
SPOP setName
# 数字集合类
## 差集
SDIFF set1 set2
## 交集 （可以实现共同好友）
SINTER set1 set2
## 并集
SUNION set1 set2
应用场景：
- 共同关注
- 共同爱好
- 二度好友
- 推荐好友
Hash
Map集合，key-map，值是map集合
# 存值
hset hashName field1 value1
## hset myhash field1 luoqing
# 取值
hget hashName fieldName
## hget myhash field1
## luoqing
# 存入多个key-value
HMSET hashName field1 value1 field2 value2......
# 获取多个字段值
HMGET hashName field1 field2......
# 获取全部的数据
HGETALL hashName
# 删除Hash指定的key字段，对应的value值就没有了
hdel hashName fieldName
## hdel myhash field1
""
# 获取指定的hash长度，返回键值对的个数
hlen hashName
# 判断hash中指定字段是否存在，非0为存在
HEXISTS hashName fieldName
# 只获取所有的field
hkeys hashName
# 只获取所有的value
hvals hashName
# 指定增量，若num为正则增加；若为负则减少
HINCRBY hashName fieldName num
# 不存在再设置
HSETNX hashName fieldName value ## 如果不存在则设置，如果存在则不能设置
应用场景：
- 用户信息等经常变动的信息
- hash更适合对象的存储，string更适合字符串的存储
Zset（有序集合）
在set的基础上增加了一个值，set setName score1 value1
# 添加一个值
zadd setName keyName value
# 添加多个值
zadd setName key1 value1 key2 value2
# 查看全部的元素
ZRANGE setName 0 -1
# 实现排序
## 1. 添加三个用户：zadd salary 2500 xiaohong; zadd salary 5000 zhangsan; zadd 500 luoqing
## 元素从低到高排列
ZRANGEBYSCORE setName min max
### 显示全部用户，从负无穷到正无穷
ZRANGEBYSCORE salary -inf +inf
> luoqing
> xiaohong
> zhangsan
### 显示全部用户，并且附带成绩
ZRANGEBYSCORE salary -inf +inf withscore
> luoqing
> 500
> xiaohong
> 2500
> zhangsan
> 5000
### 显示从最小到2500的元素
ZRANGEBYSCORE salary -ing 2500 [withscore]
## 元素从大到小进行排序
ZREVRANGE setName 0 -1
# 移除有序集合中的指定元素
ZREM setName value
# 获取有序集合中的个数
ZCARD setName
# 获取指定区间的成员数量
ZCOUNT setName start end
> zadd myset 1 hello 2 world 3 luoqing
> zcount myset 1 3
3
应用场景：
- 存储班级成绩表
- 普通消息，重要消息。带权重进行判断
- 排行榜应用实现，取Top N测试
三种特殊数据类型
geospatial（地理位置）
朋友的定位，附近的人（获得所有附近的人的地址，定位，通过半径来查询），打车距离计算
这个功能可以推算地理位置的信息，两地之间的距离
# 添加地理位置
GEOADD key longitude latitude member [longitude latitude member ...]
> geoadd china:city 116 39 beijing 114 22 shengzhen
(Integer)2
# 获取当前定位：一定是一个坐标值
GEOPOS key member [member2 ...]
# 返回两个给定位置的距离
# 指定单位的参数 unit 必须是以下单位的其中一个：
# m 表示单位为米。
# km 表示单位为千米。
# mi 表示单位为英里。
# ft 表示单位为英尺。
GEODIST key member1 member2 [unit]
> GEODIST china:city beijing shanghai km
1080
GEORADIUS以给定的经纬度为中心，找出某一半径内的元素
附近的人（获得所有附近的人的地址，定位）通过半径来查询
获得指定数量的人，200
所有数据都应该录入数据库中，才让结果更加准确
# 以110 30 这个经纬度为中心，寻找方圆1000KM内的城市
GEORADIUS china:city 110 30 1000 km
# 显示到中心位置的距离
GEORADIUS china:city 110 30 500 km withdist
>chongqing
>341
>chengdu
>483
# 显示他人的定位信息
GEORADIUS china:city 110 30 500 km withcoord
>chongqing
>106
>29
# 筛选出指定的结果
GEORADIUS china:city 110 30 500 km withdist withcoord count 1 # 只显示一个结果
# 找出位于指定元素周围的内容
GEORADIUSBYMEMBER china:city beijing 1000 km # 找出位于北京1000KM内的城市
# 返回一个或多个位置元素的Geohash表示
GEOHASH china:city beijing chongqing # 该命令将返回11个字符串的Geohash字符串，将二维的经纬度转换为一维的字符串，如果两个字符串越接近，表示距离越近
GEO底层的实现原理其实就是ZSet，可以使用ZSet命令来操作GEO
hyperloglog
基数统计的算法
优点：占用的内存是固定的，264不同的元素的基数，只需要12KB的内存
0.81%错误率，如果不允许容错，就是用set或者自己的数据类型即可
例：统计网页的UV（一个人访问一个网站多次，但是还是算作一个人）
传统的方法：set保存用户的ID，就可以统计set中的元素数量作为标准判断
# 添加
PFADD keyName member1 [member2....]
# 统计基数数量
PFCOUNT keyName
# 合并两组元素
PFMERGE newKeyName keyName1 keyName2 # keyName1 keyName2 --> newKeyName
bitmap
位存储
统计用户信息，活跃，不活跃，登录，未登录，打卡，365天打卡，两个状态的都可以使用bitmap
bitmap位图，都是操作二进制位来进行记录的，就只有0和1两个状态
使用bitmap来记录sign的一周打卡，0-6表示周一到周日，0未打卡，1打卡
周一：1 周二：0…
# 查看某一个天是否打卡
getbit sign 3
>1
getbit sign 6
>0
# 统计操作，统计一周打卡的天数
bitcount sign
>3
事务
Redis单条命令是保证原子性的，但是事务不保证原子性
Redis事务本质：一组命令的集合，一个事务中的所有命令都会被序列化，在事务执行过程中，会按照顺序执行
一次性，顺序性，排他性
Redis事务没有隔离级别的概念
所有的命令在事务中并没有直接被执行，只有发起执行命令时才会被执行（Exec）
Redis的事务：
- 开启事务（multi）
- 命令入队（…）
- 执行事务（exec）
正常执行事务
放弃事务
编译性异常（代码有问题，命令有错），事务中所有的命令都不会被执行
运行时异常，如果事务中某一条命令存在逻辑问题，那么执行命令的时，其他命令可以正常执行，错误命令抛出异常
监控！Watch（面试）
悲观锁：
- 认为什么时候都会出问题，无论做什么都会加锁
乐观锁：
- 认为什么时候都不会出问题，所以不会上锁
- 更新数据的时候去判断一下，在此期间是否有人修改过这个数据
- 获取version，更新的时候比较version
测试多线程修改值，使用watch可以当做Redis的乐观锁操作，可以使用unwatch解锁
事务执行失败后操作：
- 如果发现事务执行失败，就先使用unwatch解锁
- 再使用watch获取最新的值，再次监视，select version
- exec，比对监事的值是否发生了变化，如果没有变化，那么可以执行成功，如果变化则执行失败
Jedis
Redis官方推荐的Java连接开发工具，使用Java操作Redis中间件，如果你要使用Java操作Redis，那么一定要对Jedis十分的熟悉
1、导入依赖
<!-- 导入Jedis的包 -->
<dependency>
<groupId>redis.clients</groupId>
<artifactId>jedis</artifactId>
<version>3.2.0</version>
</dependency>
<!-- fastjosn -->
<dependency>
<groupId>com.alibaba</groupId>
<artifactId>fastjson</artifactId>
<version>1.2.62</version>
</dependency>
2、编码测试
- 连接数据库
- 操作命令
- 断开连接
package com.kuangshen;
import redis.clients.jedis.Jedis;
/**
* Created by 罗星
* 2020/10/20 15:07
*/
public class TestPing {
public static void main(String[] args) {
// 1.创建Jedis对象
Jedis jedis = new Jedis("127.0.0.1", 6379);
// jedis所有的命令就是之前学习过的所有指令
System.out.println(jedis.ping()); // 输出PONG
//关闭连接
jedis.close();
}
}
事务
package com.kuangshen;
import com.alibaba.fastjson.JSONObject;
import redis.clients.jedis.Jedis;
import redis.clients.jedis.Transaction;
/**
* Created by 罗星
* 2020/10/20 15:07
*/
public class TestPing {
public static void main(String[] args) {
Jedis jedis = new Jedis("127.0.0.1", 6379);
JSONObject jsonObject = new JSONObject();
jsonObject.put("hello", "world");
jsonObject.put("name", "kuangshen");
//开启事务
Transaction multi = jedis.multi();
String result = jsonObject.toJSONString();
try {
//将命令添加到队列
multi.set("user1", result);
multi.set("user2", result);
//执行事务
multi.exec();
} catch (Exception e) {
multi.discard(); //异常则放弃事务
e.printStackTrace();
} finally {
jedis.close(); //关闭连接
}
}
}
SpringBoot整合
springboot2之后，原来使用的Jedis被替换为了lettuce
Jedis：采用的直链模式，多个线程操作的话是不安全的，如果想要避免不安全，使用Jedis pool连接池，BIO模式
lettuce：采用netty，实例可以在多个线程中进行共享，不存在线程不安全的情况。NIO模式
源码分析
测试
1、导入依赖
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
2、配置连接
spring:
redis:
host: 127.0.0.1
port: 6379
database: 0
3、测试
package com.luoqing.kuangshenredisspringboot;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.data.redis.connection.RedisConnection;
import org.springframework.data.redis.core.RedisTemplate;
@SpringBootTest
class KuangshenRedisSpringbootApplicationTests {
@Autowired
private RedisTemplate redisTemplate;
@Test
void contextLoads() {
//redisTamplate 操作不同的数据类型，ops和所学指令是一样的
//opsForValue 操作字符串 类似String
//opsForList 操作List 类似List
//opsForSet
//opsForHash
//opsForGeo
//opsForZSet
//opsForHyperLogLog
//除了基本的操作，常用的方法都可以直接通过redisTemplate操作，比如事务和基本的CRUD
//获取Redis的连接对象
// RedisConnection connection = redisTemplate.getConnectionFactory().getConnection();
// connection.flushDb();
// connection.flushAll();
redisTemplate.opsForValue().set("user1", "luoqing");
redisTemplate.opsForValue().get("user1");
}
}
在开发中，所有的pojo都会序列化
在企业开中，我们一般不会直接使用原生的API。自己编写工具类封装原生API
自定义RedisTemplate
package com.luoqing.kuangshenredisspringboot.config;
import com.fasterxml.jackson.annotation.JsonAutoDetect;
import com.fasterxml.jackson.databind.ObjectMapper;
import com.fasterxml.jackson.databind.json.JsonMapper;
import org.springframework.beans.PropertyAccessor;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
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.StringRedisSerializer;
/**
* Created by 罗星
* 2020/10/20 19:15
* 我们为了自己开发方便，一般直接使用<Stirng, Object>
*/
@Configuration
public class RedisConfig{
// 自定义RedisTemplate
@Bean
public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory factory) {
RedisTemplate<String, Object> template = new RedisTemplate<>();
template.setConnectionFactory(factory);
//Json序列化配置
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);
//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详解
1、单位
配置文件单位对大小写不敏感
2、包含其他配置文件
3、网络配置
bind 127.0.0.1 # 允许访问的IP
protectd-mode yes # 保护模式
port 6379 # 端口设置
4、通用配置
daemonize yes # 是否以守护进程的方式运行，默认NO
pidfile /var/run/redis_6379.pid # 如果以后台的方式运行，就需要指定一个pid文件
loglevel notice # 适用于生产环境
logfile “” # 日志文件位置，如果为空则为标准输出
databases 16 #数据库数量，默认16个数据库
always-show-logo yes # 是否显示logo
5、快照（持久化，在规定的时间内，执行了多少次操作则会持久化到文件.rdb中）
save 900 1 # 900秒内如果至少有1个key进行了修改，就进行持久化操作
save 300 10 # 300秒内如果至少有10个key进行了修改，就进行持久化操作
save 60 10000 # 60秒内如果至少有10000个key进行了修改，就进行持久化操作
stop-writes-on-bgsave-error yes # 如果持久化出错，是否还需要继续工作
rdbcompression yes # 是否压缩rdb文件，需要消耗一些CPU资源
rdbchecksum yes # 保存rdb文件时进行错误的检查和校验
dir ./ #rdb文件保存的目录
6、REPLICATION（主从复制）
# 先将#删除
replicaof <masterip> <masterport> # 分别写入主机的IP和端口号
# 写入主机的密码
masterauth <master-password>
7、SECURITY（安全）
配置Redis的密码，默认是没有密码
8、限制CLIENTS
maxclients 10000 # 设置能连接上Redis的最大客户端的数量
maxmemory <bytes> # 设置最大的内存容量
maxmemory-policy noeviction # 内存到达上限之后的处理策略
# 六种策略
1、volatile-lru：只对设置了过期时间的key进行LRU（默认值）
2、allkeys-lru ： 删除lru算法的key
3、volatile-random：随机删除即将过期key
4、allkeys-random：随机删除
5、volatile-ttl ： 删除即将过期的
6、noeviction ： 永不过期，返回错误
9、APPEND ONLY模式，aof配置
appendonly no # 默认是不开启aof模式，默认是使用rdb方式持久化的，在大部分的情况下，rdb完全够用
appendfilename "appendonly.aof" # 持久化的文件名
#appendfsync always # 每次修改都会sync(同步)，消耗性能
appendfsync everysec # 每秒执行一次sync(同步)，可能会丢失这一秒的数
#appendfsync no # 不执行同步，这个时候操作系统自己同步数据，速度最快
Redis持久化（重点）
RDB（Redis DataBase）
在指定的时间间隔内将内存中的数据集快照写入磁盘，Snapshot快照，回复时是将快照文件直接读到内存中
在主从复制中，rdb是用来备用的，放在从机上
Redis会单独创建一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，在用这个临时文件替换上次持久化好的文件，整个过程中，主进程是不进行任何IO操作的，确保了极高的性能。如果需要进行大规模数据的恢复，且对数据恢复的完整性不是非常敏感，RDB方式要比AOF方式更加高效
缺点：最后一次持久化后的数据可能丢失
默认就是RDB，一般情况下不需要修改配置
RDB保存的文件是dump.rdb，可以在配置文件中快照中进行配置
# 配置保存的文件名
dbfilename dump.rdb
触发机制
- save的规则满足的情况下，会自动触发rdb规则
- 执行fllushall命令，会触发rdb规则
- 退出Redis，会产生rdb文件
备份就自动生成一个dump.rdb
恢复rdb文件：只需要将rdb文件放在Redis的启动目录就可以，Redis启动时会自动检查dump.rdb，恢复其中的数据
查看存放位置：
127.0.0.1:6379>config gei dir
dir
/usr/local/bin # 如果这个目录下存在dump.rdb，启动时就会自动恢复其中的数据
优点：
- 适合大规模的数据恢复
- 对数据完整性要求不高
缺点：
- 需要一定的时间间隔进行操作，如果Redis意外宕机了，这个最后一次修改的数据就会丢失
- fork进程的时候，会占用一定的内存空间
AOF（Append Only File）
将所有的命令都记录下来，恢复的时候就把整个文件全部执行一遍
以日志的形式来记录每个写操作，将Redis执行过的所有指令记录下来（读操作不记录），只许追加文件但不可以改写文件，Redis启动之初会读取该文件重新构建数据
AOF保存的是appendonly.aof文件
开启后重启Redis就可以生效了
如果aof文件有错误，Redis是不能启动的，我们要使用Redis提供的redis-check-aof工具来修复
# 修复命令
redis-check-aof appendonly.aof
修复之后，重启就可以恢复数据
优点：
- 每次修改都同步，文件完整性强
- 默认开启每秒同步一次，可能会丢失一秒的数据
- 从不同步效率是最高的
缺点：
- 相对于数据文件来说，aof远大于rdb，修复的速度比rdb慢
- aof运行效率比rdb低
Redis发布订阅
微博、微信关注系统
Redis发布订阅（pub/sub）是一种消息通信模式：发送者（pub）发送消息，订阅者（sub）接收消息
Redis客户端可以订阅任意数量的频道
订阅/发布消息：
第一个：消息发送者 第二个：频道 第三个：消息订阅者
命令：
这些命令被广泛用于构建即时通信应用，比如网络聊天室和实时广播，实时提醒等
# 订阅一个或多个符合给定模式的频道
PSUBSCRIBE pattern [pattern...]
# 查看订阅与发布系统状态
PUBSUB subcommand [argument [argument...]]
# 将信息发送到指定的频道
PUBLISH channet message
# 退订所有给定模式的频道
PUNSUBSCRIBE [pattern [pattern...]]
# 订阅给定的一个或多个频道的信息
SUBSCRIBE channet [channet...]
# 退订给定的频道
UNSUBSCRIBE [channet [channet...]]
使用场景：
- 实时消息系统
- 实时聊天（频道当做聊天室，将信息回显给所有人即可）
- 订阅，关注系统
稍微复杂的场景就会使用消息中间件MQ
Redis主从复制
概念：
指将一台Redis服务器的数据复制到其他的Redis服务器，前者称为主节点（master/leader），后者称为从节点（slave/follower）；数据复制是单向的，只能从主节点到从节点。master以写为主，slave以读为主
默认情况下，每台Redis服务器都是主节点，且一个主节点可以有多个从节点（或没有从节点），但一个从节点只能有一个主节点
主从复制的作用：
- 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式
- 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复。实际上是一种服务的冗余
- 负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量
- 高可用（集群）基石：主从复制是哨兵模式和集群能够实施的基础
环境配置
只配置从节点，不用配置主节点
# 查看当前库的信息
info replication
复制多个配置文件，然后修改对应的信息
- 端口
- pid名字
- log文件名
- dump.rdb文件名
从机配置
# 选择哪台作为主机，认老大
SLAVEOF host port # 在从机上使用这条命令
真实的主从配置应该写入配置文件
细节：
- 主机写，从机只能读，主机中的所有信息和数据都会自动被从机保存
- 主机断开，从机依旧连接到主机，但是没有写操作。如果主机恢复了，从机依旧可以直接获取到主机写入的数据
- 如果是使用命令行配置主从，如果从机重启了，就变为主机了。如果再次配置为从机，同样可以从主机中获取所有值
复制原理：
Slave启动成功连接到master后会发送一个sync同步命令
master接收到命令，启动后台的存盘进程，同时收集所有接收到的用于修改数据集的命令，在后台进程执行完毕后，master将传送整个数据文件到salve，并完成一次完全同步
全量复制：slave服务在接受到数据文件后，将其存盘并加载到内存中
增量复制：master继续将新的所有收集到的修改命令依次传给slave，完成同步
只要是重新连接master，一次完全同步（全量复制）将被自动执行，可以在从节点看到全部数据
层层依赖：
这时候也可以完成我们的主从复制
如果主机宕机，可以使用
SLAVEOF no one
让当前服务器变成主机，其他的节点就可以手动连接到最新的主节点。如果原master修复，那就需要重新进行配置
哨兵模式
自动选举master的模式
概述：当master宕机之后，根据投票数自动将slave转换为master
哨兵模式一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，它会独立运行，原理是哨兵通过发送命令，等待Redis服务器响应，从而监控正在运行的多个Redis实例
作用：
- 通过发送命令，让Redis服务器返回监控其运行状态，包括master和slave
- 当哨兵检测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机
多哨兵模式：一个哨兵进程对Redis进行监控可能会出现问题，可以使用多个哨兵进行监控，各个哨兵之间还会进行监控
假设master宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为master不可用，这个现象称为主观下线，当后面的哨兵也检测到master不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由任意一个哨兵发起，之后进行failover（故障转移）操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线
配置：
- 配置哨兵配置文件sentinel.conf
# sentinel monitor 被监控的主机名字 host port num
# myredis为主机名字，可以任意。1是投票机制，当1个sentinel认为master失效时，则正式失效
sentinel monitor myredis 127.0.0.1 6379 1
- 启动哨兵
# redis-sentinel 配置文件位置
redis-sentinel sentinel.conf
如果master断开，就会从从机中随机选择一个服务器（有一个投票算法）。如果主机修复了，只能归并到新的master下，作为新的master的从机
优点：
- 哨兵集群基于主从复制模式，所有的主从复制优点它全有
- 主从可以切换，故障可以转移，系统的可用性更好
- 哨兵模式就会主从模式的升级，手动到自动，更加健壮
缺点：
- Redis不好在线扩容，集群容量一旦到达上限，扩容十分麻烦
- 实现哨兵模式的配置是很麻烦的
哨兵的全部配置
# Example sentinel.conf
# 哨兵sentinel实例运行的端口 默认26379；如果有哨兵集群，我们还需要配置每个哨兵的端口
port 26379
# 哨兵sentinel的工作目录
dir /tmp
# 哨兵sentinel监控的redis主节点的 ip port
# master-name 可以自己命名的主节点名字 只能由字母A-z、数字0-9 、这三个字符".-_"组成。
# quorum 当这些quorum个数sentinel哨兵认为master主节点失联 那么这时 客观上认为主节点失联了
# sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster 127.0.0.1 6379 2
# 当在Redis实例中开启了requirepass foobared 授权密码 这样所有连接Redis实例的客户端都要提供密码
# 设置哨兵sentinel 连接主从的密码 注意必须为主从设置一样的验证密码
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster MySUPER--secret-0123passw0rd
# 指定多少毫秒之后 主节点没有应答哨兵sentinel 此时 哨兵主观上认为主节点下线 默认30秒
# sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds mymaster 30000
# 这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行同步，
这个数字越小，完成failover所需的时间就越长，
但是如果这个数字越大，就意味着越 多的slave因为replication而不可用。
可以通过将这个值设为 1 来保证每次只有一个slave 处于不能处理命令请求的状态。
# sentinel parallel-syncs <master-name> <numslaves>
sentinel parallel-syncs mymaster 1
# 故障转移的超时时间 failover-timeout 可以用在以下这些方面：
#1. 同一个sentinel对同一个master两次failover之间的间隔时间。
#2. 当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那里同步数据时。
#3. 当想要取消一个正在进行的failover所需要的时间。
#4. 当进行failover时，配置所有slaves指向新的master所需的最大时间。不过，即使过了这个超时，slaves依然会被正确配置为指向master，但是就不按parallel-syncs所配置的规则来了
# 默认三分钟
# sentinel failover-timeout <master-name> <milliseconds>
sentinel failover-timeout mymaster 180000
# SCRIPTS EXECUTION
#配置当某一事件发生时所需要执行的脚本，可以通过脚本来通知管理员，例如当系统运行不正常时发邮件通知相关人员。
#对于脚本的运行结果有以下规则：
#若脚本执行后返回1，那么该脚本稍后将会被再次执行，重复次数目前默认为10
#若脚本执行后返回2，或者比2更高的一个返回值，脚本将不会重复执行。
#如果脚本在执行过程中由于收到系统中断信号被终止了，则同返回值为1时的行为相同。
#一个脚本的最大执行时间为60s，如果超过这个时间，脚本将会被一个SIGKILL信号终止，之后重新执行。
#通知型脚本:当sentinel有任何警告级别的事件发生时（比如说redis实例的主观失效和客观失效等等），将会去调用这个脚本，这时这个脚本应该通过邮件，SMS等方式去通知系统管理员关于系统不正常运行的信息。调用该脚本时，将传给脚本两个参数，一个是事件的类型，一个是事件的描述。如果sentinel.conf配置文件中配置了这个脚本路径，那么必须保证这个脚本存在于这个路径，并且是可执行的，否则sentinel无法正常启动成功。
# 通知脚本
# sentinel notification-script <master-name> <script-path>
sentinel notification-script mymaster /var/redis/notify.sh
# 客户端重新配置主节点参数脚本
# 当一个master由于failover而发生改变时，这个脚本将会被调用，通知相关的客户端关于master地址已经发生改变的信息。
# 以下参数将会在调用脚本时传给脚本:
# <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
# 目前<state>总是“failover”,
# <role>是“leader”或者“observer”中的一个。
# 参数 from-ip, from-port, to-ip, to-port是用来和旧的master和新的master(即旧的slave)通信的
# 这个脚本应该是通用的，能被多次调用，不是针对性的。
# sentinel client-reconfig-script <master-name> <script-path>
sentinel client-reconfig-script mymaster /var/redis/reconfig.sh
Redis缓存穿透和雪崩（面试高频，工作常用）
Redis缓存的使用，极大地提升了应用程序和性能和效率，特别是数据查询方面。但同时也带来一些问题，其中最重要的就是数据一致性问题，从严格意义上讲，这个问题无解。如果对数据的一致性要求很高，就不能使用缓存
缓存穿透
概念：
用户想要查询一个数据，发现Redis内存数据库中没有，也就是缓存没有命中，于是向持久层数据库查询，发现也没有，于是本次查询失败。
当用户很多的时候，缓存都没有命中，于是都去请求了持久层数据库，这会给持久层数据库造成很大的压力，就出现了缓存穿透
解决方案：
1、布隆过滤器
布隆过滤器是一种数据结构，对所有可能查询的参数以hash的形式存储，在控制层先进行校验，不符合则丢弃，从而避免了对底层存储系统的查询压力
2、缓存空对象
当存储层不命中后，即使返回的空对象也将其缓存起来，同时会设置一个过期时间，之后再访问这个数据将会从缓存中获取，保护了后端数据源
这种方法会存在两个问题：
- 如果空值能够被缓存起来，这就意味着缓存需要更多的空间存储更多地键
- 即使对空值设置了过期时间，还是会存在缓存层和存储层的数据会有一段时间的不一致，这对于需要保持一致性的业务会有影响
缓存击穿
指一个key非常热点，不停得扛着大并发，集中对这一个点进行访问，当这个key失效的瞬间，持续的大并发就会穿透缓存，直接请求数据库，就像在缓存中凿开了一个洞
当某个key失效的瞬间，有大量的请求并发访问，这类数据一般是热点数据，由于缓存过期，会同时访问数据库来查询最新的数据，并且回写缓存，会导致数据库瞬间压力过大
解决方案：
1、设置热点数据永不过期
从缓存层面来看，没有设置过期时间，所以不会出现热点key过期后产生的问题
2、加互斥锁
使用分布式锁，保证对于每个key同时只有一个线程区查询后端服务，其他线程没有获得分布式锁的权限，只能等待。这种方式将高并发的压力转移到分布式锁，因此对分布式锁的考验很大
缓存雪崩
某一个时间段，缓存集中过期失效。或者Redis宕机或断电断网
缓存集中过期并不是非常致命的，比较致命的缓存雪崩，是缓存服务器某个节点宕机或断网。因为自然形成的缓存雪崩，一定是在某个时间段集中创建缓存，数据库也是可以顶住压力的，无非就是对数据库产生周期性的压力而已；而缓存服务节点的宕机，对数据库服务器造成的压力是不可预知的，很有可能瞬间就把数据库压垮
解决方案：
1、Redis高可用
多增设Redis服务器，多搭建集群
2、限流降级
在缓存失效后，通过加锁或者队列来控制读取数据库写缓存的线程数量
3、数据预热
在正式部署之前，先把可能的数据预先访问一遍，这样部分可能大量访问的数据就会加载到缓存中。在即将发生大并发访问前手动触发加载缓存不同的key，设置不同的过期时间，让缓存实效的时间点尽量均匀