Redis常用配置及持久化
redis.conf
1)注释掉
#bind 127.0.0.1
2)Redis默认不是以守护进程的方式运行,可以通过该配置项修改,使用yes启用守护进程,
daemonize yes
3)关闭保护模式
protected-mode no
4)设置密码(默认无密码)
requirepass 123456
5)数据文件存放路径 。默认为 dir ./ ,会将数据文件置于执行启动命令的当前目录。开机启动则会位于根目录。dir 后应使用全路径。如:dir /etc/redis
SpringBoot整合Redis(RedisTemplate)
参考:https://mp.weixin.qq.com/s/m3cqHk6yGoZo64uUq7eWFA
spring-data-redis中提供的序列化方式:
- JdkSerializationRedisSerializer:序列化java对象。RestTemplate类默认的序列化方式。
反序列化时不需要提供(传入)类型信息(class)。
存储的对象需实现Serializable接口,比较笨重。
序列化为二进制数据,这对开发者是不友好的。
序列化后的结果非常庞大,是JSON格式的5倍左右 - OxmSerializer:以xml格式存储(但还是String类型~)
解析起来也比较复杂,效率也比较低
- StringRedisSerializer:简单的字符串序列化。StringRedIsTemplate的默认序列化方式,KV均采用此方式序列化。
对开发者友好。轻量级。效率高。
- GenericToStringSerializer:可以将任何对象泛化为字符创并序列化。
需要调用者给传一个对象到字符串互转的Converter(相当于转换为字符串的操作交给转换器去做)
- Jackson2JsonRedisSerializer:序列化Object对象为json字符串(与JacksonJsonRedisSerializer相同)
不需要实现 Serializable接口。
速度快,序列化后的字符串短小精悍。
没有@class信息,所以只要字段名相同即可。只要你指定了类型,就能反序列化成功。
缺点:必须提供要序列化对象的类型信息(.class对象) - GenericJackson2JsonRedisSerializer:和Jackson2JsonRedisSerializer相近。推荐使用
不用自己手动指定对象的Class。
序列化后的内容存储了@class信息。不能序列化和反序列化不同包路径的对象
依赖
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
<!-- lettuce pool 缓存连接池 -->
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-pool2</artifactId>
<version>2.5.0</version>
</dependency>
<!-- jackson json 优化缓存对象序列化 -->
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
<version>2.9.6</version>
</dependency>
application.yml
spring:
redis:
host: 192.168.60.129
password: 123456
timeout: 1000
database: 0
lettuce:
pool:
min-idle: 0
max-idle: 8
max-wait: -1ms
max-active: 8
@Configuration
@Configuration
@AutoConfigureAfter(RedisAutoConfiguration.class)
public class RedisCacheAutoConfiguration {
/**
* 在调用处,自动注入该bean,其对象名 需与该方法名相同
* @param redisConnectionFactory
* @return
*/
@Bean
public RedisTemplate<String, Serializable> redisCacheTemplate(LettuceConnectionFactory redisConnectionFactory) {
RedisTemplate<String, Serializable> template = new RedisTemplate<>();
// key采用String的序列化方式
template.setKeySerializer(new StringRedisSerializer());
template.setValueSerializer(new GenericJackson2JsonRedisSerializer());
template.setConnectionFactory(redisConnectionFactory);
return template;
}
}
持久化方式
1.RDB(redis默认持久化方式)
RDB持久化是在指定时间间隔内把内存中的数据集快照写入内存。实际操作是fork一个子进程,子进程先把数据写入临时文件,完成后,再替换原rdb文件,用二进制压缩存储。
若不使用RDB方案,可以把 save “” 的注释打开,下面三个注释
1)主要配置
#save “”
save 900 1
save 300 10
save 60 10000
解说:save <指定时间间隔> <执行指定次数更新操作>,满足条件就将内存中的数据同步到硬盘中。默认是 900秒内有1个更改,300秒内有10个更改以及60秒内有10000个更改,则将内存中的数据快照写入磁盘。
2) 指定本地数据库文件名,一般采用默认的 dump.rdb
dbfilename dump.rdb
3)在写入文件和读取文件时是否开启rdb文件检查,检查是否有无损坏,如果在启动是检查发现损坏,则停止启动
rdbchecksum yes
4) 默认开启RDB文件压缩
rdbcompression yes
5)快照触发方式
save指令。redis会阻塞,不响应客户端发来的请求,直到RDB快照完成。
bgsave指令。“后台保存”,fork一个子进程执行快照生成操作。
2.AOF持久化
AOF是每秒/每次修改数据后,将相应操作指令追加进AOF记录文件(appendonly.aof)。在redis启动时,会优先从aof文件中恢复数据。
1)开启AOF持久化。redis 默认关闭,需要手动把no改为yes
appendonly yes
2)指定本地AOF文件名,默认值为 appendonly.aof
appendfilename “appendonly.aof”
3)指定更新条件
appendfsync always 同步持久化,每次修改都会将指令加入aof文件(相对慢,安全)
#appendfsync everysec 默认。每秒更新一次
#appendfsync no 不同步
4)配置aof文件重写机制
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
解说:当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。一般都设置为3G,64M太小了
3.RDB、AOF对比
. | RDB | AOF |
---|---|---|
优点 | 在数据量较大时,恢复速度比AOP快。RDB 是一个紧凑的单一文件,方便传送到另一个远端数据中心,适用于灾难恢复 | 数据的完整性和一致性更高。aof 文件体积变得过大时,自动地在后台对 aof 进行重写。aof 文件有序地保存了对数据库执行的所有写入操作 |
缺点 | 数据的完整性和一致性没那么高。备份时,占用内存为原数据占用内存的两倍。持久化和数据的恢复要选择在夜深人静的时候执行是比较合理的 | AOF记录的内容多,文件会越来越大,数据恢复也会越来越慢 |
适用场景 | 业务对数据完整性和一致性要求不高 | 愿意牺牲一些性能,换取更高的缓存一致性 |
4.混合持久化
AOF在进行文件重写时,将重写这一刻之前的内存rdb快照文件的内容和增量的AOF修改内存数据的命令日志文件存在一起,
都写入新的aof文件,新的文件一开始不叫appendonly.aof,等到重写完新的AOF文件才会进行改名,
原子的覆盖原有的AOF文件,完成新旧两个AOF文件的替换。