Redis基础知识

文件重写

redis进程

AOF文件

集群

Redis基于C语言开发

bgsave

解决方法

String：一个key对应一个数据结构，最基础的数据结构

哨兵是一个监视主节点状态的一个工具（一个单独的进程），是高可用的解决方案，哨兵会监视多个主节点以及从节点，当主节点宕机时会挑出一个次节点来代替主节点，保证redis服务的可用性，服务重启后也不会变为主节点哨兵也可用做集群相互监督，多哨兵模式

优点：RDB是一个紧凑的压缩文件，是redis在某一时间点的所有数据的备份，速度远比AOF快，非常适合备份、全量复制、灾难性复制

数据结构

主从复制

生成RDB文件

主观下线：（适用于主、从节点）某哨兵不我们配置的一定时间内没有收到目标节点的恢复则判断为下线

always

写命令

ZSet(有序集合)：与Set非常相似， 但每个元素的Vuale值都有一个score（可重复），会对元素进行排序

子进程

客观下线：（适用于主节点）一个哨兵发现一个主节点宕机后，会去询问其他的哨兵去对主节点进行监视判断，如果有一般以上超过则为下线

no

流程

eversec

将一台服务的数据复制到另一台服务上，前者为主节点，后者为从节点。复制是单向的只能由主节点复制到从节点。主节点主要进行写，从节点主要进行读（实现一个负载均衡的效果）。复制是异步的。

缓存出现的问题

Y

文件同步

fork创建子线程

当节点做全量复制的时候，主节点会自动执行bgsave，并把RDB文件传给子节点

优缺点

缺点：bgsave的每次操作都要执行fork创建子线程，属于重量级操作，频繁执行成本过高，所以无法做到实时持久化，或秒级持久化

每次写入缓存区后，每秒由专门的线程去同步，做到了安全与效率，是建议的同步策略也是AOF默认的策略

save

为什么需要持久化？

命令结束

应用场景：单值缓存（最常见）、对象缓存、分布式锁、文章的点赞转发数（计数器）

把我们每次所写的指令追加到日志中，需要恢复数据的时候执行日志中的指令就可以了，解决redis持久化的实时性，也是目前主流的持久化方案（默认不开启需要配置文件开启）

信号量通知

为什么要使用集群？防止单点故障，当只有一台redis服务时并且宕机，程序将出问题，讲数据压力按一定规则分配到不同的服务器上，减少服务器的压力还要内存的问题，一台redis服务最多可用内存为20g

sunion 并集：在所有集合中出现过至少两次的元素sinter 交集：将多个集合的元素合并到一起，并去掉重复元素sdiff 差集：在第一个集合中存在，在其他集合中都不存在的元素

投票选举：谁发现谁去处理，哨兵会按照一定的规则去处理故障转移

执行save会手动触发RDB持久化，但会导致redis服务阻塞，直到RDB持久化完成，大量数据时会导致长时间的阻塞，所以不推荐使用

List：列表结构，相当于java中的LinkedList，添加删除快，索引定位慢

结束线程

redis数据存储在内存的，如果没有数据持久化，当redis宕机或重启的时候，数据则会丢失

哨兵

具体流程

文件同步策略

数据加载

应用场景：抽奖，随机拿取一个从集合中移除、点赞（收藏）、关注（感兴趣的人、共同该关注的）、电商商品筛选

将当前数据以快照的形式存储在磁盘中，RDB可以自动触发也可以手动触发

判读是否有子线程存在

每次指令写入缓存不进行同步，同步由操作系统来控制，我们不可控

解决高并发（三高）问题

执行shutdown的时候没有开启AOF持久化也会自动触发bgsave操作

一款非关系型数据库，数据存储在内存，拥有丰富的数据结构，单线程，在开发过程中常用于缓存数据

基础知识

1.缓存穿透：布隆过滤器、判读添加相应缓存2.缓存击穿：限流策略、数据库集群实现负载均衡、缓存key永不过期3.雪崩：设置缓存key永不过期、上线时提前预热、设置缓存消失的时间不同

AOF

执行bgsave

持久化

手动触发

追加

1.redis事务的概念：本质上是一组指令的集合，redis可以一次性执行多个指令，在事务执行时，其他客户端的指令请求不会到集合中2.redis事务有没有隔离级别：redis没有隔离级别，不存在脏读、幻读、不可重复读的问题出现3.redis不存在原子性：事务中任何指令执行失败，其他指令也会执行，不保证原则性且不具有回滚4.redis的事务的三个阶段：开启事务-->指令入队-->执行事务5.redis事务指令：discard:取消事务，放弃执行事务块中所有指令                            exec:执行                            multi:事务开启（事务块）                            watch：监视一个和多个key（被监视的key value事务执行前发生改变事务将被打断）                            unwatch：取消watch对所有的key监听（无论事务使用执行成功，watch对变量的监控都将被取消）

RDB

执行debug reload的时候也会自动执行bgsave

事务

自动触发

在配置文件中设置了相关设置 save m n表示在m秒内被修改n次就自动执行bgsave

Set(集合)：相当于Java中HashSet，无序唯一的；但集合内部的最后一个元素被移除后，数据结构会被回收

应用场景：订阅微博和公众号的消息，a来消息了移除，加入msg后加入第一个

hash（字典）：相当于java中的HashMap，内部实现也差不多，数组+链表的方式存在

应用场景：对象缓存，电商购物车优点：同类数据归类，方便整理、相对String内存资源消耗更小缺点：过期功能不能使用在字段上、集群架构下不适合大量使用（key相同的经过hash后只会落在其中一台机器上）

AOF缓存区

bgsave与save不同的是，一般情况下不会出现阻塞，redis进程会执行fork操作创建子线程去执行持久化，阻塞只会出现在子线程一般时间很短

每次指令写入缓存就同步到AOF文件中，磁盘操作比较慢，限制了redis高并发，一般不推荐使用

应用场景：微博热搜榜，用户点击文章热度+1

1.手动触发：使用bgrewriteaof2.自动触发：服务器配置方式自动触发

总结：redis事物提供了一种将多个命令打包，有序、一次性执行机制命令到事物队列中，然后按先进先出(FIFO)的顺序执行。事务在执行过程中不会被中断，当事务队列中的所有命令都被执行完毕之后，事务才会结束。Redis事务不支持回滚机制。

N

1.缓存穿透：大量请求一条缓存、数据库不存在的数据导致数据库宕机      2.缓存击穿：大量请求数据并且缓存突然失效，直接请求到数据库上，导致数据库宕机3.雪崩：是指在某一个时间段，缓存集中过期失效或者Redis宕机，导致数据直接请求到数据库

作用：1.redis持久化只能同通过AOF和RDB实现数据备份，并不是非常安全，把数据复制另一台服务器上保证数据的安全性 2.进行读写分离，可以实现服务器的负载均衡，降低各个服务器的压力3.可以配合哨兵模式，达到高可用的性能，当一个主节点宕机后，哨兵会通过一定的规则，从从节点中选出一个为主节点，保证redis服务的不间断

重写

恢复数据