重学之路-Redis（2）

基于狂神视频做的笔记

事务

Redis 事务本质：一组命令的集合！事务中的所有命令都会被序列化，在事务执行过程中，会按照顺序执行！
一次性，顺序性，排他性！执行一系列命令！

Redis事务没有隔离级别的概念！
所有的命令在事务中，并没有直接被执行！只有发起执行命令的时候才会执行！ Exec
Redis单条命令是保存原子性的，但是事务不保证原子性！ 要么同时成功 要么同时失败，原子性！

redis的事务：

• 开启事务（multi）
• 命令入队（…）
• 执行事务（exec）

正常执行事务

127.0.0.1:6379> MULTI			# 开启事务
OK
127.0.0.1:6379(TX)> set k1 v1
QUEUED
127.0.0.1:6379(TX)> set k2 v2
QUEUED
127.0.0.1:6379(TX)> get k2
QUEUED
127.0.0.1:6379(TX)> set k3 v3
QUEUED
127.0.0.1:6379(TX)> exec		# 执行事务
1) OK
2) OK
3) "v2"
4) OK

放弃事务

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379(TX)> set k1 v1
QUEUED
127.0.0.1:6379(TX)> set k3 v3
QUEUED
127.0.0.1:6379(TX)> set k4 v4
QUEUED
127.0.0.1:6379(TX)> DISCARD			# 放弃事务
OK
127.0.0.1:6379> get k4
(nil)

编译型异常（代码有问题！命令有错！），事务中所有命令都不会被执行！

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379(TX)> set k5 v5
QUEUED
127.0.0.1:6379(TX)> getset k3		# 错误的命令
(error) ERR wrong number of arguments for 'getset' command
127.0.0.1:6379(TX)> set k1 v1
QUEUED
127.0.0.1:6379(TX)> EXEC	# 执行报错
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379> get k5			# 所有的命令都不会被执行！
(nil)

运行时异常（1/0），如果事务队列中存在语法性，那么执行命令的时候，其他命令是可以正常执行的！错误命令抛出异常！

127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379(TX)> INCR k1
QUEUED
127.0.0.1:6379(TX)> set k2 v2
QUEUED
127.0.0.1:6379(TX)> set k3 v3
QUEUED
127.0.0.1:6379(TX)> get k3
QUEUED
127.0.0.1:6379(TX)> EXEC
1) (error) ERR value is not an integer or out of range				# 虽然第一条命令报错 倒是依旧正常执行成功了！
2) OK
3) OK
4) "v3"

监控 Watch(=乐观锁=)

悲观锁：
认为什么时候都会出现问题，无论做什么都会加锁！
乐观锁：
认为什么时候都不会出现问题，所以不会上锁！ 更新数据的时候判断一下 在次旗舰是否有人改动数据
获取version
更新时候比较version

Redis检测测试！

127.0.0.1:6379> set money 100
OK
127.0.0.1:6379> set out 0
OK
127.0.0.1:6379> WATCH money			# 监视money 对象
OK
127.0.0.1:6379> MULTI			#事务正常结束，结束期间没有发生变动 正常执行成功！
OK
127.0.0.1:6379(TX)> DECRBY money 20
QUEUED
127.0.0.1:6379(TX)> INCRBY out 20
QUEUED
127.0.0.1:6379(TX)> EXEC
1) (integer) 80
2) (integer) 20
127.0.0.1:6379> 

测试多线程修改值 使用watch可以当作redis的乐观锁操作！

127.0.0.1:6379> WATCH money	#监视 money
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379(TX)> DECRBY money 10
QUEUED
127.0.0.1:6379(TX)> INCRBY out 10
QUEUED
127.0.0.1:6379(TX)> exec				# 在执行事务之前  另一个线程修改了money的值 事务执行失败！
(nil)

再次执行：

127.0.0.1:6379> UNWATCH						#  先解锁
OK
127.0.0.1:6379> WATCH money				# 获取最新的值 再次监视 selectversion
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379(TX)> DECRBY money 100
QUEUED
127.0.0.1:6379(TX)> INCRBY out 100
QUEUED
127.0.0.1:6379(TX)> exec						# 如果监视的值 另一个线程没有修改 执行成功 如果监视值改变  则执行失败！
1) (integer) 900
2) (integer) 120

Jedis

什么是Jedis 是Redis官方推荐的java链接开发工具！使用java操作Redis中间件！

maven库：

<dependencies>
        <dependency>
            <groupId>redis.clients</groupId>
            <artifactId>jedis</artifactId>
            <version>3.3.0</version>
        </dependency>
        <!--fastjson-->
        <dependency>
            <groupId>com.alibaba</groupId>
            <artifactId>fastjson</artifactId>
            <version>1.2.75</version>
        </dependency>
    </dependencies>

略。。。

SpringBoot整合

说明：在springBoot2.x之后，利用lettuce替换了 jedis
jedis：采用直连模式 多线程不安全。如果要避免不安全的情况，需要使用jedis pool链接池！BIO模式
lettuce：底层使用netty，实例可以在多个线程中进行共享，不存在线程不安全的情况！可以减少线程数据，更像NIO模式
源码分析

    @Bean
    @ConditionalOnMissingBean(
        name = {"redisTemplate"}
    )						// 我们可以自定义一个redisTemplate来替换这个默认的！
    @ConditionalOnSingleCandidate(RedisConnectionFactory.class)
    public RedisTemplate<Object, Object> redisTemplate(RedisConnectionFactory redisConnectionFactory) {
    	// 默认的 RedisTemplate 没有过多的设置，redis对象都是需要序列化的！
    	// 两个泛型都是 Object Object 的类型 后续我们需要强制转换<string object>
        RedisTemplate<Object, Object> template = new RedisTemplate();
        template.setConnectionFactory(redisConnectionFactory);
        return template;
    }

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

导入依赖

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-data-redis</artifactId>
        </dependency>

配置

@Configuration
public class RedisConfig {

    // 编写自己的配置类
    @Bean
    public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory redisConnectionFactory) {
        RedisTemplate<String, Object> template = new RedisTemplate();
        template.setConnectionFactory(redisConnectionFactory);
        // 序列化配置
        Jackson2JsonRedisSerializer jackson2JsonRedisSerializer = new Jackson2JsonRedisSerializer(Object.class);
        ObjectMapper objectMapper = new ObjectMapper();
        objectMapper.setVisibility(PropertyAccessor.ALL, JsonAutoDetect.Visibility.ANY);
        jackson2JsonRedisSerializer.setObjectMapper(objectMapper);

        // String序列化
        StringRedisSerializer stringRedisSerializer = new StringRedisSerializer();

        // key采用String的序列化方式
        template.setKeySerializer(stringRedisSerializer);
        template.setHashKeySerializer(stringRedisSerializer);
        // value采用jackson的序列化方式
        template.setValueSerializer(jackson2JsonRedisSerializer);
        template.setHashValueSerializer(jackson2JsonRedisSerializer);
        template.afterPropertiesSet();
        return template;
    }
}

略。。。

Redis.conf配置详解

启动的时候 就通过配置文件来启动！

单位

配置文件 unit单位对大小写不敏感！

包含

网络

bind 127.0.0.1  # 绑定IP
protected-mode yes  # 保护模式
port 6379			#端口设置

通用配置

daemonize yes	# 以守护进程的方式运行，默认no 我们一定要开启 yes！
pidfile /var/run/redis_6379.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 ""			# 日志的文件位置名
databases 16	#数据库的数量 默认16个
always-show-logo no	#是否总是显示logo

快照

持久化，在规定的时间内 执行了多少次操作，则会持久化到文件 .rdb .aof
redis是内存数据库 如果没有持久化就丢数据

save 3600 1		#如果3600秒内 如果至少有1个key进行修改 我们就进行持久化操作
save 300 100		#如果300秒内 如果至少有10个key进行修改 我们就进行持久化操作
save 60 10000	#如果60秒内 如果至少有10000个key进行修改 我们就进行持久化操作

stop-writes-on-bgsave-error yes  #持久化如果出错 是否继续工作！
rdbcompression yes			#是否压缩rdb文件，需要消耗一些cpu资源
rdbchecksum yes				#保存rdb文件的时候 进行错误的检查修复！
dir ./										# rdb文件保存的目录！

REPLICATION 复制 查看下面的redis主从复制
SECURITY 安全

config get requirepass	 # 获取密码	
config set requirepass 123456	# 设置密码
auth 123456 登录密码

CLIENTS 限制

maxclients 10000  # 设置能够连接上redis的最大客户端数量

maxmemory <bytes> # 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 ： 永不过期，返回错误

APPEND ONLY 模式 aof配置

appendonly no			#默认不开启 aof模式  默认是使用rdb方式持久化，在大部分情况下 rdb完全够用！
appendfilename "appendonly.aof"		#持久化的文件名字

# appendfsync always			# 每次修改都会 sync 消耗性能
appendfsync everysec		#每秒执行一次 sync 可能会丢失 1s的数据！
# appendfsync no				# 不执行sync 

Redis持久化

RDB（Redis DataBase）

在主从复制中 RDB就是备用在从机上！
RDB是Redis用来进行持久化的一种方式，是把当前内存中的数据集快照写入磁盘，也就是 Snapshot 快照（数据库中所有键值对数据）。恢复时是将快照文件直接读到内存里。

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，在用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的。这就确保了极高的性能。如果需要进行大规模数据的恢复，且对越数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加高效。RDB的缺点是最后一次持久化后的数据可能丢失。
有时候在生产环境会将这个文件备份。
=rdb保存的文件是dump.rdb= 在snapshotting中配置

触发机制

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

如何恢复rdb文件！

4. 只需要将rdb文件放在我们redis启动目录就可以，redis启动的时候会自动检查dump.rdb恢复其中的数据！
5. 查看需要存放的位置

127.0.0.1:6379> CONFIG GET dir
1) "dir"
2) "/usr/local/bin" # 如果在这个目录下存在 dump.rdb文件，启动就会自动恢复其中的文件

优点：
1.适合大规模数据恢复！ dump.rdb
2.如果对数据完整性不高！
缺点：
1.需要一定的时间间隔进行操作！如果redis意外宕机，最后一次修改数据就没有了！
2.fork进程的时候，会占用一定的内存空间！

AOF（Append Only File）

将我们的所有命令都记录下来（相当于history）恢复的时候把这个文件全部运行一遍！

以日志的形式来记录每个写操作，将Redis执行过的所有指令记录下来（都操作不记录），只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据。
=AOF保存的是 appendonly.aof 文件=

appendonly no  # 默认关闭  改为 yes 开启就可以！

重启服务后 将会生产appendonly.aof文件

如果aof文件有错误，这时候Redis启动会失败，我们需要修复这个aof文件
Redis给我们提供了一个工具 ===redis-check-aof --fix ===

[root@iZ2vc20ehn0q0ihrgccmd2Z bin]# redis-check-aof --fix appendonly.aof 
AOF analyzed: size=81, ok_up_to=81, diff=0
AOF is valid

重写规则

如果aof文件大于64m fork一个新的进程来将我们的文件重写！（默认就是文件的无线追加，文件会越来越大）

appendonly no			#默认不开启 aof模式  默认是使用rdb方式持久化，在大部分情况下 rdb完全够用！
appendfilename "appendonly.aof"		#持久化的文件名字

# appendfsync always			# 每次修改都会 sync 消耗性能
appendfsync everysec		#每秒执行一次 sync 可能会丢失 1s的数据！
# appendfsync no				# 不执行sync 

优点：

1. 每次修改都同步，文件的完整会更加好！
2. 每秒同步一次，可能会丢失1秒的数据
3. 从不同步，效率最高！

缺点：

1. 相对于数据文件来说 aof远远大于rdb，修复的速度也比rdb慢！
2. aof运行效率也要比rdb慢，所有redis默认的配置是rdb持久化！

扩展

只做缓存 就不需要任何持久化！
同时开启2中持久化：
启动优先 aof 持久化（aof数据较完整！）
如果rdb的数据不实时 服务器重启也会只找 aof文件
性能建议：
因为RDB文件只做后备用途，建议旨在Salve上持久化RDB 而且只要15分钟配分一次就够了！只保留 save 900 1 这个规则
如果Enable AOF 最恶劣的情况下也只会丢失不超过2秒的数据，启动脚本较简单 只需要load自己的aof文件就可以了，代价就是带来了持续的IO AOF rewirte过程中传说的新数据写到新文件造成的阻塞几乎不可避免。只要硬盘许可 应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认64M太小 可以改到5G以上。
如果不Enable AOF， 仅靠Master-Slave Repllcation 实现高可用性也可以。能省掉一大笔IO，也减少rewrite是带来的系统波动！代价是如果主从都宕机 会丢失十几分钟的数据，启动脚本也要比较 2个 master/ slave中的RDB文件，载入较新的那个（微博架构）

Redis发布订阅

Redis 发布订阅 (pub/sub) 是一种=消息通信模式=：发送者 (pub) 发送消息，订阅者 (sub) 接收消息。
Redis 客户端可以订阅任意数量的频道。
订阅/发布消息图：1 消息发布者 2 频道 3 消息订阅者

下图展示了频道 channel1 ， 以及订阅这个频道的三个客户端 —— client2 、 client5 和 client1 之间的关系：


测试：
订阅端：

127.0.0.1:6379> SUBSCRIBE xuanmengChannel			#订阅一个频道 xuanmengChannel
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "xuanmengChannel"
3) (integer) 1
# 等待读取推送信息
1) "message"
2) "xuanmengChannel"
3) "hello!"
1) "message"
2) "xuanmengChannel"
3) "hello!this is redis"

发送端：

127.0.0.1:6379> PUBLISH xuanmengChannel "hello!"		# 发布者发布消息到频道
(integer) 1
127.0.0.1:6379> PUBLISH xuanmengChannel "hello!this is redis"
(integer) 1

使用场景：
1.实时消息系统！
2.时时聊天
3.订阅 关注系统！

Redis主从复制

主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(master)，后者称为从节点(slave)；=数据的复制是单向的，只能由主节点到从节点=。=默认情况下，每台Redis服务器都是主节点；=且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点。=（master主要负责写 slave主要负责读）=

作用：
1.数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。

2.故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。

3.负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。

4.高可用基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。

主从复制，读写分离！80%的情况都是读操作！减缓服务器压力！

环境配置

127.0.0.1:6379> info replication				# 查看当前库的信息
# Replication
role:master				# 角色
connected_slaves:0	# 从机数
master_failover_state:no-failover
master_replid:401cd8339287efa96421389b7bdd67c157f513b3
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

复制3个配置文件，修改以下对应信息：
1.端口
2.pid名字
3.log文件名字
4.dump.rdb名字

修改完毕后 启动redis服务

# 通过进程查看启动的redis服务
[root@iZ2vc20ehn0q0ihrgccmd2Z ~]# ps -ef|grep redis
root     31822     1  0 11:33 ?        00:00:00 redis-server 127.0.0.1:6379
root     31877     1  0 11:33 ?        00:00:00 redis-server 127.0.0.1:6380
root     31913     1  0 11:34 ?        00:00:00 redis-server 127.0.0.1:6381
root     31952 30427  0 11:34 pts/3    00:00:00 grep --color=auto redis

一主二从

=默认情况下，每台Redis服务器都是主节点；= 所有一般情况下配置从机就行！
认老大！
SLAVEOF 127.0.0.1 6379

127.0.0.1:6380> SLAVEOF 127.0.0.1 6379
OK
127.0.0.1:6380> info replication
# Replication
role:slave					# 变成了从机
master_host:127.0.0.1
master_port:6379
master_link_status:down
master_last_io_seconds_ago:-1
master_sync_in_progress:0
slave_repl_offset:0
master_link_down_since_seconds:1618198818
slave_priority:100
slave_read_only:1
connected_slaves:0
master_failover_state:no-failover
master_replid:1806cb0a3f42d2b458ca293eda7af892aebee140
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

再次查看主机

127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:1				# 1个从机
slave0:ip=127.0.0.1,port=6380,state=online,offset=14,lag=1  #从机信息
master_failover_state:no-failover
master_replid:1169693a1179ad6672acdefdf8820f648c96e832
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> set k1 v1
OK

从机读：

127.0.0.1:6381> get k1
"v1"
127.0.0.1:6381> set k2 v2
(error) READONLY You can't write against a read only replica.

复制原理
Slave 启动成功连接到 master 后会发送一个sync命令
Master 接到命令，启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行
完毕之后，=master将传送整个数据文件到slave，并完成一次完全同步。=
全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。
增量复制：Master 继续将新的所有收集到的修改命令依次传给slave，完成同步
但是只要是重新连接master，一次完全同步（全量复制）将被自动执行！ 我们的数据一定可以在从机中看到！

层层链路

哨兵模式

概述

主从切换技术的方法是：当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑哨兵模式。
哨兵模式能够后台监控主机是否故障，如果故障了根据投票数=自动将从库转换为主库=。
哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。

测试
创建 sentinel.conf文件

# sentinel monitor 主机名称 host port 1
sentinel monitor myredis 127.0.0.1 6379 1

如果主从服务器设置了密码，需要主从机服务器的密码一致，并且需要在sentinel.conf配置：
sentinel auth-pass mysentinel1 你的reids密码

后面的数字1 代表主机宕机后 slave投票看让谁接替成为主机 票数最多 就会成为主机！

[root@iZ2vc20ehn0q0ihrgccmd2Z bin]# redis-sentinel xmconfig/sentinel.conf 
32520:X 12 Apr 2021 16:36:55.263 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
32520:X 12 Apr 2021 16:36:55.263 # Redis version=6.2.1, bits=64, commit=00000000, modified=0, pid=32520, just started
32520:X 12 Apr 2021 16:36:55.263 # Configuration loaded
32520:X 12 Apr 2021 16:36:55.264 * monotonic clock: POSIX clock_gettime
                _._                                                  
           _.-``__ ''-._                                             
      _.-``    `.  `_.  ''-._           Redis 6.2.1 (00000000/0) 64 bit
  .-`` .-```.  ```\/    _.,_ ''-._                                   
 (    '      ,       .-`  | `,    )     Running in sentinel mode
 |`-._`-...-` __...-.``-._|'` _.-'|     Port: 26379
 |    `-._   `._    /     _.-'    |     PID: 32520
  `-._    `-._  `-./  _.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |           http://redis.io        
  `-._    `-._`-.__.-'_.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |                                  
  `-._    `-._`-.__.-'_.-'    _.-'                                   
      `-._    `-.__.-'    _.-'                                       
          `-._        _.-'                                           
              `-.__.-'                                               

32520:X 12 Apr 2021 16:36:55.265 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
32520:X 12 Apr 2021 16:36:55.268 # Sentinel ID is 133e16ce8e40af3eb1d94d6d000eb058b4f6462c
32520:X 12 Apr 2021 16:36:55.268 # +monitor master myredis 127.0.0.1 6379 quorum 1
32520:X 12 Apr 2021 16:36:55.268 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ myredis 127.0.0.1 6379
32520:X 12 Apr 2021 16:36:55.271 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ myredis 127.0.0.1 6379

如果master节点断开 此时就会从从机随机选择一个从机作为主机。

如果6379 主机回来 只能归并到新的主机下 作为从机！！

哨兵模式
优点：
1.哨兵集群 基于主从复制模式
2.主从可以切换，故障可以转移，系统可用性更好
3.哨兵模式就是主从模式的升级，手动到自动，更加健壮！
缺点：
1.redis不好在线扩容，集群容量一旦到达上限，在线扩容就十分麻烦！
2.实现哨兵模式的配置其实很麻烦，里面有很多选择！

哨兵的全部配置！

# 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 <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster 127.0.0.1 6379 2
#当在redis实例中开启了reuirepass foobared 授权密码 这样所有连接redis实例的客户端都要提供密码
#设置哨兵sentinel连接主从的密码 注意必须为主从设置一样的验证密码
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster 123456
#指定多少毫秒之后 主节点没有答应哨兵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> <numslave>
sentinel parallel-syncs mymaster 1
#故障转移的超时时间failover-timeout 可以用在以下这些方面:
#1.同一个sentinel对同一个master两次failover之间的间隔时间。
#2.当一个slave从一个错误master那里同步开始时间，直到slave被纠正为向正确的master那里同步数据时。
#3.当想要取消一个正在进行failover所需要的时间
#4.当进行failover时,配置所有slave指向新的master所需的最大时间，不过，即使过了这个超时,slaves依然会被正确配置为指向master,但是就不按parallel-syncs所配置的规则来了
# 默认三分钟
# sentinel failover-timeout <master-name> <milliseconds>
setinel 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

缓存穿透，击穿和雪崩

缓存穿透（查不到）

缓存穿透：key对应的数据在数据源并不存在，每次针对此key的请求从缓存获取不到，请求都会到数据源，从而可能压垮数据源。比如用一个不存在的用户id获取用户信息，不论缓存还是数据库都没有，若黑客利用此漏洞进行攻击可能压垮数据库。

解决方案：

布隆过滤器
布隆过滤器是一种数据结构，对所有可能查询的参数以hash形式存储，在控制层先进行校验，不符合则丢弃，从而避免了对底层存储系统的查询压力。

缓存空对象

当存储层不命中时，即使返回的空对象也将其缓存起来，同时会设置一个过期时间，之后再访问这个数据将会从缓存中获取，从而保护了后端数据源。

但是这种方式存在两个问题：

如果空值能够被缓存起来，这就意味着需要更多的空间存储更多的键，因为其中可能会有很多空值的键。
即使对空值设置了过期时间，还是会存在缓存层和存储层的数据会有一段时间窗口不一致的问题，这对于需要保持一致的业务会有影响。

缓存击穿（量太大，缓存过期！）

概述

这里和缓存穿透不同，缓存穿透是查询不到数据，所以都去查询数据库，给数据库造成很大压力；而缓存击穿是一个key十分热点（比如微博某明星热搜），缓存在不停地抗着高并发，始终对一个点访问，当这个缓存数据失效后，大量的高并发请求穿破缓存，在很短时间去请求数据库（就好比一梭子子弹打容器上），就像在屏幕中凿了个洞。

当这个热点key失效过期后，大量并发请求前往数据库查询最新数据，查询完后并写入缓存，会使数据库压力过大。

解决方案
1、设置热点数据永不过期
从缓存层面来看，没有设置过期时间，所以不会出现热点key过期后产生的问题。

2、加互斥锁
分布式锁：使用分布式锁，保证对每个key同时只有一个线程去查询后端服务，其它线程没有获得分布式锁的权限，因此只需要等待即可。这种方式将高并发的压力转移到了分布式锁，因此对分布式锁的考验很大。

缓存雪崩

缓存雪崩是因为大面积的缓存在一个时间点集中失效，打崩了数据库。（如Redis宕机）

举个简单的例子：如果所有首页的Key失效时间都是12小时，中午12点刷新的，在零点的时候有个秒杀活动会有大量用户涌入，假设当时每秒 6000 个请求，本来缓存在可以扛住每秒 5000 个请求，但是这个时候缓存所有的Key都失效了。此时 1 秒 6000 个请求全部落数据库，数据库必然扛不住，它会报一下警，真实情况可能DBA（管理员）都没反应过来就直接挂了。此时，如果没用什么特别的方案来处理这个故障，DBA 很着急，重启数据库，但是数据库立马又被新的流量给打死了。这就是缓存雪崩。

解决方案

1、Redis高可用
这个思想的含义就是：既然Redis有可能会挂掉，那我多增设几台Redis，这样一台挂掉了之后其它的还可以继续工作，高可用其实就是搭建的Redis集群。将热点数据均匀分布在不同的Redis库中。

2、限流降级
这个解决方案的思想就是：在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其它线程等待。

3、数据预热
数据预热的含义就是在正式部署之前，先把可能高访问的数据预先访问一遍，这样可能大部分的数据就能加载到缓存中。在即将发生大并发访问前手动触发加载缓存中不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀一点。

4、在批量往Redis存数据的时候，把每个key的失效时间都加个随机值，这样保证数据不会在同一时间大面积失效。