Redis简单介绍

目录

1、Redis简介

2、Redis主要能做什么

3、Redis和Memcached的区别以及与其他数据库的区别

4、Redis的五种数据类型

5、Redis的持久化功能

RDB（快照）

AOF（只追加文件）

6、Redis的数据淘汰策略

7、Redis的主从复制

Redis全称为Remote Dictionary Server（远程数据服务），是一款开源的基于内存的键值对存储系统，其主要被用作高性能缓存服务器使用，当然也可以作为消息中间件和Session共享等。Redis独特的键值对模型使之支持丰富的数据结构类型，即它的值可以是字符串、哈希、列表、集合、有序集合，而不像Memcached要求的键和值都是字符串。同时由于Redis是基于内存的方式，免去了磁盘I/O速度的影响，因此其读写性能极高。

那何为基于内存呢？我们知道数据存储模式分为磁盘存储模式与内存存储模式，传统的数据库将数据直接存储在磁盘中，受到磁盘I/O性能的影响，而Redis则是将数据存储在内存中，因此其运行速度极快，两种模式简易图如下：

磁盘数据库的工作模式：

内存数据库的工作模式：

a、缓存，这毫无疑问是Redis被大众所熟知的功能，也是其最强大的功能之一，在提示服务器性能方面非常有效

b、排行榜功能，利用Redis中有序集合的特性可以很容易的实现排行榜功能，由于排行榜功能一般都要求实时性，如果采用传统数据库来实现将会非常麻烦。

c、计数器/限速器，利用Redis中原子性的自增操作，我们可以统计类似用户点赞数、用户访问数以及在需要限制某些用户访问某个api的频率时（例如抢购），我们均可以使用Redis来代替传统数据库实现，因为传统数据库在实现该类需求时会有非常大的读写压力。

d、好友关系，利用集合的一些命令，如交集、差集、并集等能方便的搞定一些共同好友及共同爱好等功能

e、简单消息队列，除了Redis自身的发布/订阅模式，我们也可以使用其List来实现一个简单的消息队列，例如：到货通知、邮件发送之类的需求，不需要高可靠但是会带来非常大的db压力，完全可以用List来完成异步解耦

f、session共享，一般情况下session都是存在服务器的文件中，在集群部署下，同一用户登陆时session文件可能落在不同的服务器上，因此导致了频繁的登陆操作，采用Redis保存session信息后，无论用户访问到哪台机器都能够获取到对应的session信息。

当然Redis也不是万能的，如果某部分数据内容非常大或者说该部分数据访问频率很低，那么这部分数据便不建议存储在Redis中，数据太大会增加成本，访问频率过低则非常浪费内存资源

这两者都是基于内存的高性能缓存服务器，常常被拿来作比较，常见区别如下：

a、Redis和Memcached都是将数据放在内存中，都是高性能缓存服务器，但是Memcached还可以缓存其他东西，如图片和视频

b、Memchched缓存数据时要求键和值都是字符串类型，而Redis的值支持丰富的数据类型，即字符串、哈希、列表、集合、有序集合

c、Redis支持数据的持久化，可通过设置每隔一段时间将数据持久化到磁盘，因此在断电时Redis的数据不至于全部丢失，而Memcached则将全部丢失。同样的由于其持久化功能，在灾难恢复场景时Redis也可以通过AOF进行部分数据恢复，而Memcached则没有任何办法。

d、两者使用场景也不同，Redis不仅可以作为缓存，也可以作为简单的消息队列和Session共享使用，而Memcached仅是作为缓存使用

下面给出一张图表明Redis与其他数据库的区别：

就总体看下这五种数据类型的大致介绍及区别，至于具体命令有兴趣可自行google，或者走我的另外一篇文章查看部分命令：Redis部分命令

我们都知道Redis作为一款内存服务器，就算我们对自己的服务器足够信任，不会出现任何软件或硬件上的故障，但一旦出现突然断电等异常情景，内存中的数据仍将一并丢失，因此我们需要向传统关系型数据库一样对数据进行持久化，幸好Redis也提供了持久化功能，使得在数据丢失后或服务重启后能快速恢复到之前的数据。

Redis的持久化方式大致分为两种：

即我们常说的备份，它可以通过配置文件中的配置信息定期对数据进行备份，即将Redis中的数据持久化到硬盘中，这也是Redis 默认的持久化方式。

所产生的文件格式默认为：dump.rdb

rdb的持久化配置

我们需要使用rdb的持久化功能，首先就是对其进行配置，Redis默认也是开启了rdb配置，大致有关的配置如下：

具体配置其实也比较简单，主要是针对时间策略的配置：

save 900 1：表示900s内如果有1次写操作，那么就触发一次快照，即将数据备份到rdb文件中，下面两个save命令同理，之所以会配置多条时间规则，主要是因为Redis在每个时段的读写请求肯定是不均衡的，为了平衡性能与数据安全，我们可以自定义时间策略来满足我们的业务需求。

当然如果我们不需要开启rdb操作，只需要将上述三条save命令都注释掉，并加上save ""配置即可禁用rdb操作

rdb原理

在Redis中RDB持久化的触发分为两种：手动触发与Redis定时触发。

1、针对手动触发，大致有如下两种命令：

2、针对自动触发，主要是根据配置文件中的时间策略来自动执行，Redis也是调用bgsave命令来执行自动触发操作的，当从节点全量复制时，主节点会发送rdb文件给从节点完成复制操作，主节点会触发 bgsave

这里介绍下bgsave的命令过程：

当子进程完成rdb操作后，会用新的rdb文件替换之前的文件，这里需要注意的是上图 fork 操作会阻塞，导致Redis读写性能下降。我们可以控制单个Redis实例的最大内存，来尽可能降低Redis在fork时的时间消耗。以及上面提到的自动触发的频率减少fork次数，或者使用手动触发，根据自己的机制来完成持久化。

aof持久化会将被执行的写和删除命令写到aof文件的末尾，以此来记录数据发生的变化。这样，我们在恢复数据的时候，只需要从头到尾的执行一下aof文件即可恢复数据，注意读命令并不会写入到aof文件中

所产生的文件格式默认为：appendonly.aof

aof的持久化配置

其中比较重要的配置就是同步方式的配置，主要有如下三种方式：

aof-load-truncated yes 如果该配置启用，在加载时发现aof尾部不正确时，会向客户端写入一个log，但是会继续执行，如果设置为 no ，发现错误就会停止，必须修复后才能重新加载。

aof原理

aof的整个工作流程大致分为两步，一是命令的写入，二是对aof文件的重写，关于文件的追加可以分为写入命令->追加到aof_buf->同步到aof磁盘，如果实时同步到磁盘会带来非常高的磁盘IO，影响整体性能，所以需要先写到缓存文件。

aof文件的重写主要是为了减少文件的大小，可以手动或者自动触发，手动触发可以使用bgrewriteaof命令，自动触发主要是依照配置文件的规则来触发，Redis会记录上次重写时aof的文件大小，默认配置是当aof文件大小是上次重写后的一倍并且文件大小大于64m便会触发重写。

下面来看看重写的一个流程图：

对于上图有四个关键点补充一下：

数据恢复

那我们如何从持久化数据中进行数据恢复呢？一般来说只需要重启即可，Redis会自动进行数据恢复操作，其数据恢复操作如下图所示：

Redis允许用户设置最大使用内存大小server.maxmemory，换句话说，当Redis内存使用达到某一设置量时，便会执行数据淘汰策略，Redis支持以下六种策略：

Redis确定驱逐某个键值对后，会删除该数据，同时发送数据变更消息到本地（aof持久化）和从机（主从连接）

当然这里需要注意，针对lru和ttl，挑选的数据并不是绝对的最近最少使用或者说过期时间中最快过期的那些数据，Redis只是保证在随机挑选中的数据集满足上述条件。

Redis支持master-slave（主从）模式，一个redis-server可以设置为另一个redis-server的主机，即简单的主从关系，从机定期从主机拿数据。当然前者中的从机又可以作为另一个redis-server的主机，循环往复，最终整个master-slave的分布就变成了树状结构，如此形成redis server集群，不管是主机还是从机都是一个redis-server，都可以提供独立的服务。

当然主从复制可尽量减少使用如下图的图状结构，使用单项链表结构更为稳定，即master