1. 性能测试 - 【redis-benchmark】

//进入含有redis-benchmark执行文件的目录

// 解释：访问localhost:6379  模拟10个用户，每个用户请求100次
./redis-benchmark -h localhost -p 6379 -c 10 -n 100

2. 持久化

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

Redis持久化文件1. AOF模式：appendonly.aof - 记录命令2. RDB模式：dump.rdb - 记录数据
Redis持久化3种时机1. 满足redis.conf配置文件中的save规则2. 执行flushall命令3. 退出Redis

恢复Redis持久化文件到内存1. 重新启动Redis - 会自动加载dir + dbfilename 的文件

2.1 RDB（Redis DataBase）模式 - 针对数据快照 - 默认 - 人类读不懂乱码

RDB优缺点1. 适合大规格数据恢复2. 对数据完整性要求不高1. 需要一定的时间间隔进程操作，Redis意外宕机，最后一次数据修改会丢失2. fork进程时，会占用一定内存空间

2.2 AOF（Append Only File）模式 - 针对Redis命令快照 - 人类可读懂

AOF优缺点appendfsync1. always - 每次修改都同步，文件完整性好2. everysec - 每秒同步一次，可能会丢失一次数据3. no - 从不同步，效率最高缺点1. 对于RDB持久化文件来说，aof远远大于rdb，且恢复效率会慢2. aof运行效率比rdb慢

//开始aof持久化记录 - 配置文件
appendonly yes

测试Redis持久化是否生效

//开启Redsi服务
redis-server  配置文件

//客户端连接Redsi
redis-cli

//随便设置一个键值对
set school gdmu

//获取school，查看是否保存成功
get school

//正常退出Redis - 自动会生成aof文件在redis根目录中
shutdown

exit

//重新连接开启Redis服务，查看是否aof载入内存中
redis-server 配置文件

//可见载入文件成功
get school

2.3 AOF文件经过私自篡改，修复文件

AOF文件错误导致Redis不能启动解决方案1：直接删除appendonly.aof文件2. 使用官方工具进行修复aof文件：命令 - redis-check-aof --fix

//修复aof文件
redis-check-aof.exe --fix <需要修复的AOF文件>

2.4 同时开启 - 两种恢复顺序

1. aof文件：优先使用该文件进行恢复2. rdb文件

2.5 性能建议

1. 1. RDB文件只用作后备用途 - 主从Redis中，建议从Redis进行持久化RDB文件 - 每15分钟一次 - 即 save 900 1
       
2. 1. 如果Enable AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了，代价一是带来了持续的IO，二是AOF rewrite的最后将 rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上，默认超过原大小100%大小重写可以改到适当的数值
       
3. 1. 如果不Enable AOF，仅靠Master-Slave Repllcation实现高可用性也可以，能省掉一大笔10，也减少了rewrite时带来的系统波动。代价是如果Master/Slave同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个Master/Slave中的RDB文件，载入较新的那个，微博就是这种架构

3. 发布订阅（pub/sub） - 消息通信模式

角色1. 消息发布者2. 频道1. 消息订阅者 - 接收消息

//订阅多个渠道 - 【接收消息】
subscribe  <channel> <channel> ...


//发送消息到某个渠道，订阅者接收到message -  【发送消息】
publish <channel> <message>

//退订多个频道
unsubscribe <channel> <channel>

4. 主从复制 - 主机可读可写，从机只能读

注意：只要是某主机的从节点，该节点都是只能读不能写

4.1 概述

1. 数据复制单向 - 只能从主节点到从节点 - Master已写为主，Slave已从为主
    
2. 每台Redis都是主节点，并可以有多个从节点，但是从节点只能有一个主节点Redis
    
3. 建议：单台Redis使用内存超过20G，上Redis集群，减缓内存压力
    
4. 使用命令行配置主从机，如果从机Redis重启，就会变回主机，如果需要变回从机，则需要重新的配置主从命令，一配置自动获取主机的数据

从主机同步流程

Slaver从机连接Master主机成功，发送sync同步命令2. Mster主机接收到同步命令，启动后台进程，将从机的数据文件给从机，完成一次完全同步3. 只要从机重新连接，主机都要给从机完成一次完全同步复制

复制全量复制：从机接收到主机的数据文件，将其存盘并加载到内存增量复制：Master主机将收集到的修改命令依次发送给从机，完成同步
主从复制作用1. 备份：数据热备份2. 故障恢复：主节点失效，从节点顶替主节点3. 并发量提升：读写分离，主节点负责提供写服务，从节点负责读服务4. 高可用：主从复制是哨兵，集群的基础

//查看当前库的信息
info replication

4.2 配置

启动多个Redis，则需要同等的Redis配置文件

//修改的信息
    //1. 端口号  port
    //2. 持久化rdb文件：dbfilename
    //3. 日志文件：logfile
    //4. pid文件：pidfile    -- linux才有

方式1 - 命令配置主从机器 - 只有暂时性

//启动Redis
redis-server  配置文件

//连接Redis
redis-cli -p 端口号

配置一台master机器，两台备用slaver机

//一般只要配置从机即可

//意思是：我是某个ip，端口号的奴隶
slaveof <ip号>   <端口号>

方式2 - 配置文件中配置主从机 - 永久性起作用 - 真实开发场景

Linux - redis.conf文件

//从机的配置文件中 - 配置主机的端口号与Ip地址
replicaof <masterip> <masterport>

//从机配置主机的授权码
masterauth <master-password>

windows - redis.windows.conf文件

//从机的配置文件中 - 配置主机的端口号与Ip地址
slaveof <masterip> <masterport>

//从机配置主机的授权码
masterauth <master-password>

方式3- 从机变主机 - 但一开始从主机同步的数据不会被删除

//变为主机
slaveof no one

5. 哨兵[Sentinal]模式 - Redis集群中自动选举主机 - Linux才有哨兵模式

5.1 概述

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

哨兵作用1. 发送命令，让Redis服务器返回监控状态，包括主、从服务器2. 哨兵监测到master宕机，通过发布订阅模式通知修改配置文件，让其从从机切换为主机3. 一个哨兵进程对Redis服务进行监控 - 可以多哨兵模式 - 哨兵之间会进行互相监控4. 主机1挂了，哨兵自动将某台从机提升为主机2，如果主机1恢复了，又将主机2恢复为主机1的从机

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

5.2 配置

启动哨兵

//创建文件
touch redisSentinel.conf

//往上述文件添加内容
sentinel monitor 被监控名字[随意起] Redis的IP号 端口号   1

//启动哨兵
redis-sentinel redisSentinel.conf

5.3 哨兵配置文件 - Linux

6. 缓存穿透、雪崩、击穿

6.1 概述

缓存问题1. 缓存穿透：用户请求服务器时，Redis缓存，数据库都没有数据 - 缓存，数据库都查不到热点数据2. 缓存击穿：大量用户访问同一个热点数据，如果这个热点数据失效，则大量的请求会瞬间访问数据库 - 请求量大，缓存过期导致3. 缓存雪崩：某个时间段，Redis中的缓存KeyValue集中过期

6.2 缓存穿透解决方案

方案1 - 布隆过滤器 - 丢弃

方案2 - 布隆过滤器 - 不存在则在缓存中存空值

6.3 缓存击穿解决方案

解决方案方案1：设置热点永不过期方案2：加互斥锁【分布式锁】，保证每个key只有一个线程去查询后端服务，其他线程需等待分布式锁释放

6.4 缓存雪崩解决方案

其实集中过期，倒不是非常致命，比较致命的缓存雪崩，是缓存服务器某个节点宕机或断网。因为自然形成的缓存雪崩，一定是在某个时间段集中创建缓存，这个时候，数据库也是可以顶住压力的。无非就是对数据库产生周期性的压力而已。而缓存服务节点的若机，对数据库服务器造成的压力是不可预知的，很有可能瞬间就把数据库压垮。

雪崩情况

解决方案方案1：Redis集群方案2：限流降级 - 缓存失效后，通过加锁、队列来控制读数据库的线程数方案3：数据预热 - 部署前，先把数据预先访问一遍，提前将热点数据缓存放入Redis中方案4：不同的Key设置不同的过期时间