Redis的高可用
redis当中，高可用的概念更宽泛一些，除了正常服务以外，数据量的扩容，数据安全
1、实现高可用的方式
1.1 持久化，最简单的高可用的方法，主要作用就是备份数据，把内存当中的数据保存到硬盘当中
1.2 主从复制
1.3 在主从复制的基础上，部署哨兵模式
1.4 redis的集群
redis的持久化：内存当中的数据，保存到硬盘，开启持久化之后，会有一个持久化的文件，通过文件进行恢复
2、redis持久化方式
1.1 RDB持久化
定时的将内存当中的数据保存到磁盘上，类似于快照的形式用二进制压缩存储。后缀名是.rbd
每次redis重新启动时，都会读取快照文件进行恢复，默认的持久化方式
vim /etc/redis/6379.conf
219行 save 900 1
# 当前时间到900秒,如果redis的数据发生1次变化，就会执行bgsave
220行 save 300 10
# 当时间到300秒,如果redis发生10次变化，就会执行bgsave
221行 save 60 10000
# 当时间到60秒,如果redis发生10000次变化，就会执行bgsave
254行 dbfilename dump.rdb
#rbd持久化的文件名
wq!
bgsave命令
# save m n 只是配置文件当中的配置项，redis执行的命令是bgsave
# save不能直接在命令行执行,一旦执行了save，redis的主进程会进入阻塞状态，读写都将不能进行，直到save完成，才能继续读写，在生产中是禁用的
# bgsave 就是rbd快照保存的方式。
# 在执行关闭Redis服务的时候也会自动执行bgsave
# bgsave总结：主从复制的默认恢复模式，从节点执行全量恢复操作，主节点通过bgsave命令把rdb发送给从节点，除了配置文件的save m n，还有关闭redis会执行bgsave，开启redis也会执行bgsave
RDB工作方式
RDB实验
systemctl stop firewalld
setenforce 0
redis-cli -h 192.168.100.21 -p 6379
在数据库里面创建键值对
cd /var/lib/redis/6379 # ls出现dump.rdb 删除部分键值对
/etc/init.d/redis_6379 stop # 备份的时候需要把服务关闭
cp dump.rdb /opt
删除/var/lib/redis/6379目录下的dump.rdb
cp /opt/dump.rdb /var/lib/redis/6379 # 备份
/etc/init.d/redis_6379 start #开启服务的时候会自动读取rdb文件，此时再进入软件查看，恢复成功
1.2 AOF持久化
是把操作的数据库指令以日志的形式，保存在指定的文件当中，文件的后缀名.aof，类似于mysql的binlog。
没有时间、没有位置，只有命令
AOF持久化的实时性更好，只要是操作了，都会记录在日志文件中，进程出现意外时，丢失的数据更少，AOF是主流的持久化方式
RDB和AOF两者是配合使用
AOF默认是关闭，需要开启，如果同时开启RDB和AOF，哪个优先级高？
一旦开启，系统默认选择AOF进行恢复
vim /etc/redis/6379.conf
700行 appendonly yes
# 把no修改为yes
704行 appendfilename 'appendonly.aof'
730行 appendfsync everysec
# 每秒都会主动更新一次
752行 no-appendfsync-on-rewrite no
# 不是每次都一定要对aof文件进行重写，手动对aof进行重写
796行 aof-load-truncated yes
# 如果发现aof文件被截断，redis启动时会自动修复aof的文件，尽可能得对数据进行恢复
# 如果是no，那么redis发现文件被截断，将会拒绝启动
wq!
/etc/init.d/redis_6379 restart
# 重启之后会出现appendonly.aof文件
AOF工作方式
AOF实验
redis-cli -h 192.168.100.21 -p 6379
在数据库中创建多个键值对
bgrewriteaof
exit
vim /var/lib/redis/6379/appendonly.aof
# 文本出现以二进制压缩形式刚刚创建的文件
删除刚刚创建的部分键值对
vim /var/lib/redis/6379/appendonly.aof
# del有刚刚删除键值对的名字，把del下面删除
/etc/init.d/redis_6379 restart # 刷新，删除键值对恢复
重写：充分非必要条件
一旦开启AOF持久化之后，所有的数据库操作记录必然都会写入AOF持久化文件当中
AOF文件会越来越大，AOF文件越大，记录的操作越多，一旦要恢复，速度会很慢
重写就是为了压缩AOF持久化文件
重写就是把原内容压缩，后续新的读写继续插入AOF文件
1.3 RDB和AOF
RDB：文件小，传输的速度也很快，是主从复制的默认模式。适合全量复制，恢复速度也比AOF快，性能上影响较小
缺点：数据安全性较低、可读性低
AOF：秒级的持久化，数据量全，兼容性好
缺点：文件大，恢复速度慢，性能影响大，但是支持全量和增量，数据安全大于一切
3、redis性能的管理
redis-cli -h 192.168.100.21 -p 6379
info memory # 查看redis的指标
used_memory:874496字节 redis中的数据占用内存的大小
used_memory_rss:10588160字节 redis想系统申请的内存，随着数据占用的大小，自动扩容
used_memory_peak:874496占用系统内存的峰值
vim /etc/redis/6379.conf
573 maxmemory 2gb # 设置redis占用系统的阈值
## 这个一定要设置，资源限制一定要设置
4、内存碎片化率
内存碎片化率=（redis向系统申请的内存/redis数据实际占用的内存）
查看内存碎片化率命令：redis-cli info memory | grep ratio
allocator_frag_ratio:1.28分配器的碎片化率，值越大，碎片越多，导致内存浪费
allocator_rss_ratio:5.32分配器占用物理内存的比例
rss_overhead_ratio:1.38表示占用物理内存的额外开销的比例，这个值越小越好。redis实际使用的物理内存比rss更接近
mem_fragmentation_ratio:15.25内存的碎片比例，已经分配的内存，但是没有使用的内存，这个值越低越好，越低，内存利用率更高
自动清理：不推荐！
vim /etc/redis/6379.conf
1354行 activedefrag yes # 取消注释 # 表示自动清理 下面active开头的要全部取消注释，这样自动清理才有意义
手动清理：推荐！
终端：redis-cli memory purge
数据库：memory purge
5、redis常见问题：
1、缓存击穿
我发现我经常使用的热点语句，查询速度突然变更很慢，查找问题，发信该热点数据对应的缓存键值对消失了
解决：因为我没有redis的密码，我报告给了数据库的部门
我进入了redis数据库用set创建了这个热点数据的缓存，解决了这个问题
产生原因：
redis的缓存数据有一部分丢失，导致请求转发到了数据库，或者是缓存刚刚过期，新换成还没有建立，请求都转发到了数据库
防范机制：
热点缓存数据设置成永不过期
持久化、高可用
2、缓存雪崩
redis产生了大面积的故障（缓存数据全部丢失），所有的请求全部转发到了数据库，数据库不适合高并发，很快集群就会崩溃，然后整个系统瘫痪。
产生原因：
1.1 人为====踩缝纫机
1.2 缓存数据大量的同时过期，新的缓存没有及时生成
1.3 redis服务集群崩溃
怎么防备：
1.1 redis集群必须做高可用方案（持久化、主从、哨兵、集群）
1.2 访问量过大，甚至超过redis本身的负载能力，熔断机制Hystrix可以实现熔断，降级，限流来降低雪崩的概率
3、缓存穿透
80%以上是黑客在攻击
利用缓存和数据库里面都没有的数据，用户一直发起请求
利用大量的请求压垮数据库，从而导致整个网站崩溃
防火墙，只能起到一定的作用
验证拦截（消失队列）需要手动完成，可以判断是否是攻击行为
缓存空的数据，
备：
1.1 redis集群必须做高可用方案（持久化、主从、哨兵、集群）
1.2 访问量过大，甚至超过redis本身的负载能力，熔断机制Hystrix可以实现熔断，降级，限流来降低雪崩的概率
3、缓存穿透
80%以上是黑客在攻击
利用缓存和数据库里面都没有的数据，用户一直发起请求
利用大量的请求压垮数据库，从而导致整个网站崩溃
防火墙，只能起到一定的作用
验证拦截（消失队列）需要手动完成，可以判断是否是攻击行为
缓存空的数据，
把一些空数据也设置成缓存，生命周期短一些，一防止恶意攻击
4万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
