初识Redis
docker ``exec` `-it docker-redis ``/bin/bash
Linux安装Redis
-
官网下载Redis
-
解压Redis安装包 程序放到opt下面
-
tar -zxvf 安装包
-
进入解压后的文件
-
安装基本的环境配置
yum install gcc-c++ make make install
-
redis 默认安装路径是
usr/local/bin
-
redis默认不是后台启动;修改Redis配置文件
-
启动Redis服务
-
通过制定的配置文件启动服务
redis-server redis.conf
-
连接Redis服务;;
使用Redis-cli进行连接测试
-
查看Redis进程是否开启
ps -ef | frep redis
-
关闭Redis服务
shutdown exit
;
Redis压力测试
测试100个并发连接,100000个请求
redis-benchmark -h localhost -p 6379 -c 100 -n 10000
)]
压力测试结果
Redis基本知识说明
默认16个库
默认有16个数据库,从配置文件中可以得到,默认使用的第0个数据库
通过
select 0
来切换数据库
#切换数据库
select 3
#查看db大小
DBSIZE
#查看数据库所有的key
keys *
#清除当前数据库
flushdb
#清除全部数据库内容
flushall
在docker中操作Redis
#输出docker日志
[root@hecs-x-medium-2-linux-20200921093101 home]# docker logs mydocker
#在容器中运行Redis CLI
#接着我们通过在容器中运行 redis-cli 来连接 redis 服务。我们将在运行中的容器中用 -it 选项来启动一个新的交互式会话,并使用它来运行 redis-cli:
docker exec -it docker-redis /bin/bash
#运行redis-cli
root@517350f4f2bb:/data# redis-cli
redis是单线程 的
明白Redis是很快的,官方表示Redis是基于内存操作,CPU不是Redis的性能操作的瓶颈,Redis的瓶颈是根据机器中的内存和网络带宽,既然可以使用单线程实现,就用单线程了。所以就是用了单线程了。
Redis为什么单线程还那么快?
Redis是C语言写的
1、误区1:很多人认为高性能的服务器一定是多线程的!
2、误区2:多线程(CPU上下文会切换)一定比单线程效率高!
核心:Redis是将所有的数据都放到了内存中,所以用单线程操作效率高,多线程(上下文切换:耗时的操作),对于内存系统来说,如果没有上下文切换,效率就是最高的!多次读写都是在一个CPU上面操作的。在内存的情况下,这就是最佳的操作。
五大基本数据类型
说明
Redis 是一个开源(BSD许可)的,内存中的数据结构存储系统,它可以用作数据库
、缓存
和消息中间件
。 它支持多种类型的数据结构,如 字符串(strings)
,散列(hashes)
,列表(lists)
,集合(sets)
,有序集合(sorted sets)
与范围查询
,bitmaps
, hyperloglogs
和 地理空间(geospatial)
索引半径查询
。 Redis 内置了 复制(replication),LUA脚本(Lua scripting), LRU驱动事件(LRU eviction),事务(transactions) 和不同级别的 磁盘持久化(persistence), 并通过 Redis哨兵(Sentinel)和自动 分区(Cluster)提供高可用性(high availability)。
Redis-key
# set key
set name xixin
#判断当前的key是否存在
EXISTS key
#移除当前的key
move key
#设置key 的过期时间,时间是秒
EXPIRE KEY 10(秒)
#查看当前key的剩余时间
TTL key
#储存一个key
SET key value
#获取一个key
GET key
#查看key的类型
TYPE key
String(字符串)
#追加字符串 如果当前可以不存在,
#相当于set key
APPEND key "值"
#获取字符串长度
STRLEN key
#自增 1 比如设置浏览量,一些不是持久化的数据
INCR key
#自减 1
DECR key
#设置步长,指定增量
INCRBY KEY length
#设置步长,指定减量
DECRBY KEY length
# range 范围
#截取字符串[0,3]
GETRANGE KEY 0 3
#获取全部的字符串,和get key的效果是一样的
GETRANGE KEY 0 -1
# 替换指定位置开始字符串
SETRANGE KEY 1 XXX
#setex (set with excpire) 设置过期时间
#setnx (set if not excpire) 不存在设置(在分布式锁中会常常使用)
#设置key的值为 hello 30秒后过期
SETEX key 30 "hello"
#如果mykey 不存在则创建 mykey 如果存在,则创建失败
SETNX mykey "redis"
MSET
MGET
#同时设置多个值
MSET k1 v1 k2 v2 k3 v3
#同时获取多个值
MGET k1 k2 k3
#mestx是一个原子性操作。要么一起成功,要么一起失败
MESTX k1 v1 k4 v4
#对象
#设置一个user:1对象 值为json字符来保存一个对象!!
SET user:1{name :zhangsan,age:3}
#这里的一个key是一个巧妙的设计 user:{id}:{filed} 如此设计在Redis中是完全OK的
#储存一个值
MSET user:1:name zhangsna user:1:age 3
#GETSET
#先获取key的value如果不存在则返回nil ;;
#如果存在,获取原来的值,并设置新的值
GETSET key value
数据结构是想通的
String类似的使用场景:value除了可以是字符,还可以是我们的数字
- 计数器
- 统计多单位的数量
- 粉丝数
- 对象缓存存储
List(列表)
在Redis中,我们可以吧list玩成栈、队列、阻塞队列
所有的list命令都是以l开头的、
Redis不区分大小写
#讲一个值或多个值,插入到列表头部(左)
LPUSH list one
#获取list中的值
LRANGE list 0 -1
#通过区间获取具体的值
LRANGE list 0 1
#将一个值或者多个值插入到列表的尾部(右)
RPUSH list four
#移除列表的第一个元素
LPOP list
#移除列表的最后一个元素
RPOP list
#通过下标获取值 Lindex
LINDEX KEY 0
LINDEX KEY 0
#获取list集合的长度
Llen key
# Lrem 移除list集合中指定个数的value,精确匹配
Lrem key number "值"
#Ltrim 通过下标截取指定的长度,这个list已经被改变了,只剩下了截取的元素
Ltrim key 1 2
#rpoplpush移除列表最后一个元素,将他移动到新的列表中
#将值从原有的列表中移除,添加到新的列表中,剪切 粘贴
rpoplpush key NewKey
#Lset 将列表中指定下标的值替换为另外一个值;更新操作
#判断这个列表的值是否存在
EXISTS key
#如果存在,更新当前下标的值;如果不存在,则会报错;
LSET key index value
#Linsert将某个具体的value插入插入到列表中某个元素的前面或者后面
Linsert key before/after oldValue newValue
小结
- 他实际上是一个链表,before node after left right 都可以插入值
- 如果key不存在,创建新的链表
- 如果key存在,新增内容
- 如果移除了所有值,空链表,也代表不存在
- 在两边插入或者改动值,效率最高!中间元素,相对来说效率会低一点
消息队列(Lpush Rpop)栈(Lpush Lpop)
消息队列,从左边进去,从右边拿出去
栈:从那边进,就从那边出去
Set(集合)
set中的值不能够重复
无序不重复集合
#向set集合中添加一个值
sadd key value
#查看set中指定的值
SMEMBERS key
#判断某一个元素是不是在set集合中
SISMEMBER key value
#获取set集合中的内容元素个数
SCARD key
#移除set集合中的指定元素
SREM key value
#随机抽取一个元素
SRANDMEMBER key
#随机抽取出指定个数的元素
SRANDMEMBER key number
#随机删除一个set集合中的元素
SPOP key
#将一个set中的元素移到另一个set集合中
SMOVE oldKey newKey value
#差集
SDIFF key1 key2
#并集
SINTER key1 key2
#交集
SUNION key1 key2
Hash
Map集合,key—map 时候、这是一个map集合,本质和String类型没有太大的区别;还是一个简单的key-value
set Myhash field xinaxin
#set 一个字段值key-value
hset key field value
#同时set多个key-value
hmset key field1 value1 field2 value2
#获取多个字段值
hmget key field1 field2
#获取全部的数据(展示方式:key : value 方式)
hgetall key
#删除hash指定的field 对应的value 值也就没有了
hdel key field
#获取这个hash表的字段数量
hlen key
#判断hash中指定字段是否存在
hexists key field
#只获得所有的field
hkeys key
#只获得所有的value
hvals key
#指定增量
hset key field3 number
HINCRBY key field3 number
#如果不存在则可以设置
hsetnx key field4 value
#如果存在则不可以设置
hsetnx key field4 value
hash变更数据 user name age,尤其是用户信息之类的,经常变动的信息!hash更适合与对象的存储,String更加适合字符串的存储;
Zset(有序集合)
在set的集合基础之上,增加了一个值;set k1 v1 zset k1 score1 v1
#添加一个值
zadd key score1 value
#添加多个值
zadd key score2 v2 score3 v3
#查看所有的值
zrange key 0 -1
#实现排序
#从小到大排序,显示所有的用户
ZRANGEBYSCORE key -inf +inf
#从小到大排序,显示所有的用户以及薪资
ZRANGEBYSCORE key -inf +inf WITHSCORES
#从小到大排序,显示薪资小于2500部分用户的信息
ZRANGEBYSCORE key -inf 500 WIDTHSCORES
#从大到小进行排序
ZREVRANGE key 0 -1
#移除有序集合中的指定元素
zrem key value
#获取有序集合中的个数
zcard key
#获取指定区间的成员数量
acount key scores1 scores2
案例思路:set 排序 储存班级成绩表,工资排序表
【普通消息,重要消息,带权重进行判断
排行榜应用实现,取Top N 测试
三种特殊数据类型
geospatial
goadd
#geoadd 添加地理位置
#规则:两极无法直接添加,我们一般会下载城市数据,通过java程序一次性导入
#参数 key 值(经度、纬度、名称)
#有效的经度从 -180度到180度
#有效的纬度从-85.05112878度到85.05112878度
#当坐标位置超出上述范围是,该命令将会返回一个错误
geoadd china:city 经度 纬度 城市名
getpso
#获取指定城市的经度和纬度
GEOPOS china:city beijing
#获取多个城市的经度和纬度
GEOPOS china:city beijing shanghai
GEODIST
两人之间的距离
单位
- m表示单位为米
- km表示单位为千米
- mi表示单位为英里
- ft表示单位为英尺
#计算两个城市之间的距离
GEODIST china:city beijing shanghai km
GEORADIUS:以给定的经纬度为中心,找出某一半径内的元素
所有的数据都应该录入到China:city中才会让结果更加清晰准确
#以已知经纬度为中心,获取某半径内的城市信息 以110,30为例
GEORADIUS china:city 110 30 1000Km
#显示到中心的位置
GEORADIUS chian:city 110 30 50Km withdist
#显示城市的经度纬度(显示他人的定位信息)
GEORADIUS China:city 110 30 500km withcoord
#筛选出指定的结果
GEORADIUS China:city 110 30 500km withdist withcoord count 1
GEORANDIUSBYMEMBER
#找出位于指定元素周围的其他元素!!!
GEORADIUSBYMEMBER china:city beijing 1000 km
GEO底层实现原理其实就是Zset!我们可以使用Zset命令来操作geo
#移除指定的元素
zrem china:city beijing
#查看地图中全部元素
ZRANGE china:xity 0 -1
hyperloglog
简介
Redis 2.8.9版本就更新了Hyperloglog 数据结构!
Redis Hyperloglog基数统计的算法!
优点:占用的内存是固定, 2^64不同的元素的技术,只需要废12KB内存!如果要从内存角度来比较的话Hyperloglog首选!
网页的UV (一个人访问一个网站多次,但是还是算作-个人! )
传统的方式,set 保存用户的id ,然后就可以统计set中的元素数量作为标准判断!
这个方式如果保存大量的用户id ,就会比较麻烦!我们的目的是为了计数,而不是保存用户id ;
0.81%错误率!统计UV任务,可以忽略不计的!
测试使用
127. 0.0.1:6379> PFadd mykey a b c d e f g h i j
#创建第一组元素mykey
(integer) 1
127.0.0.1:6379> PFCOUNT mykey # 统计mykey元素的基数数量
(integer) 10
127.0.0.1:6379> PFadd mykey2 i j z x c v b n m
#创建第二组元素mykey2
(integer) 1
127.0.0.1:6379> PFCOUNT mykey2
(integer) 9
127.0.0.1:6379> PFMERGE mykey3 mykey mykey2 # 合并两组mykey mykey2 => mykey3 并集
OK
127.0.0.1:6379> PFCOUNT mykey3 # 看并集的数量!
(integer) 15
如果允许容错,那么一定可以使用hyperloglog;
如果不允许容错,那么就使用set数据类型即可;
Bitmap
位储存
统计用户信息,活跃,不活跃!登录、未登录!打卡, 365打卡!两个状态的,都可以使用Bitmaps !
Bitmaps位图,数据结构!都是操作二进制位来进行记录,就只有0和1两个状态!
365天= 365 bit 1字节=8bit 46 个字节左右!
测试
#储存值
setbit key 0 1
#取值
getbit key 6
#统计操作
bitcount key
事务
Redis事务本质:一组命令的集合!一个事务中所有命令都会被序列化,在事务执行过程中,会按照顺序进行执行!
一致性、顺序性、排他性!1执行一些命令
------队列 set set set 执行------
Redis事务没有隔离级别的概念
所有的命令在事务中,并没有直接被执行!只有发起执行命令才会被执行!Exec
Redis的事务:
- 开启事务(multi)
- 命令入队(…)
- 执行事务(exec)
正常执行事务
127.0.0.1:6379> multi #开启事务
0K
#命令入队
127.0.0.1:6379> set k1 v1
QUEUED|
127.0.0.1:6379> set k2 v2
QUEUED
127.0.0.1 :6379> get k2
QUEUED
127.0.0.1:6379> set k3 v3
QUEUED
127.0.0.1:6379> exec # 执行事务
1) 0K
2) 0K
3) "v2"
4) OK
放弃事务
#开启事务
multi
#消息队列
set
#取消事务
DISCARD
#取消事务之后,事务队列中的命令都不会被执行
编译型异常(代码有问题!命令有错!!)事务中所有的命令都不会被执行!
运行时异常(1/0) 如果事务队列中存在语法性错误,那么执行命令的时候,其他命令是可以正常执行的,错误命令被抛出异常
悲观锁
- 很悲观,认为什么时候都会出问题,无论做什么都会加锁!
乐观锁
- 很乐观,认为什么时候都不会出问题,所以不会 上锁!更新数据的时候去判断一下,再此期间是否有人修改过这个数据
- 获取version
- 跟新的时候比较一下version
redis监控测试
正常执行成功
127.0.0.1:6379> set money 100
OK
127.0.0.1:6379> set out (
OK
127.0.0.1 :6379> watch money#监视money对象
OK
127.0.0.1:6379> mu1ti #事务正常结束,数据期间没有发生变动,这个时候就正常执行成功!
OK
127.0.0.1:6379> DECRBY money 20
QUEUED
127.0.0.1:6379> INCRBY out 20
QUEUED
127.0.0.1:6379> exec
1) (integer) 80
2) (integer) 20
测试多线程修改值,使用watch可以当做Redis的乐观锁;
在执行之前,如果另外一个线程修改了我们的值,这个时候,就会导致事务执行失败
如果修改失败,获取最新的值就好
- 如果发现事务执行失败,就先解锁
- 获取最新的值,再此监视,select version
- 对比监视的值是否发生了变化,如果没有发生变化,那么可以执行成功,如果变化就执行失败;
Jedis
我们要使用java来操作Redis
什么是Je推荐的Java连接开发工具dis 是Redis官方提供的java连接工具!使用java操作radish中间件!如果使用java操作Redis;那么一定要对Jedis十分熟悉
测试
1、导入对应的依赖
<!-- https://mvnrepository.com/artifact/redis.clients/jedis -->
<dependency>
<groupId>redis.clients</groupId>
<artifactId>jedis</artifactId>
<version>3.3.0</version>
</dependency>
<dependency>
<groupId>com.alibaba</groupId>
<artifactId>fastjson</artifactId>
<version>1.2.58</version>
</dependency>
2、编码测试
- 连接数据库
- 操作命令
- 断开连接
public class JedisPing {
public static void main(String[] args) {
Jedis jedis = new Jedis("192.168.80.128",6379);
System.out.println(jedis.ping());
}
}
//输出PONG则连接成功
事务
Jedis jedis = new Jedis("192.168.80.128",6379);
jedis.flushDB();
JSONObject jsonObject = new JSONObject();
jsonObject.put("hello","world");
jsonObject.put("name","xin");
String res = jsonObject.toString();
/*开启事务*/
Transaction multi = jedis.multi();
try {
multi.set("us1",res);
multi.set("us2",res);
multi.exec();//执行事务
} catch (Exception e) {
e.printStackTrace();
multi.discard();//放弃事务
} finally {
System.out.println(jedis.get("us1"));
System.out.println(jedis.get("us2"));
System.out.println(jedis.flushDB());
multi.close();//关闭事务
}
Spring Boot整合
SpringBoot操作数据: spring-data jpa jdbc mongodb redis !
SpringData也是和SpringBoot齐名的项目!
说明:在SpringBoot2.x之后,原来使用的jedis被替换为了lettuce?
jedis :采用的直连,多个线程操作的话,是不安全的,如果想要避免不安全的,使用jedis pool 连接池!更像BIO 模式
lettuce :采用netty ,实例可以再多个线程中进行共享,不存在线程不安全的情况!可以减少线程数据了,更像NIO 模式
application.properties
# SpringBoot所有的配置类,都有一个自动配置类 RedisAutoConfiguration
# 共自动配置类都会绑定一个 properties;配置文件 RedisProperties
spring.redis.host=192.168.80.128
spring.redis.database=1
链接测试
@Autowired
private RedisTemplate redisTemplate;
@Test
void contextLoads() {
// redisTemplate操作不同的数据类型, api和我们的指令是一样的
// opsForValue操作字符串 类似String
// opsForlist 操作List类似ist
// opsForSet
// opsForHash
// opsForZSet
// opsForGeo
// opsForHyperLogLog
// 除了进本的操作,我们常用的方法都可以直接通过redisTemplate操作, 比如事务,和基本的CRUD
redisTemplate.opsForValue().set("name","1123");
System.out.println(redisTemplate.opsForValue().get("name"));
//获取redis的链接对象
RedisConnection connection = redisTemplate.getConnectionFactory().getConnection();
connection.flushAll();
}
序列化
在所有的企业中,pojo中的类都会被序列化;
@Component
@AllArgsConstructor
@NoArgsConstructor
@Data
//固定的模板,可以直接拿去使用
//自定义一个Template
@Bean
@SuppressWarnings("all")
public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory redisConnectionFactory) throws UnknownHostException {
//我们为了开发方便,一般直接使用<string,Object>
RedisTemplate<String, Object> template = new RedisTemplate();
template.setConnectionFactory(redisConnectionFactory);
//josn序列化
Jackson2JsonRedisSerializer jackson2JsonRedisserializer = new Jackson2JsonRedisSerializer(java.lang.Object.class);
ObjectMapper mapper = new ObjectMapper();
mapper.setVisibility(PropertyAccessor.ALL, JsonAutoDetect.Visibility.ANY);
mapper.enableDefaultTyping(ObjectMapper.DefaultTyping.NON_FINAL);
jackson2JsonRedisserializer.setObjectMapper(mapper);
//string序列化
StringRedisSerializer stringRedisSerializer = new StringRedisSerializer();
// key采用string的序列化方式
template . setKeySerializer(stringRedisSerializer);
// hash 的key也采来用string的序列化方式
template . setHashKeySerializer(stringRedisSerializer);
// value序列化方式采用jackson
template . setValueSerializer(jackson2JsonRedisserializer);
// hash的value序列化方式采用jackson
template. setHashValueSerializer(jackson2JsonRedisserializer);
template. afterPropertiesSet();
return template;
}
Redis.conf详解
单位
配置文件unit单位对大小写不敏感
包含
就好比我们spring中的import、include;可以导入外置的配置文件
网络
bind 192.168.80.128 #绑定的IP
protected-model yes #保护模式
port 6379 #端口
通用 General
daemonize yes #以守护进程的方式运行,默认是no,我们需要自己开启为yes
pidfile /var/run/redis_6379.pid #如果要以后台的方式进行运行,需要我们指定一个pid文件
#日志
# specify the server verbosity leve1.
# This can be one of:
# debug (a 1ot of information, usefu1 for development/testing)
# verbose (many rarely useful info, but not a mess 1ike the debug 1eve1)
# notice(moderately verbose, what you want in production probab1y) 生产环境
# warning (on1y very important / critical messages are 1ogged)
1ogleve1 notice
logfile "" #日志的文件位置名,
databases 16 #默认数据库的数量
always-show-logo yes #是否显示logo
快照 SNAPSHOTTING
持久化,在规定时间内,执行了多少次操作,则会持久化到.rdb.rof
redis是内存数据库,如果没有持久化,那么数据断电即失;
#如果900s内, 如果至少有一个1 key进行了修改, 我们及进行持久化操作
save 900 1
#如果300s内,如果至少10 key进行了修改,我们及进行持久化操作
save 300 10
#如果60s内,如果至少10000 key进行 了修改,我们及进行持久化操作
save 60 10000
#我们之后学习持久化,会自己定义这个测试!
stop-wri tes -on-bgsave-error yes #持久化如果出错,是否还需要继续工作!
rdbcompression yes #是否压缩rdb 文件,需要消耗- - 些cpu资源!
rdbchecksum yes #保存rdb文件的时候,进行错误的检查校验!
dir ./ # rdb文件保存的目录!
SECURITY 安全
这里可以设置redis的密码,默认是没有密码的!!
#设置密码
config set requirepass "123456"
#获取密码
config get requirepass
#登录验证密码
ping
auth 123456
限制 CLIENTS
maxclients 10000#设置能连接上redis的最大客户端的数量
maxmemory <bytes> # redis 配置最大的内存容量
maxmemory-policy noeviction # 内存到达上限之后的处理策略
1、volatile-1ru: 只对设置了过期时间的key进行LRU (默认值)
2、a11keys-1ru :删除1ru算法的key
3、volatile-random: 随机删除即将过期key
4、a11keys-random:随机删除
5、volatile-tt1 :删除即将 过期的
6、noeviction :永不过期,返回错误
APPEND ONLY 模式 aof配置
appendonly no #默认是不开启aof模式的,默认是使用rdb方式持久化的,在大部分所有的情况下,rdb完全够用!
appendfilename "appendonly.aof" # 持久化的文件的名字
# appendfsync always #每次修改都会sync。消耗性能
appendfsync everysec #每秒执行一次sync,可能会丢失这1s的数据!
# appendfsync no #不执行sync,这个时候操作系统自己同步数据,速度最快!
Redis持久化
redis是内存数据库,如果不将内存中的数据库状态保存到磁盘中,那么一旦服务器进程退出,服务器中的数据库状态也会消失。所以Redis提供了持久化功能;
RDB(Redis DataBase)
什么是RDB
在指定的时间间隔内将内存中的数据集快照写入磁盘,也就是行话讲的Snapshot快照,它恢复时是将快照文件直接读到内存里。
Redis会单独创建( fork ) -个子进程来进行持久化,会先将数据写入到一-个临时文件中,待持久化过程都结束了, 再用这个临时文
件替换上次持久化好的文件。整个过程中, 主进程是不进行任何I0操作的。这就确保了极高的性能。如果需要进行大规模数据的恢
复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效。RDB的缺点是最后- -次持久化后的数据可能丢
失。我们默认的就是RDB , -般情况下不需要修改这个配置!
有时候在生产环境我们会将这个文件进行备份!
rdb保存的文件是dump.rdb都是在我们的配置文件中快照中进行配置的!
触发机制
1、save的规则满足的情况下,会自动触发rdb规则
2、执行flushall命令,也会触发我们的rdb规则!
3、退出redis ,也会产生rdb文件!
备份就自动生成一个 dump.rdb
如何恢复rdb文件!
1、只需要将rdb文件放在我们redis启动目录就可以, redis启动的时候会自动检查dump.rdb恢复其中的数据!
2、查看需要存在的位置
127.0.0.1:6379> config get dir
1) "di r"
2) "/usr/1oca1/bin" # 如果在这个目录下存在dump.rdb 文件,启动就会自动恢复其中的数据
几乎就他自己的配置就够用了,但是我们还是需要去学习
优点
- 适合大规模的数据恢复!
- 对数据的完整性要求不高!
缺点
- 需要一定的时间间隔进程操作,如果意外宕机了,那么最后一次修改的数据就没有了
- for进程的时候,会占用一定的内容空间
AOF(Append Only File)
将我们所有的命令都记下来,history,恢复的时候会把这个文件全部执行一遍
是什么
以日志的形式来记录每个写操作,将Redis执行过的所有指令记录下来(读操作不记录) , 只
许追加文件但不可以改写文件, redis启动之初会读取该文件重新构建数据,换言之, redis
重启的话就根据日志文件的内容将写指令从前到后执行一-次以完成数据的恢复
工作
AOF保存的是appendonly.aof文件
appernd
默认是不开启的,我们需要手动进行配置!我们只需要将appendonly改为yes就开启了aof !
重启, redis就可以生效了!
如果这个aof文件有错位,这时候redis 是启动不起来的吗,我们需要修复这个aof文件
redis给我们提供了一个工具redis-check-aof --fix
如果文件正常,则重启就可以恢复了
重写规则说明
Aof默认就是文件无限追加;
如果aof文件大于64M,太大了fork一个新的进程来将我们的文件进行重写!
优点
- 每一次修改都同步,让文件的完整性更加的好
- 每秒同步一次,就可能会丢失一秒的数据
- 从不同步,效率最高
缺点
- 相对于数据文件来说,aof远远大于rdb,修复的速度也比rdb慢
- Aof运行效率也要比aof慢,所以我们Redis默认的配置就是rdb持久化
扩展
1、RDB 持久化方式能够在指定的时间间隔内对你的数据进行快照存储
2、AOF 持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命
令来恢复原始的数据, AOF命令以Redis协
议追加保存每次写的操作到文件末尾, Redis还能对AOF文件进行后台重写,使得AOF文件
的体积不至于过大。
3、只做缓存,如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久
化
4、同时开启两种持久化方式
●在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情
况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。
●RDB的数据不实时,同时使用两者时服务器重启也只会找AOF文件,那要不要只使用AOF
呢?作者建议不要,因为RDB更适合用于备份数据库( AOF在不断变化不好备份) ,快速重
启,而且不会有AOF可能潜在的Bug ,留着作为- -个万一-的手段。
5、性能建议
●因为RDB文件只用作后备用途,建议只在Slave.上持久化RDB文件,而且只要15分钟备份
一 次就够了,只保留save 9001这条规则。
●如果Enable AOF ,好处是在最恶劣情况下也只会丢失不超过两秒数据,启动脚本较简单只
load自己的AOF文件就可以了,代价-是带来了持续的I0 ,二是AOF rewrite的最后将rewrite
过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可,应该尽量
减少AOF rewrite的频率, AOF重写的基础大小默认值64M太小了,可以设到5G以上,默认超
过原大小100%大小重写可以改到适当的数值。
●如果不Enable AOF , 仅靠Master-Slave Repllcation实现高可用性也可以,能省掉一大笔
I0 ,也减少了rewrite时带来的系统波动。代价是如果Master/Slave 同时倒掉,会丢失十几
分钟的数据,启动脚本也要比较两个Master/Slave中的RDB文件,载入较新的那个,微博就是
这种架构。
Redis发布订阅
Redis发布订阅(pub/sub)是一种消息通信模式:发送者(pub)发送消息,订阅者(sub)接收消
息。微信、微博、关注系统!
Redis客户端可以订阅任意数量的频道。
订阅/发布消息图:
第一个:消息发送者I第二个:频道第三个:消息订阅者!
下图展示了频道channel1,以及订阅这个频道的三个客户端
)]
当有新消息通过PUBLISH命令发送给频道channel1时,这个消息就会被发送给订阅它的三个客户端:
命令
这些命令被广泛应用于实时通信应用,比如网络聊天室(chatrooom)场景、实时提醒
测试
订阅端
#订阅一个频道
SUBSCRIBE 频道
#读取消息的形式
#消息
#那个频道的消息
#消息的具体内容
发送端
#发布者发布消息频道
PUBLISH 频道 消息
原理
Redis是使用C实现的,通过分析Redis源码里的pubsub.c文件,了解发布和订阅机制的底层实现,籍此加深对Redis的理解。
Redis通过PUBLISH、SUBSCRIBE 和PSUBSCRIBE等命令实现发布和订阅功能。
通过SUBSCRIBE命令订阅某频道后, redis-server 里维护了- -个字典,字典的键就是一个个channel ,而字典的值则是一个链
表,链表中保存了所有订阅这个channel的客户端。
SUBSCRIBE 命令的关键,就是将客户端添加到给定channel的订阅链表中。通过PUBLISH命令向订阅者发送消息, redis-server 会使用给定的频道作为键,在它所维护的channel字典中查找记录了订阅这个频道的所有客户端的链表,遍历这个链表,将消息发布给所有订阅者。
Pub/Sub从字面上理解就是发布( Publish )与订阅( Subscribe ) , 在Redis中,你可以设定对某一个key值进行消息发布及消息
订阅,当一个key值上进行了消息发布后,所有订阅它的客户端都会收到相应的消息。这一功能最明显的用法就是用作实时
消息系统,比如普通的即时聊天,群聊等功能。
应用
- 实时聊天系统
- 实时消息系统
- 订阅,关注都是可以的
主从复制
概念
主从复制,是指将一台Redis服务器的数据 ,复制到其他的Redis服务器。前者称为主节点(master/leader) ,后者称为从节点
(slave/follower) ;数据的复制是单向的,只能由主节点到从节点。Master以写为主 , Slave以读为主。
默认情况下,每台Redis服务器都是主节点;且-个主节点可以有多个从节点(或没有从节点) ,但一个从节点只能有一-个主节
点。
主从复制的作用主要包括:
1、数据冗余:主从复制实现了数据的热备份,是持久化之外的一种数据冗余方式。
2、故障恢复:当主节点出现问题时,可以由从节点提供服务,实现快速的故障恢复;实际上是一种服务的冗余。
3、负载均衡:在主从复制的基础上,配合读写分离,可以由主节点提供写服务,由从节点提供读服务(即写Redis数据时应用连接
主节点,读Redis数据时应用连接从节点),分担服务 器负载;尤其是在写少读多的场景下,通过多个从节点分担读负载,可以大
大提高Redis服务器的并发量。
4、高可用基石:除了.上述作用以外,主从复制还是哨兵和集群能够实施的基础,因此说主从复制是Redis高可用的基础。
一般来说,要将Redis运用于工程项目中,只使用一-台Redis是万万不能的,原因如下:
1、从结构上,单个Redis服务器会发生单点故障,并且一台服务器需要处理所有的请求负载,压力较大;
2、从容量上,单个Redis服务器内存容量有限,就算一 台Redis服务器内存容量为256G ,也不能将所有内存用作Redis存储内
存一般来说 ,单台Redis最大使用内存不应该超过20G。
电商网站上的商品,-般都是一次上传,无数次浏览的,说专业点也就是"多读少写"。
对于这种场景,我们可以使如下这种架构:
主从复制,读写分离! 80% 的情况下都是在进行读操作!减缓服务器的压力! 架构中经常使用! -主二从!
只要在公司中,主从复制就是必须要使用的,因为在真实的项目中不可能单机使用Redis !
环境配置
只配置从库,不配置主库
127.0.0.1:6379> info repTication # 查看当前库的信息
# Rep1ication
role:master #角色
maste r
connected_ slaves:0 #没有从机
master_ replid:b63c90e6c501143759cb0e7f450bd1eb0c70882a
master_ rep1i d2 : 0000000000000000000000000000000000000000
master_ rep1_ offset:0
second_ rep1_ _offset:-1
rep1_ back1og_ _active:0
rep1_ back7og_ size :1048576
rep1_ back7og_ first_ byte_ offset:0
rep1_ back7og_ histlen:0
一主二从
默认情况下每一台Redis服务器都是主节点;我们一般情况下,只用配置从机就行了;
认老大一主(79) 二从(80,81)
#找谁当自己的老大
SLAVEOF 主机地址 端口号
#查看当前库信息
info replication
真实的主从配置是在配置文件写的,这样的配置是永久的;命令写的只是暂时的;
细节
主机可以写,从机不能写,只能读;主机中所有的信息都会被自动保存在从机中;
测试
主机断开连接,从机依旧是连接到主机的;但是没有写操作的;
主机回来,从机依旧可以获取写的信息;
从机断开,如果是使用命令行编写的配置文件;那么需要重新来配置主从配置;修改配置文件则不需要;
复制原理
Slave启动成功连接到master后会发送一个sync命令
Master接到命令,启动后台的存盘进程,同时收集所有接收到的用于修改数据集命令,在后台进程执行完毕之后, master将传
送整个数据文件到slave ,并完成一次完全同步。
全量复制:而slave服务在接收到数据库文件数据后,将其存盘并加载到内存中。
增量复制: Master继续将新的所有收集到的修改命令依次传给slave ,完成同步
但是只要是重新连接master , - -次完全同步(全量复制)将被自动执行
如果没有老大,这个时候需要手动选择出来一个老大
如果主机断开连接,我们可以使用 SLAVEOF no one 让自己变成主机!其他的节点就可以手动连接到最新的主机节点(手动)
哨兵模式
自动选举老大的模式
概述
主从切换技术的方法是:当主服务器宕机后,需要手动把一台从服务器切换为主服务器,这就需要人工干预,费事费力,还会造成
一段时间内服务不可用。这不是一-种推荐的方式 ,更多时候,我们优先考虑哨兵模式。Redis从2.8开始正式提供Sentinel(哨
兵)架构来解决这个问题。
谋朝篡位的自动版,能够后台监控主机是否故障,如果故障了根据投票数自动将从库转换为主库。
哨兵模式是一种特殊的模式 ,首先Redis提供了哨兵的命令,哨兵是一-个独立的进程,作为进程,它会独立运行。其原理是哨兵
通过发送命令,等待Redis服务器响应,从而监控运行的多个Redis实例。
这里的哨兵有两个作用
●通过发送命令,让Redis服务器返回监控其运行状态,包括主服务器和从服务器。
●当哨兵监测到master宕机,会自动将slave切换成master ,然后通过发布订阅模式通知其他的从服务器,修改配置文件,让它
们切换主机。
然而一一个哨兵进程对Redis服务器进行监控,可能会出现问题,为此,我们可以使用多个哨兵进行监控。各个哨兵之间还会进
行监控,这样就形成了多哨兵模式。
假设主服务器宕机,哨兵1先检测到这个结果,系统并不会马上进行failover过程,仅仅是哨兵1主观的认为主服务器不可用,这
个现象成为主观下线。当后面的哨兵也检测到主服务器不可用,并且数量达到一定值时,那么哨兵之间就会进行一次投票,投
票的结果由一一个哨兵发起,进行failover[故障转移]操作。切换成功后,就会通过发布订阅模式,让各个哨兵把自己监控的从
服务器实现切换主机,这个过程称为客观下线。
测试
1、配置哨兵模式sentinel.conf
# sentine1 monitor 被监控的名称host port 1
sentine1 monitor myredis 127.0.0.1 6379 1
后面的这个数字1 ,代表主机挂了, slave投票看让谁接替成为主机,票数最多的,就会成为主机!
2、启动哨兵!
如果主机死后又回来了,只能归并到新的主机下面;当做从机,这就是哨兵模式的规则
哨兵模式的优缺点
1、优点
- 哨兵集群,基于主从复制模式,所有主从配置优点,他都有;
- 主从可以切换,故障可以转移,系统的可用性就会更好;
- 哨兵模式就是主从模式的升级版,手动到自动,更加健壮
2、缺点
- Redis不好在线扩容,集群容量一旦达到上限,在扩充就会十分麻烦;
- 哨兵模式配置很麻烦,里面有很多的选择;
缓存穿透与雪崩
保证服务器的三高!!!!
高可用
高性能
高并发
在这里我们不会详细的区分析解决方案的底层!
Redis缓存的使用,极大的提升了应用程序的性能和效率,特别是数据查询方面。但同时,它也带来了一些问题。 其中,最要害
的问题,就是数据的一致性问题,从严格意义上讲,这个问题无解。如果对数据的一致性要求很高,那么就不能使用缓存。
另外的一些典型问题就是,缓存穿透、缓存雪崩和缓存击穿。目前,业界也都有比较流行的解决方案。
缓存的穿透(查询不到)
概念
缓存穿透的概念很简单,用户想要查询一-个数据,发现redis内存数据库没有,也就是缓存没有命中,于是向持久层数据库查询。发现也没有,于是本次查询失败。当用户很多的时候,缓存都没有命中,于是都去请求了持久层数据库。这会给持久层数据库造成很大的压力,这时候就相当于出现了缓存穿透。
解决方案
布隆过滤器
布隆过滤器是一种数据结构,对所有可能查询的参数以hash形式存储,在控制层先进行校验,不符合则丢弃,从而避免了对底层存储系统的查询压力;
缓存空对象
当存储层不命中后,即使返回的空对象也将其缓存起来,同时会设置一个过期时间 ,之后再访问这个数据将会从缓存中获取,保护了后端数据源;
但是这种方法会存在两个问题:
1、如果空值能够被缓存起来,这就意味着缓存需要更多的空间存储更多的键,因为这当中可能会有很多的空值的键;
2、即使对空值设置了过期时间,还是会存在缓存层和存储层的数据会有一-段时间窗口的不一致,这对于需要保持一致性的业务会有影响。
缓存击穿(量太大,缓存过期)
概述
这里需要注意和缓存击穿的区别,缓存击穿,是指一个key非常热点 ,在不停的扛着大并发,大并发集中对这一个点进行访问, 当这个key在失效的瞬间,持续的大并发就穿破缓存,直接请求数据库, 就像在一个屏障_ 上凿开了一个洞。
当某个key在过期的瞬间,有大量的请求并发访问,这类数据一般是热点数据 ,由于缓存过期,会同时访问数据库来查询最新数据,并且回写缓存,会导使数据库瞬间压力过大。
解决方案
设置热点数据永不过期
从缓存层面个看,没有设置过期时间,所以不会出现热点key过期后产生的问题。
加互斥锁
分布式锁:使用分布式锁,保证对于每个key同时只有一个线程去查询后端服务,其他线程没有获得分布式锁的权限,因此只需要等待即可。这种方式将高并发的压力转移到了分布式锁,因此对分布式锁的考验很大。
缓存雪崩
概念
缓存雪崩,是指在某一一个时间段,缓存集中过期失效。
产生雪崩的原因之- - ,比如在写本文的时候,马上就要到双十二零点,很快就会迎来一波抢购,这波商品时间比较集中的放入了缓存,假设缓存一一个小时。 那么到了凌晨- -点钟的时候 ,这批商品的缓存就都过期了。而对这批商品的访问查询,都落到了数据库上,对于数据库而言,就会产生周期性的压力波峰。于是所有的请求都会达到存储层,存储层的调用量会暴增,造成存储层也会挂掉的情况。
实集中过期,倒不是非常致命,比较致命的缓存雪崩,是缓存服务器某个节点宕机或断网。因为自然形成的缓存雪崩, -定是在
某个时间段集中创建缓存,这个时候,数据库也是可以顶住压力的。无非就是对数据库产“生周期性的压力而已。而缓存服务节点的宕机,对数据库服务器造成的压力是不可预知的,很有可能瞬间就把数据库压垮。
解决方案
Redis高可用
这个思想的含义是,既然redis有可能挂掉,那我多增设几台redis ,这样一台挂掉之 后其他的还可以继续工作,其实就是搭建的集群。
限流降级
这个解决方案的思想是, 在缓存失效后,通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一一个线程查询数据和写缓存,其他线程等待。
数据预热
数据加热的含义就是在正式部署之前,我先把可能的数据先预先访问-遍,这样部分可能大量访问的数据就会加载到缓存中。在即将发生大并发访问前手动触发加载缓存不同的key ,设置不同的过期时间,让缓存失效的时间点尽量均匀。
层先进行校验,不符合则丢弃,从而避免了对底层存储系统的查询压力;
[外链图片转存中…(img-v6oQtB56-1615206260895)]
缓存空对象
当存储层不命中后,即使返回的空对象也将其缓存起来,同时会设置一个过期时间 ,之后再访问这个数据将会从缓存中获取,保护了后端数据源;
[外链图片转存中…(img-qgwSi9Zr-1615206260895)]
但是这种方法会存在两个问题:
1、如果空值能够被缓存起来,这就意味着缓存需要更多的空间存储更多的键,因为这当中可能会有很多的空值的键;
2、即使对空值设置了过期时间,还是会存在缓存层和存储层的数据会有一-段时间窗口的不一致,这对于需要保持一致性的业务会有影响。
缓存击穿(量太大,缓存过期)
概述
这里需要注意和缓存击穿的区别,缓存击穿,是指一个key非常热点 ,在不停的扛着大并发,大并发集中对这一个点进行访问, 当这个key在失效的瞬间,持续的大并发就穿破缓存,直接请求数据库, 就像在一个屏障_ 上凿开了一个洞。
当某个key在过期的瞬间,有大量的请求并发访问,这类数据一般是热点数据 ,由于缓存过期,会同时访问数据库来查询最新数据,并且回写缓存,会导使数据库瞬间压力过大。
解决方案
设置热点数据永不过期
从缓存层面个看,没有设置过期时间,所以不会出现热点key过期后产生的问题。
加互斥锁
分布式锁:使用分布式锁,保证对于每个key同时只有一个线程去查询后端服务,其他线程没有获得分布式锁的权限,因此只需要等待即可。这种方式将高并发的压力转移到了分布式锁,因此对分布式锁的考验很大。
缓存雪崩
概念
缓存雪崩,是指在某一一个时间段,缓存集中过期失效。
产生雪崩的原因之- - ,比如在写本文的时候,马上就要到双十二零点,很快就会迎来一波抢购,这波商品时间比较集中的放入了缓存,假设缓存一一个小时。 那么到了凌晨- -点钟的时候 ,这批商品的缓存就都过期了。而对这批商品的访问查询,都落到了数据库上,对于数据库而言,就会产生周期性的压力波峰。于是所有的请求都会达到存储层,存储层的调用量会暴增,造成存储层也会挂掉的情况。
实集中过期,倒不是非常致命,比较致命的缓存雪崩,是缓存服务器某个节点宕机或断网。因为自然形成的缓存雪崩, -定是在
某个时间段集中创建缓存,这个时候,数据库也是可以顶住压力的。无非就是对数据库产“生周期性的压力而已。而缓存服务节点的宕机,对数据库服务器造成的压力是不可预知的,很有可能瞬间就把数据库压垮。
解决方案
Redis高可用
这个思想的含义是,既然redis有可能挂掉,那我多增设几台redis ,这样一台挂掉之 后其他的还可以继续工作,其实就是搭建的集群。
限流降级
这个解决方案的思想是, 在缓存失效后,通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一一个线程查询数据和写缓存,其他线程等待。
数据预热
数据加热的含义就是在正式部署之前,我先把可能的数据先预先访问-遍,这样部分可能大量访问的数据就会加载到缓存中。在即将发生大并发访问前手动触发加载缓存不同的key ,设置不同的过期时间,让缓存失效的时间点尽量均匀。