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中提供的序列化方式：

1. JdkSerializationRedisSerializer：序列化java对象。RestTemplate类默认的序列化方式。

   反序列化时不需要提供（传入）类型信息(class)。
   存储的对象需实现Serializable接口，比较笨重。
   序列化为二进制数据，这对开发者是不友好的。
   序列化后的结果非常庞大，是JSON格式的5倍左右

2. OxmSerializer：以xml格式存储（但还是String类型~）

   解析起来也比较复杂，效率也比较低

3. StringRedisSerializer：简单的字符串序列化。StringRedIsTemplate的默认序列化方式，KV均采用此方式序列化。

   对开发者友好。轻量级。效率高。

4. GenericToStringSerializer：可以将任何对象泛化为字符创并序列化。

   需要调用者给传一个对象到字符串互转的Converter（相当于转换为字符串的操作交给转换器去做)

5. Jackson2JsonRedisSerializer：序列化Object对象为json字符串（与JacksonJsonRedisSerializer相同）

   不需要实现 Serializable接口。
   速度快，序列化后的字符串短小精悍。
   没有@class信息，所以只要字段名相同即可。只要你指定了类型，就能反序列化成功。
   缺点：必须提供要序列化对象的类型信息(.class对象)

6. 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文件的替换。