Redis笔记5

P25 SpringBoot整合Redis

说明：在springboot2.x之后，原来使用的jedis换成了lettuce
原因：
jedis：采用的直连，多个线程操作的话，是不安全的，想要避免不安全使用jedis pool连接池

lettuce：采用netty，实例可以在多个线程中共享，不存在线程不安全的情况，可以减少线程数据

1.源码分析，在springAutoConfig中的Redis自动配置类里
@Bean
@ConditionalOnMissingBean(
name = {“redisTemplate”}
) //我们可以自己定义一个Redistemlate来替换
@ConditionalOnSingleCandidate(RedisConnectionFactory.class)
public RedisTemplate<Object, Object> redisTemplate(RedisConnectionFactory redisConnectionFactory) {、
//1.这是默认的redisTemplate，没有其他设置，但是一般redis对象都需要我们去序列化
//2.泛型是<Object, Object>，我们一般使用比较多的是String类型，这样的话都需要强转
RedisTemplate<Object, Object> template = new RedisTemplate();
template.setConnectionFactory(redisConnectionFactory);
return template;
}

@Bean
@ConditionalOnMissingBean				//由于String类型是我们最常使用的类型，所以单独提出来了一个bean
@ConditionalOnSingleCandidate(RedisConnectionFactory.class)
public StringRedisTemplate stringRedisTemplate(RedisConnectionFactory redisConnectionFactory) {
    StringRedisTemplate template = new StringRedisTemplate();
    template.setConnectionFactory(redisConnectionFactory);
    return template;
}	

1.导入依赖

org.springframework.boot
spring-boot-starter-data-redis

2.配置连接
#配置redis
spring.redis.url=127.0.0.1
spring.redis.port=6379

3.测试

P26

自定义redistemplate，以后可以直接用这个

/**

• @author 87209
  */
  @Configuration
  public class RedisConfig {
  //编写自己的RedisTemplate
  @Bean
  @SuppressWarnings(“all”)
  public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory redisConnectionFactory) {
  RedisTemplate<String, Object> template = new RedisTemplate();
  template.setConnectionFactory(redisConnectionFactory);

   //序列化配置，把所有传入的对象Object.class变为jackson2JsonRedisSerializer序列化
   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);
  
   //设置完之后set进properties
   template.afterPropertiesSet();
  
   return template;
  

  }

P27 Redis配置文件

1.单位不区分大小写
2. 可以包含其他配置文件
3.网络
bind 127.0.0.1 #绑定的ip
protected-mode yes #保护模式
port 6379 #端口
4.通用
daemonize yes #以守护进程运行（后台一直开启），默认是no
pidfile /www/server/redis/redis.pid #如果以守护方式运行（后台一直运行），那么就需要指定这个pid文件
#日志
# Specify the server verbosity level.
# This can be one of:
# debug (a lot of information, useful for development/testing)
# verbose (many rarely useful info, but not a mess like the debug level)
# notice (moderately verbose, what you want in production probably) #适合生产环境
# warning (only very important / critical messages are logged)
loglevel notice

logfile "/www/server/redis/redis.log"	#日志文件存放位置

databases 16	#配置数据库数量，默认16个

5.快照 RDB
持久化，在规定时间内执行了多少次操作，则会持久化到文件 .rdb .aof

redis是内存型数据库，如果没有持久化那么断电就会失去
save 900 1		#900秒内如果至少有一个key进行了修改，那么就进行持久化操作
save 300 10		#300秒内如果至少有10个key进行。。。。。。。。。。。。
save 60 10000	#60秒内。。。。。。。

stop-writes-on-bgsave-error yes		#持久化出错之后是否还继续工作
rdbcompression yes		#是否去压缩rdb的配置文件，需要消耗一些cpu资源

rdbchecksum yes		#rdb文件保存的时候是否检查
dir /www/server/redis/	#rdb文件保存的目录

6.主从复制

7.安全
requirepass可以设置密码，默认没有密码。

8.限制clients
maxclients 10000 #设置能连上redis的客户端的最大连接数
maxmemory #配置redis最大内存容量
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 MODE aof配置
1.appendonly no #默认不开启，默认使用rdb持久化，大部分情况下rdb都够用了
2.appendfilename “appendonly.aof” #aof文件的名字
3. # appendfsync always #每次修改都会sync，消耗性能
appendfsync everysec #每秒执行一次，但是如果宕机可能就会丢失这一秒的数据
# appendfsync no #不执行sync，这个时候操作系统自己同步数据，速度最快

P28 redis持久化

Redis是内存数据库，如果没有配置持久化，那么如果出现问题，数据无法保存。

RDB;
1.指定时间间隔内将内存中的数据集快照写入磁盘
** Redis主进程会创建一个子进程来进行持久化，主进程做正常的操作，不影响性能，子进程将数据写入一个临时文件中，持久化结束之后就用这个文件替换之前的持久化文件。
**如果需要大量的恢复数据并且对数据恢复的完整性不是特别敏感，那么RDB比AOF更加高效，因为RDB有一个缺点就是最后一次持久化的数据可能会丢失。

2.Rdb保存的文件是dunmp.rdb ,在配置文件中进行配置
dbfilename dump.rdb

3.触发机制
1.save的规则满足的情况下，会自动触发rdb规则
2.执行flushall命令，也会出发rdb规则
3.推出redis，也会产生rdb文件。

4.如何恢复rdb文件
只需要将rdb文件放在redis启动目录就可以了，redis启动时会自动检查dump.rdb，恢复其中的数据
查看位置：
在redis的输入中输入：config get dir 这就是存放目录

5.优点：
1.适合大规模的数据恢复。（因为父进程不受影响，fork子进程）
2.对数据的完整性要求不高

6.缺点：
1.需要一定的时间间隔，如果redis意外宕机了，这个最后一次修改的数据就没有了。
2.fork进程的时候，会占用一定的内存空间。

7.有时候在生产环境会将这个文件备份

P29 AOF

将我们的所有命令都记录下来，恢复的时候将这些命令全部执行一遍
ps：只记录写的操作，读的操作不记录，如果大数据的情况下就不建议，因为会写入很久

默认不开启，需要手动配置开启，将appendonly 改为yes

如果aof文件有错误，那么redis是启动不起来的，我们需要修复这个aof文件，
redis提供了 ：redis-check-aof --fix 命令

优点：每一次修改都同步，文件的完整性会更好
每秒同步一次，可能会丢失一秒的数据
如果不开启，就从不同步，效率最高
缺点：相对于数据文件来说，aof文件远远大于rdb，修复的速度也会比rdb慢
aof的运行效率也比rdb慢，所以redis默认配置是rdb持久化

aof的重写机制：
如果aof文件大于64m，太大了，就会fork一个新的进程来将我们的文件进行重写。

P30 redis发布订阅

1.Redis发布订阅是一种消息通信模式：发送者发送消息，订阅者接收消息

订阅端：
127.0.0.1:6379> subscribe xusheng #订阅一个频道
Reading messages… (press Ctrl-C to quit)

1. “subscribe”
2. “xusheng”
3. (integer) 1
   #等待读取推送的消息
4. “message” #消息
5. “xusheng” #哪个频道
6. “hello xuehng” #消息内容
7. “message” #消息
8. “xusheng” #哪个频道
9. “hello redis” #消息内容

发送端：
127.0.0.1:6379> PUBLISH xusheng “hello xuehng”
(integer) 1
127.0.0.1:6379> PUBLISH xusheng “hello redis”
(integer) 1

P31 Redis集群环境搭建

概念：
主从复制：是指将一台Redis服务器的数据，复制到其他的Redis服务器。
前者称为主节点，后者为从节点；
ps：数据的复制是单向的，只能由主节点到从节点。Master以写为主，Slave以读为主。

2.主从复制的作用：
1.数据冗余：实现数据的热备份，是持久化之外的一种数据冗余方式。
2.故障恢复：主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复，实际上是一种服务的冗余。
3.负载均衡：在主从复制的基础上，配合读写分离，由主节点提供写服务，从节点提供读服务，（即
写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载，尤其实在写少读多的场景下，通过多个从节点）
分担读负载，可以大大提高Redis服务器的并发量）
4.高可用（集群）基石：主从复制是哨兵和集群能实施的基础，因此主从复制是Redis高可用的基础。

3.环境配置
只配置从库，不用配置主库
127.0.0.1:6379> info replication #查看当前库的信息

Replication

role:master #角色 master
connected_slaves:0 #没有从机
master_failover_state:no-failover
master_replid:a4555d91786dddd37e4178c0151e36aacee8e4fb
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

1.复制三个配置文件，修改信息
1.端口
2.pid名字
3.log文件名字
4.dunm.rdb名字
修改完毕之后，启动三个redis服务（redis-server xsconfig/redis6379.conf、redis-server xsconfig/redis6380.conf、redis-server xsconfig/redis6381.conf）
启动完之后，在测试服务器上 ps -ef|grep redis 可以看到三个reids服务

P32 主从复制之复制原理

ps：默认情况下，每一台服务器都是主节点（还没配置从节点的时候）
一般情况下，我们只要配置从机就好了–》认老大

127.0.0.1:6380> SLAVEOF 127.0.0.1 6379 #SLAVEOF ip 端口 认ip下端口的redis服务做主机
OK
127.0.0.1:6380> info replication

Replication

role:slave #角色：从机
master_host:127.0.0.1 #可以看到主机的信息
master_port:6379
master_link_status:up
master_last_io_seconds_ago:3
master_sync_in_progress:0
slave_repl_offset:14
slave_priority:100
slave_read_only:1
connected_slaves:0
master_failover_state:no-failover
master_replid:ca82f217bfee004080cbd4ffbf1b9fde21e0fb10
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:14
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:14

主机：
127.0.0.1:6379> info replication

Replication

role:master
connected_slaves:1 #一个从机
slave0:ip=127.0.0.1,port=6380,state=online,offset=42,lag=0 #可以看到从机的信息
master_failover_state:no-failover
master_replid:ca82f217bfee004080cbd4ffbf1b9fde21e0fb10
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:42
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:42

真实的配置应该在配置文件中配置，这样才是永久的。我们这里使用命令配置是暂时的
ps：在配置文件中的replication部分里配置，可以配置主机的ip端口（replicaof）和主机的密码（masterauth）

细节：
主机可以写，从机不能写只能读！主机中所有的数据都会被从机自动保存！

主机写：
127.0.0.1:6379> set k1 v1
OK
从机读：
127.0.0.1:6380> get k1
“v1”

从机写：
127.0.0.1:6380> set k2 v2
(error) READONLY You can’t write against a read only replica.

测试: 主机断开连接，从机依旧连接到主机，这个时候如果主机回来了，从机依旧可以直接获取到主机写的信息。

如果使用命令行配置的主从，如果从机重启了，就会变回主机，但是只要变回为从机，就会立马从主机中获取值

复制原理：
Slave启动成功连接到master后会发送一个sync同步命令
Master接收到命令之后，启动后台的存盘进程，同时收集所有用于修改数据的命令，在后台
进程执行完毕后，master将传送整个数据文件到slave，并完成一次完全同步。

全量复制：在slave服务接收到数据库文件数据后，（刚连接上主机），将其存盘并加载到内存中。（将主机的所有数据加载到内存中）
增量复制：Master继续将新的命令一次传给slave，完成同步（正常情况下主机操作从机同步）

只要重新连接master，一次完全同步（全量复制）将被自动执行

P33 主机宕机后手动配置主机

#谋朝篡位
如果主机断开了，我们可以使用 slaveof no one 让自己变成主机！
如果这个时候老大回来了，那么也没用，不会有从机，需要重新配置。

P34 哨兵模式（自动选举老大）

概念：
谋朝篡位的自动版，能够后台监控主机是否故障，如果故障了就根据投票自动将从库转换为主库

1.哨兵模式是一种特殊的模式，Redis提供了哨兵的命令，哨兵是一个独立的进程，
独立运行
原理：哨兵通过发送命令，等待redis服务器响应，从而监控多个redis实例

2.单机哨兵模式的话，如果哨兵也挂了就不行，所有一般哨兵也会采用集群，
除了监控各个redis服务器之外，哨兵之间也会互相监控

过程：
多个哨兵都通过发送命令监控redis服务器，看其是否返回消息，如果主服务器宕机，
哨兵1先检测到这个结果，系统不会马上进行failover（选举），
仅仅只有哨兵1认为主服务器不可用，这个现象称为主观下线。当其他的哨兵也检测到主服务器不可用时，
并且数量达到一定值（比如总共三个哨兵，有两个认为主服务器不可用），那么
哨兵之间会进行一次投票（投从服务器），投票的结果由一个哨兵发起，进行
failover（故障转移）操作进行切换，切换成功后会通过发布订阅模式，让各个哨兵
把自己监控的从服务器实现切换主机，这个过程称为客观下线。

测试：
1.配置哨兵配置文件sentinel.conf
sentinel monitor myredis 127.0.0.1 6379 1
最后一个1代表主机挂了，slave投票看让谁接替主机，myredis是自己取得名字

2.启动哨兵
redis-sentinel xsconfig/sentinel.conf

主机和从机 

主机转移到6381了

如果此时主机回来了，只能归并到新的主机下，当作从机，这就是哨兵模式的规则。

哨兵模式：
优点：

1. 哨兵集群，基于主从复制模式，所有的主从配置优点他都有
2. 主从可以切换，故障可以转移，系统的可用性更好
   缺点：
3. Redis不好在线扩容，集群容量一旦达到上限，在线扩容就十分麻烦。
4. 实现哨兵的配置十分麻烦，选择太多。

哨兵全部配置：

Example sentinel.conf

哨兵sentinel实例运行的端口 默认26379 port 26379 # 哨兵sentinel的工作目录 dir /tmp # 哨兵sentinel监控的redis主节点的 ip port # master-name 可以自己命名的主节点名字 只能由字母A-z、数字0-9 、这三个字符".-_"组成。# quorum 配置多少个sentinel哨兵统一认为master主节点失联 那么这时客观上认为主节点失联了# sentinel monitor

sentinel monitor mymaster 127.0.0.1 6379 2

当在Redis实例中开启了requirepass foobared 授权密码 这样所有连接Redis实例的客户端都要提供密码 # 设置哨兵sentinel 连接主从的密码 注意必须为主从设置一样的验证密码 # sentinel auth-pass

sentinel auth-pass mymaster MySUPER–secret-0123passw0rd

指定多少毫秒之后 主节点没有应答哨兵sentinel 此时 哨兵主观上认为主节点下线 默认30秒 # sentinel down-after-milliseconds sentinel down-after-milliseconds mymaster 30000

这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行 同步， 这个数字越小，完成failover所需的时间就越长，

但是如果这个数字越大，就意味着越 多的slave因为replication而不可用。
可以通过将这个值设为 1 来保证每次只有一个slave 处于不能处理命令请求的状态。

sentinel parallel-syncs 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

sentinel failover-timeout mymaster 180000

SCRIPTS EXECUTION

#配置当某一事件发生时所需要执行的脚本，可以通过脚本来通知管理员，例如当系统运行不正常时发邮件通知 相关人员。
#对于脚本的运行结果有以下规则：
#若脚本执行后返回1，那么该脚本稍后将会被再次执行，重复次数目前默认为10 #若脚本执行后返回2，或者比2更高的一个返回值，脚本将不会重复执行。
#如果脚本在执行过程中由于收到系统中断信号被终止了，则同返回值为1时的行为相同。
#一个脚本的最大执行时间为60s，如果超过这个时间，脚本将会被一个SIGKILL信号终止，之后重新执行。

#通知型脚本:当sentinel有任何警告级别的事件发生时（比如说redis实例的主观失效和客观失效等等）， 将会去调用这个脚本，这时这个脚本应该通过邮件，SMS等方式去通知系统管理员关于系统不正常运行的信息。调用该脚本时，将传给脚本两个参数，一个是事件的类型，一个是事件的描述。如果sentinel.conf配 置文件中配置了这个脚本路径，那么必须保证这个脚本存在于这个路径，并且是可执行的，否则sentinel无 法正常启动成功。
#通知脚本

shell编程

sentinel notification-script sentinel notification-script mymaster /var/redis/notify.sh

客户端重新配置主节点参数脚本 # 当一个master由于failover而发生改变时，这个脚本将会被调用，通知相关的客户端关于master地址已经发生改变的信息。 # 以下参数将会在调用脚本时传给脚本:

# 目前总是“failover”, # 是“leader”或者“observer”中的一个。 # 参数 from-ip, from-port, to-ip, to-port是用来和旧的master和新的master(即旧的slave)通信的

这个脚本应该是通用的，能被多次调用，不是针对性的。 # sentinel client-reconfig-script

sentinel client-reconfig-script mymaster /var/redis/reconfig.sh # 一般都是由运维来配置！