Redis核心原理详细解说

1、Redis为何这么快

C语言编写

网络IO是nio

单线程避免了多线程上下文切换酿成的性能消耗

在内存中运算速度不错

2、Redis网络模型

IO多路复用（reactor）

redis利用epoll实现IO多路复用，将连接信息和事件放到队列中，顺次放到文件事件分派器，事件分派器将事件分发给事件处理器。

3、Redis数据结构

4、Redis持久化

RDB快照（snapshot）

配置# save 60 1000 //关闭RDB只需要将所有的save保存策略注释掉便可

AOF（append-only file）

将修改的每条指令记录进文件appendonly.aof中（先写入os cache，每隔一段时间fsync到磁盘）。

AOF重写：AOF文件里可能有太多没用指令，所以AOF会定期根据内存的最新数据生成aof文件。AOF重写redis会fork出一个子进程去做（与bgsave命令类似），不会对redis正常命令处理有太多影响。bgrewriteao手动重写。

Redis 4.0 混合持久化：aof-use-rdb-preamble yes

如果开启了混合持久化，AOF在重写时，不再是单纯将内存数据转换为RESP命令写入AOF文件，而是将重写这一刻之前的内存做RDB快照处理，并且将RDB快照内容和增量的AOF修改内存数据的命令存在一起，都写入新的AOF文件，新的文件一开始不叫appendonly.aof，等到重写完新的AOF文件才会进行改名，覆盖原本的AOF文件，完成新旧两个AOF文件的替换。因而在 Redis 重启的时候，可以先加载 RDB 的内容，然后再重放增量 AOF 日志就能够完全替换之前的 AOF 全量文件重放，因此重启效力大幅得到提升。

RDB与AOF区分

Redis数据备份策略

• （1）写crontab定时调度脚本，每小时都copy一份rdb或aof的备份到一个目录中去，仅仅保存最近48小时的备份。
• （2）每天都保存一份当日的数据备份到一个目录中去，可以保存最近1个月的备份。
• （3）每次copy备份的时候，都把太旧的备份给删了。
• （4）每天晚上将当前机器上的备份复制一份到其他机器上，以防机器破坏。

5、Redis管道（Pipeline）

客户端可以一次性发送多个要求而不用等待服务器的响应，待所有命令都发送完后再一次性读取服务的响应，这样可以极大的下降多条命令履行的网络传输开消，管道履行多条命令的网络开消实际上只相当于一次命令履行的网络开消。需要注意到是用pipeline方式打包命令发送，redis一定要在处理完所有命令前先缓存起所有命令的处理结果。打包的命令越多，缓存消耗内存也越多。所以其实不是打包的命令越多越好。

pipeline中发送的每一个command都会被server立即履行，如果履行失败，将会在尔后的响应中得到信息；也就是pipeline其实不是表达“所有command都一起成功”的语义，管道中前面命令失败，后面命令不会有影响，继续履行。

6、Redis使用lua脚本

• 1、减少网络开消：本来5次网络要求的操作，可以用一个要求完成，本来5次要求的逻辑放在redis服务器上完成。使用脚本，减少了网络来回时延。这点跟管道类似。
• 2、原子操作：Redis会将全部脚本作为一个整体履行，中间不会被其他命令插入。管道不是原子的，不过redis的批量操作命令(类似mset)是原子的。
• 3、替换redis的事务功能：redis自带的事务功能很鸡肋，而redis的lua脚本几近实现了常规的事务功能，官方推荐如果要使用redis的事务功能可以用redis lua替换。

7、Redis散布式锁

nx通过同享内存实现

8、Redis主从架构

9、Redis哨兵架构

sentinel哨兵是特殊的redis服务，不提供读写服务，主要用来监控redis实例节点。

10、Redis集群

11、Redis优化

• 1、redis配置

公道的配置最大连接数；最大，最小空闲数。

• 2、规约
• 3、慢日志

slowlog

• 4、操作系统配置

（1）vm.swapiness

如果linux内核版本<3.5，那末swapiness设置为0，这样系统宁愿swap也不会oom killer（杀掉进程）

如果linux内核版本>=3.5，那末swapiness设置为1，这样系统宁愿swap也不会oom killer

（2）公道设置文件句柄数

12、Redis问题

缓存穿透

缓存穿透是指查询一个根本不存在的数据，缓存层和存储层都不会命中，通常出于容错的斟酌，如果从存储层查不到数据则不写入缓存层。缓存穿透将致使不存在的数据每次要求都要到存储层去查询，失去了缓存保护后端存储的意义。

• 第一，本身业务代码或数据出现问题。
• 第二，一些歹意攻击、爬虫等造成大量空命中。

（1）缓存空对象

（2）布隆过滤器

缓存失效（击穿）

由于大批量缓存在同一时间失效可能致使大量要求同时穿透缓存直达数据库，可能会造成数据库瞬间压力过大乃至挂掉，对这类情况我们在批量增加缓存时最好将这一批数据的缓存过期时间设置为一个时间段内的区别时间。

缓存雪崩

• （1）保证缓存层服务高可用性，比如使用Redis Sentinel或Redis Cluster。
• （2）依赖隔离组件为后端限流熔断并降级。比如使用Sentinel或Hystrix限流降级组件。比如服务降级，我们可以针对区别的数据采取区别的处理方式。当业务利用访问的是非核心数据（例如电商商品属性，用户信息等）时，暂时停止从缓存中查询这些数据，而是直接返回预定义的默许降级信息、空值或是毛病提示信息；当业务利用访问的是核心数据（例如电商商品库存）时，依然允许查询缓存，如果缓存缺失，也能够继续通过数据库读取。
• （3）提早演练。在项目上线前，演练缓存层宕掉后，利用和后真个负载情况和可能出现的问题，在此基础上做一些预案设定。

到此这篇关于Redis核心原理详细解说的文章就介绍到这了,更多相关Redis原理内容请搜索之前的文章或继续浏览下面的相关文章希望大家以后多多支持！