Redis核心原理-白红宇

Redis核心原理

阅读量：3784 次

发布时间：2019-05-22

本文共 2812 字，大约阅读时间需要 9 分钟。

Redis的一些核心原理。

Redis系列介绍：

Redis的基础介绍与安装使用步骤：

Redis的基础数据结构与使用：

Redis核心原理：

Redis 5.0.2 版本的高可用集群搭建：

Redis 5 版本的高可用集群的水平扩展：

Redis 5 集群选举原理分析:

优秀博客：

一、Redis的单线程和高性能

Redis 单线程为什么还能这么快？

因为它所有的数据都在内存中，所有的运算都是内存级别的运算（纳秒），而且单线程避免了多线程的切换（上下文切换）性能损耗问题。正因为 Redis 是单线程，所以要小心使用 Redis 指令，对于那些耗时的指令(比如keys)，一定要谨慎使用，一不小心就可能会导致 Redis 卡顿。

Redis 单线程如何处理那么多的并发客户端连接？

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

Nginx也是采用IO多路复用原理解决C10K问题。

c10k：

持久化

RDB快照（snapshot）

在默认情况下， Redis 将内存数据库快照保存在名字为dump.rdb的二进制文件中。

你可以对 Redis 进行设置，让它在N秒内数据集至少有M个改动这一条件被满足时，自动保存一次数据集。

比如说，以下设置会让 Redis 在满足60秒内有至少有1000个键被改动”这一条件时，自动保存一次数据集：

save 60 1000

redis.conf文件里面有默认的3种情况，3种是或的关系

AOF（append-only file）

快照功能并不是非常耐久（durable）：如果 Redis 因为某些原因而造成故障停机，那么服务器将丢失最近写入、且仍未保存到快照中的那些数据。从 1.1 版本开始， Redis 增加了一种完全耐久的持久化方式： AOF 持久化，将修改的每一条指令记录进文件

你可以通过修改配置文件来打开 AOF 功能：

appendonly yes

开启后，每当 Redis 执行一个改变数据集的命令时（比如SET），这个命令就会被追加到 AOF 文件的末尾。

这样的话，当 Redis 重新启时，程序就可以通过重新执行 AOF 文件中的命令来达到重建数据集的目的。

你可以配置 Redis 多久才将数据fsync到磁盘一次。

有三个选项：

每次有新命令追加到 AOF 文件时就执行一次fsync：非常慢，也非常安全。

每秒fsync一次：足够快（和使用 RDB 持久化差不多），并且在故障时只会丢失 1 秒钟的数据。

从不fsync：将数据交给操作系统来处理。更快，也更不安全的选择。

RDB 和 AOF ，我应该用哪一个？

如果你非常关心你的数据，但仍然可以承受数分钟以内的数据丢失，那么你可以只使用 RDB 持久化。

有很多用户都只使用 AOF 持久化，但我们并不推荐这种方式：因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份，并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快。

Redis 4.0 混合持久化

重启 Redis 时，我们很少使用 rdb 来恢复内存状态，因为会丢失大量数据。我们通常使用 AOF 日志重放，但是重放 AOF 日志性能相对 rdb 来说要慢很多，这样在 Redis 实例很大的情况下，启动需要花费很长的时间。 Redis 4.0 为了解决这个问题，带来了一个新的持久化选项——混合持久化。AOF在重写(aof文件里可能有太多没用指令，所以aof会定期根据内存的最新数据生成aof文件)时将重写这一刻之前的内存rdb快照文件的内容和增量的 AOF修改内存数据的命令日志文件存在一起，都写入新的aof文件，新的文件一开始不叫appendonly.aof，等到重写完新的AOF文件才会进行改名，原子的覆盖原有的AOF文件，完成新旧两个AOF文件的替换；

aof 根据配置规则在后台自动重写，也可以人为执行命令bgrewriteaof重写AOF。于是在 Redis 重启的时候，可以先加载 rdb 的内容，然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放，重启效率因此大幅得到提升。

开启混合持久化：

aof-use-rdb-preamble yes

混合持久化aof文件结构

缓存淘汰策略(解决数据热点问题)

当 Redis 内存超出物理内存限制时，内存的数据会开始和磁盘产生频繁的交换 (swap)。交换会让 Redis 的性能急剧下降，对于访问量比较频繁的 Redis 来说，这样龟速的存取效率基本上等于不可用。

在生产环境中我们是不允许 Redis 出现交换行为的，为了限制最大使用内存，Redis 提供了配置参数 maxmemory 来限制内存超出期望大小。

当实际内存超出 maxmemory 时，Redis 提供了几种可选策略 (maxmemory-policy) 来让用户自己决定该如何腾出新的空间以继续提供读写服务。

noeviction

不会继续服务写请求 (DEL 请求可以继续服务)，读请求可以继续进行。这样可以保证不会丢失数据，但是会让线上的业务不能持续进行。这是默认的淘汰策略。

volatile-lru

尝试淘汰设置了过期时间的 key，最少使用的 key 优先被淘汰。没有设置过期时间的 key 不会被淘汰，这样可以保证需要持久化的数据不会突然丢失。

volatile-ttl

跟上面一样，除了淘汰的策略不是 LRU，而是 key 的剩余寿命 ttl 的值，ttl 越小越优先被淘汰。

volatile-random

跟上面一样，不过淘汰的 key 是过期 key 集合中随机的 key。

allkeys-lru

区别于 volatile-lru，这个策略要淘汰的 key 对象是全体的 key 集合，而不只是过期的 key 集合。这意味着没有设置过期时间的 key 也会被淘汰。

allkeys-random跟上面一样，不过淘汰的策略是随机的 key。

volatile-xxx

策略只会针对带过期时间的 key 进行淘汰，allkeys-xxx 策略会对所有的 key 进行淘汰。如果你只是拿 Redis 做缓存，那应该使用 allkeys-xxx，客户端写缓存时不必携带过期时间。如果你还想同时使用 Redis 的持久化功能，那就使用 volatile-xxx 策略，这样可以保留没有设置过期时间的 key，它们是永久的 key 不会被 LRU 算法淘汰。