redis高可用：

redis高可用：

redis当中，高可用概念更宽泛一些。

除了正常服务以外，数据量的扩容，数据安全。

实现高可用的方式：

1、持久化，最简单的高可用方法，主要功能就是备份数据。

把内存当中的数据保存到硬盘当中。

2、主从复制

3、在主从复制的基础之上，部署哨兵模式。

4、redis的集群。

redis的持久化：

内存当中的数据，保存到硬盘

开启持久化之后，会有一个持久化的文件。通过文件进行恢复。

redis提供的持久化方式：

RBD持久化：定时的将内存当中的数据保存到磁盘上，类似于快照的形式用二进制压缩存储。后缀名是.rdb

每次redis重新启动时，都会读取快照文件，进行恢复。默认的持久化方式。

 254 dbfilename dump.rdb
 255 #rdb持久化的默认文件

 269 dir /var/lib/redis/6379
 270 #RDB文件的默认存放位置

 219 save 900 1
 220 #当时间到900秒，如果redis的数据发生了1次变化，就>     会执行bgsave
 221 save 300 10
 222 #当时间到300秒，如果redis的数据发生了10次变化，就
     会执行bgsave
 223 save 60 10000 224 #当时间到60秒，如果redis的数据发生了10000次变化，     就会执行bgsave
 225 #save m n 只是配置文件当中的配置项，redis执行的命
     令是bgsave。

save不能直接在命令行执行。一旦执行了save，redis的主进程会进入阻塞状态，读写都将不能进行。

直到save完成，才能继续读写，save在生产时是禁用的。

bgsave就是rbd快照保存的方式。

bgsave在执行关闭redis服务的时候，也会自动执行bgsave

bgsave是主从复制的默认恢复模式，从节点执行全量恢复操作。主节点通过bgsave命令把rdb发生给从节点。除了配置文件 save m n 关闭redis会执行bgsave，开启redis也会执行bgsave

AOF持久化：

他是把操作的数据库指令以日志的形式保存到指定的文件当中，文件的后缀名.aof。类似于mysql的binlog。

没有时间，没有位置，只有命令。

AOF持久化的实时性很好，只要是操作了都会记录在日志文件中，进程出现意外时，丢失的数据更少，AOF是主流的持久化方式。

ROB和AOF两者是配合使用的。

AOF默认是关闭的，需要开启。如果同时开启RDB和AOF，哪个优先级高？

一旦开启AOF，系统默认选择AOF进行恢复。

 706 appendonly yes         #把no改为yes就是打开AOF持久化
 736 appendfsync everysec
 737 #每秒都会主动更新一次
 759 no-appendfsync-on-rewrite no
 760 #不是每次都一定要对AOF文件进行重写，手动来对AOF文件进行重写？
 804 aof-load-truncated yes
 805 #如果发现AOF文件被截断，redis在启动时会自动修改AOF文件，尽可能的对数据进行恢复。
 806 #一旦变成no，redis发现文件被截断，redis就会拒绝启动
[root@test3 ~]# /etc/init.d/redis_6379 restart      #重启配置文件

重写：

充分非必要条件

一旦开启AOF持久化之后，所有的数据库操作记录必然都会写入AOF持久化文件当中。

AOF的文件会越来越大。

AOF的文件越大，记录的操作就越多，一旦要回复，速度会很慢。

重写就是为了压缩AOF持久化文件。

重写就是把源内容压缩，后续新的读写，继续插入AOF文件

RDB持久化和AOF持久化之间的优缺点：

RDB文件小，传输速度快，适合全量复制。

恢复速度也比AOF快

性能上影响较小

AOF：秒级持久化，数据量全，兼容性好。

缺点：文件大，恢复速度慢，性能影响大。

但是，AOF支持全量和增量。数据安全大于一切。

redis性能管理：

used_memory:853624      #字节     redis中的数据占用内存的大小
used_memory_rss:10555392        #字节     redis向系统申请的内存。随着数据占用的大小，自动扩容
used_memory_peak:916480     #占用系统内存的峰值
[root@test3 ~]# vim /etc/redis/6379.conf     
    `573  maxmemory 2gb`
     574 #设置redis占用系统的阈值

内存碎片化率：

内存碎片化率=redis向系统申请的内存/redis数据实际占用的内存

[root@test3 ~]# redis-cli info memory | grep ratio
allocator_frag_ratio:1.36
#分配器的碎片化比例，值越大，碎片越多，导致内存浪费
allocator_rss_ratio:4.83
#分配器占用物理内存的比例
rss_overhead_ratio:1.21
#表示占用物理内存的额外的开销的比例，这个值越小越好。redis实际使用的物理内存比rss更接近
mem_fragmentation_ratio:12.99
#内存的碎片比例，已经分配的内存，但是没有使用的内存，这个值也是越低越好，表示内存利用率更高。
​
1364  activedefrag yes      #这几行都取消注释
1367  active-defrag-ignore-bytes 100mb
1370  active-defrag-threshold-lower 10
1373  active-defrag-threshold-upper 100
1376  active-defrag-cycle-min 5
1379  active-defrag-cycle-max 75
1383  active-defrag-max-scan-fields 1000

追求安全性的双一设置：

innodb_flush_log_at_trx_commit=1 0: 事务提交时不刷新事务日志，而是每秒进行一次日志刷新。这可以提高性能， 但在发生故障时可能会导致数据丢失。

1: 默认值。每次事务提交时都会刷新事务日志，以确保事务持久性。 这提供了最高级别的数据安全性，但可能会影响性能。

2: 事务提交时将事务日志写入操作系统缓存，但不进行物理刷新。 这提供了一定的数据安全性和性能。

sync_binlog=1 0: 二进制日志写入操作系统缓存，但不进行物理刷新。这提供了最高性能， 但在发生故障时可能会导致数据丢失。

1: 默认值。每次事务提交时，将二进制日志刷新到磁盘，以确保日志的持久性。 这提供了较高级别的数据安全性。

N: 每次事务提交时，将二进制日志刷新到磁盘，但最多每 N 个事务执行一次物理刷新。 这在某些情况下可以提高性能，但在发生故障时可能会导致少量数据丢失。

面试题：

缓存击穿：

redis的缓存数据有一部分丢失了，导致请求转发到了数据库。或者是缓存刚刚过期，新缓存还没有建立，请求都转发到了数据库。

防范机制：

1、热点缓存数据一般设置为永不过期

2、持久化，高可用

我发现经常使用的热点语句，查询速度突然变得很慢，查找问题，发现改热点数据对应的缓存键值对消失了。

因为我没有redis的密码，我报告给了数据库的部门。

我进入了redis的数据库

set重新创建了这个热点数据的缓存，解决了这个问题。

缓存穿透：

80%以上是黑客攻击。

利用缓存和数据库里面都没用的数据，用户一直在发起请求。

利用大量的请求压垮数据库，从而导致整个网站崩溃。

防火墙 只能起到一定的作用

验证拦截（消息队列） 需要手动完成，可以判断是否是攻击行为。

缓存空的数据，id=-1 test=-1

把一些空数据，也设置缓存，生命周期短一些，以防止恶意攻击

缓存雪崩：

redis产生了大面积的故障（缓存数据丢失），所有的请求全部转发到了数据库。

数据库不适合高并发，很快集群就会崩溃，然后整个系统瘫痪。

1、人为————踩缝纫机

2、缓存数据大量的同时过期，新的缓存没有及时生成

3、redis服务集群崩溃

怎么防备：

1、redis集群一定要做高可用方案

持久化，主从，哨兵，集群。

2、访问量过大，甚至超过了redis本身的负载能力。

熔断机制 Hystrix可以实现熔断，降级，限流来降低雪崩的概率。