Redis 2 配置文件redis.conf以及应用

redis.conf

1. units 单位对大小写不敏感
2. include 引用其他配置文件
3. NETWORK
   • bind 127.0.0.1 ::1 绑定哪些ip才能访问
   • protected-mode yes 是否保护
   • port 6379 端口
4. daemonize yes 以守护进程的方式运行，默认no
   - pidfile /var/run/redis.pid 如果是上面是yes,就需要指定一个pid文件
   - loglevel notice 日志级别 debug/verbose/notice/warning
   - logfile “server_log.txt” 日志文件名
5. databases 16 数据库数量
6. 快照-持久化
   - save 900 1 表示900s内，如果有至少一个key进行了修改，则进行持久化操作
   - stop-writes-on-bgsave-error yes 持久化失败后是否继续工作
   - rdbcompression yes 是否压缩rdb文件
   - rdbchecksum yes 保存rdb文件时，进行错误检查
   - dir ./ 保存路径
7. 安全
   • requirepass 123456 密码 配置文件设置密码
   • 命令行设置密码 config set requirepass 123456 config get requirepass
8. 设置最大客户端连接数 maxclients 10000
9. redis 最大内存容量 maxmemory
   maxmemory-policy 内存达到最大的处理策略
   - volatile-lru:从已设置过期时间的内存数据集中挑选最近最少使用的数据 淘汰；
   - volatile-ttl: 从已设置过期时间的内存数据集中挑选即将过期的数据 淘汰；
   - volatile-random:从已设置过期时间的内存数据集中任意挑选数据 淘汰；
   - allkeys-lru:从内存数据集中挑选最近最少使用的数据 淘汰；
   - allkeys-random:从数据集中任意挑选数据 淘汰；
   - no-enviction：禁止驱逐数据。（默认淘汰策略。当redis内存数据达到maxmemory，在该策略下，直接返回OOM错误）；
10. AOF
    appendonly no 默认不开启，默认使用rdb
    appendfilename “appendonly.aof” 持久化文件名
    appendfsync no/everysec/always 同步的方式 不/每秒/总是

持久化-RDB

在指定的时间间隔内将内存中的数据集快照写入磁盘,恢复时是将快照文件直接读到内存里.Redis会单独创建(fork)一个子进程来进行持久化,会先将数据写入到一个临时文件中,待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件。整个过程中,主进程是不进行任何IO操作,确保了极高的性能
如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

1. 触发机制
   • save的规则满足的情况下，会自动触发
   • 执行flushall命名，也会触发
   • 退出redis,也是触发
     备份自动生成dump.db文件
2. 恢复数据
   • 只需要将rdb文件放在redis启动目录下，redis启动时会自动检查，然后恢复
   • 查看存放位置 config get dir

config get dir
1) "dir"
2) "/data" # 存放在这个文件下的dump.db在redis启动时会被自动加载

持久化-AOF

会记录所有命令，恢复时就是将文件中的命令全部执行一次（读操作不记录）

如果配置文件aof有错，则可以使用redis-check-aof 进行修复

redis-check-aof --fix appendonly.aof

如果同时开启RDB和AOF，会优先加载AOF，因为他的数据更完整

redis订阅与发布

发布者

	PUBLISH cainiao hello # 发布一个channel- cainiao ，内容为 hello

订阅者

SUBSCRIBE cainiao .. # 订阅一个channel- cainiao ，也可以订阅多个，会自动收到发布者发布的消息

应用场景

1. 实时消息系统
2. 实时聊天
3. 订阅 关注系统

主从复制

1. 主从复制的作用
   • 数据冗余:主从复制实现了数据的热备份,是持久化之外的一种数据冗余方式；
   • 故障恢复:当主节点出现问题时,可以由从节点提供服务,实现快速的故障恢复;实际上是一种服务的冗余；
   • 负载均衡:在主从复制的基础上,配合读写分离,可以由主节点提供写服务,由从节点提供读服务
   • 高可用基石:除了上述作用以外,主从复制还是哨兵和集群能够实施的基础
   2. 实现生产环境不要只用一台redis,一主三从，单台redis内存建议不要超过20G
   3. 配置方式
      每台机器默认都是主库，所以只需要配置从库
      1 配置从机的配置文件 （port 、pidfile、logfile、 dbfilename）
      2 slaveof host port 从机中配置主机地址和端口
      3 或者在从机的配置文件中配置 replicaof host post 和主机密码 masterauth xxx
   4. 主机才能写，从机只能读
   5. 主机断掉后，从机无法自动选举，当主机重新连接后，从机也能默认连上主机
   6. 如果从机是用命令配置的，当他断掉再恢复时，也不再是从机了；但如果时配置文件中配置，则还是从机
   7. 如果从机断掉再恢复，断掉期间的主机写入的数据，从机依然可以获取到

复制原理

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

info replication # 查看当前服务基本信息
# Replication
role:master			角色
connected_slaves:0 从机数
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

slaveof no one # 由从节点变为主节点

哨兵模式

当主服务器宕机后,需要手动把一台从服务器切换为主服务器,这就需要人工干预,费事费力,还会造成一段时间内服务不可用。这不是一种推荐的方式,更多时候,我们优先考虑哨兵模式。 Redis从2.8开始正式提供了 Sentinel(哨兵)架构来解决这个问题。
哨兵模式是一种特殊的模式，首先redis提供了哨兵的命令，哨兵是一个独立的进程。其原理是哨兵通过发送命令，等待redis服务响应，从而监控运行的redis服务，为防止哨兵挂掉，可配置多哨兵模式


假设主服务器宕机,哨兵1先检测到这个结果,系统并不会马上进行选举,仅仅是哨兵1主观的认为主服务器不可用,这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用,并且数量达到一定值时,那么哨兵之间就会进行一次投票,投票的结果由一个哨兵发起,进行 failover[故障转移]操作。切换成功后,就会通过发布订阅模式,让各个哨兵把自己监控的从服务器实现切换主机,这个过程称为客观下线

配置方式

1. 配置哨兵文件

vim sentinel.conf
-------------------基础配置------------------------------------------
protected-mode no       #关闭保护模式                                                                                                 
port 26479              #端口                                                                                           
daemonize yes           #使用后台模式启动                                                                                               
pidfile "sentinel_26479.pid" #进程id文件                                                       
logfile "sentinel_26479.log" #日志文件                                                        
dir "/usr/local/redis/sentinel" #工作目录
--------------------核心配置----------------------------------
sentinel monitor <master-name> <ip> <port> <quorum>
	master-name：redis主节点昵称。
	ip：		 redis主机ip。
	port：		 redis主机端口。
	quorum：	哨兵判断主节点是否发生故障的票数。
	如果设置为2，表示2个哨兵节点认为主节点发生了故障，一般设置为：哨兵节点数/2+1。
	
sentinel down-after-milliseconds <master-name> <times>
	哨兵会定期的向redis节点发送ping命令来判断redis是否可达，
	若超过指定的times毫秒内还未得到pong回复，则判读该redis不可达。
	
sentinel parallel-syncs <master-name> <nums>
	当redis主节点挂了后，哨兵会选出新的master，此时，剩余的slave会向新的master发起同步数据，
	这个设置表示允许并行同步的slave个数。
sentinel failover-timeout <master-name>  <times>
	进行故障转移时，如果超过设置的times毫秒，表示故障转移失败。
	
sentinel auth-pass <master-name> <password>
	如果redis主节点设置了密码，则需要进行这个配置。

2. 启动哨兵

使用

1. 主机挂了，会自动选举从机
2. 主机恢复后，也不会变成主机，但是会自动变成从机

缺点

1 不好在线扩容，一旦到达集群上限，在线扩容就十分麻烦
2 实现哨兵模式的配置比较麻烦

缓存穿透和缓存雪崩

缓存穿透（查不到）

概念：用户（有意）查询不存在的数据，缓存不命中，导致频繁查询数据库,给持久层数据库造成很大的压力,这时候就相当于出现了缓存穿透

解决方案

1. 布隆过滤器：能确定一定不存在，但不能保证一定存在。

布隆过滤器是一种数据结构,对所有可能査询的参数以hash形式存储,在控制层先进行校验,不符合则丟弃,从而避免了对底层存储系统的查询压力。就像hashMap<int,int>，将查询参数的hash值为key,结果存放1.当请求获取结果时，先计算查询条件的hash，判断map中有则继续去获取，如没有则直接返回
,

2. 缓存空对象

当存储层不命中后,返回的空对象也将其缓存起来,同时会设置一个过期时间,之后再访问这个数据将会从缓存中获取,保护了后端数据源
问题：
1、 如果空值能够被缓存起来,这就意味着缓存需要更多的空间存储更多的键,因为这当中可能会有很多的空值的键;
2、即使对空值设置了过期时间,还是会存在缓存层和存储层的数据会有一段时间不一致,这对于需要保持一致性的业务会有影响。

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

概念：缓存击穿,是某个key的查询非常高频，当这key在失效的瞬间,持续的大并发就穿破缓存,直接请求数据库,就像在一个屏障上凿开了一个洞。当某个key在过期的瞬间,有大量的请求并发访问,这类数据一般是热点数据,由于缓存过期,会同时访问数据库来查询最新数据,并且回写缓存,会导使数据库瞬间压力过大。

解决方案

1. 热点数据永不过期
2. 加互斥锁：使用分布式锁,保证对于毎个key同时只有一个线程去査询后端服务,其他线程没有获得分布式锁的权限,因此只需要等待即可。这种方式将高并发的压力转移到了分布式锁,因此对分布式锁的考验很大。

缓存雪崩

概念：在某一个时间段，缓存集体失效。

解决方案

1. redis高可用（集群）：①停掉某些功能，贡献出更多的机器，② 异地多活
2. 限流降级：在缓存失效后，通过使用锁或者对列来限制读数据库写缓存的线程数。
3. 数据预热：