Redis基础

1. Redis 简介

在这个部分，我们将学习以下3个部分的内容，分别是：

◆ Redis 简介（NoSQL概念、Redis概念）

◆ Redis 的下载与安装

◆ Redis 的基本操作

1.1 NoSQL概念

1.1.1 问题现象

在讲解NoSQL的概念之前呢，我们先来看一个现象：

（1）问题现象

每年到了过年期间，大家都会自觉自发的组织一场活动，叫做春运！以前我们买票都是到火车站排队，后来呢有了12306，有了他以后就更方便了，我们可以在网上买票，但是带来的问题，大家也很清楚，春节期间买票进不去，进去了刷不着票。什么原因呢，人太多了！

除了这种做铁路的，它系统做的不专业以外，还有马爸爸做的淘宝，它面临一样的问题。淘宝也崩，也是用户量太大！作为我们整个电商界的东哥来说，他第一次做图书促销的时候，也遇到了服务器崩掉的这样一个现象，原因同样是因为用户量太大！

（2）现象特征

再来看这几个现象，有两个非常相似的特征：

第一，用户比较多，海量用户

第二，高并发

这两个现象出现以后，对应的就会造成我们的服务器瘫痪。核心本质是什么呢？其实并不是我们的应用服务器，而是我们的关系型数据库。关系型数据库才是最终的罪魁祸首！

（3）造成原因

什么样的原因导致的整个系统崩掉的呢：

1.性能瓶颈：磁盘IO性能低下

关系型数据库菜存取数据的时候和读取数据的时候他要走磁盘IO。磁盘这个性能本身是比较低的。

2.扩展瓶颈：数据关系复杂，扩展性差，不便于大规模集群

我们说关系型数据库，它里面表与表之间的关系非常复杂，不知道大家能不能想象一点，就是一张表，通过它的外键关联了七八张表，这七八张表又通过她的外件，每张又关联了四五张表。你想想，查询一下，你要想拿到数据，你就要从A到B、B到C、C到D的一直这么关联下去，最终非常影响查询的效率。同时，你想扩展下，也很难!

（4）解决思路

面对这样的现象，我们要想解决怎么版呢。两方面：

一，降低磁盘IO次数，越低越好。

二，去除数据间关系，越简单越好。

降低磁盘IO次数，越低越好，怎么搞？我不用你磁盘不就行了吗？于是，内存存储的思想就提出来了，我数据不放到你磁盘里边，放内存里，这样是不是效率就高了。

第二，你的数据关系很复杂，那怎么办呢？干脆简单点，我断开你的关系，我不存关系了，我只存数据，这样不就没这事了吗？

把这两个特征一合并一起，就出来了一个新的概念：NoSQL

1.1.2 NoSQL的概念

（1）概念

NoSQL：即 Not-Only SQL（ 泛指非关系型的数据库），作为关系型数据库的补充。 作用：应对基于海量用户和海量数据前提下的数据处理问题。

他说这句话说的非常客气，什么意思呢？就是我们数据存储要用SQL，但是呢可以不仅仅用SQL，还可以用别的东西，那别的东西叫什么呢？于是他定义了一句话叫做NoSQL。这个意思就是说我们存储数据，可以不光使用SQL，我们还可以使用非SQL的这种存储方案，这就是所谓的NoSQL。

（2）特征

可扩容，可伸缩。SQL数据关系过于复杂，你扩容一下难度很高，那我们Nosql 这种的，不存关系，所以它的扩容就简单一些。

大数据量下高性能。包数据非常多的时候，它的性能高，因为你不走磁盘IO，你走的是内存，性能肯定要比磁盘IO的性能快一些。

灵活的数据模型、高可用。他设计了自己的一些数据存储格式，这样能保证效率上来说是比较高的，最后一个高可用，我们等到集群内部分再去它！

（3）常见 Nosql 数据库

目前市面上常见的Nosql产品：Redis、memcache、HBase、MongoDB

（4）应用场景-电商为例

我们以电商为例，来看一看他在这里边起到的作用。

第一类，在电商中我们的基础数据一定要存储起来，比如说商品名称，价格，生产厂商，这些都属于基础数据，这些数据放在MySQL数据库。

第二类，我们商品的附加信息，比如说，你买了一个商品评价了一下，这个评价它不属于商品本身。就像你买一个苹果，“这个苹果很好吃”就是评论，但是你能说很好吃是这个商品的属性嘛？不能这么说，那只是一个人对他的评论而已。这一类数据呢，我们放在另外一个地方，我们放到MongoDB。它也可以用来加快我们的访问，他属于NoSQL的一种。

第三，图片内的信息。注意这种信息相对来说比较固定，他有专用的存储区，我们一般用文件系统来存储。至于是不是分布式，要看你的系统的一个整个 瓶颈 了？如果说你发现你需要做分布式，那就做，不需要的话，一台主机就搞定了。

第四，搜索关键字。为了加快搜索，我们会用到一些技术，有些人可能了解过，像分ES、Lucene、solr都属于搜索技术。那说的这么热闹，我们的电商解决方案中还没出现我们的redis啊！注意第五类信息。

第五，热点信息。访问频度比较高的信息，这种东西的第二特征就是它具有波段性。换句话说他不是稳定的，它具有一个时效性的。那么这类信息放哪儿了，放到我们的redis这个解决方案中来进行存储。

具体的我们从我们的整个数据存储结构的设计上来看一下。

我们的基础数据都存MySQL,在它的基础之上，我们把它连在一块儿，同时对外提供服务。向上走，有一些信息加载完以后,要放到我们的MongoDB中。还有一类信息，我们放到我们专用的文件系统中（比如图片），就放到我们的这个搜索专用的，如Lucene、solr及集群里边，或者用ES的这种技术里边。那么剩下来的热点信息，放到我们的redis里面。

1.2 Redis概念

1.2.1 redis概念

概念：Redis (REmote DIctionary Server) 是用 C 语言开发的一个开源的高性能键值对（key-value）数据库。

特征：

（1）数据间没有必然的关联关系；

（2）内部采用单线程机制进行工作；

（3）高性能。官方提供测试数据，50个并发执行100000 个请求,读的速度是110000 次/s,写的速度是81000次/s。

（4）多数据类型支持

字符串类型，string list

列表类型，hash set

散列类型，zset/sorted_set

集合类型

有序集合类型

（5）支持持久化，可以进行数据灾难恢复

1.2.2 redis的应用场景

（1）为热点数据加速查询（主要场景）。如热点商品、热点新闻、热点资讯、推广类等高访问量信息等。

（2）即时信息查询。如各位排行榜、各类网站访问统计、公交到站信息、在线人数信息（聊天室、网站）、设备信号等。

（3）时效性信息控制。如验证码控制、投票控制等。

（4）分布式数据共享。如分布式集群架构中的 session 分离
消息队列.

1.3 Redis 的下载与安装

后期所有资料分4中不同色块显示，详情如下：

1.3.1 Redis 的下载与安装

本课程所示，均基于Center OS7安装Redis。

（1)下载Redis

下载安装包：

wget http://download.redis.io/releases/redis-5.0.0.tar.gz

解压安装包：

tar –xvf redis-5.0.0.tar.gz

编译（在解压的目录中执行）：

make

安装（在解压的目录中执行）：

make install

（2）安装 Redis

redis-server，服务器启动命令 客户端启动命令

redis-cli，redis核心配置文件

redis.conf，RDB文件检查工具（快照持久化文件）

redis-check-dump，AOF文件修复工具

redis-check-aof

1.4 Redis服务器启动

1.4.1 Redis服务器启动

启动服务器——参数启动

redis-server [--port port]

范例

redis-server --port 6379

启动服务器——配置文件启动

redis-server config_file_name

范例

redis-server redis.conf

1.4.2 Redis客户端启动

启动客户端

redis-cli [-h host] [-p port]

范 例

redis-cli –h 61.129.65.248 –p 6384

注意：服务器启动指定端口使用的是—port，客户端启动指定端口使用的是-p。-的数量不同。

1.4.3 Redis基础环境设置约定

创建配置文件存储目录

mkdir conf

创建服务器文件存储目录（包含日志、数据、临时配置文件等）

mkdir data

创建快速访问链接

ln -s redis-5.0.0 redis

1.5 配置文件启动与常用配置

1.5.1 服务器端设定

设置服务器以守护进程的方式运行，开启后服务器控制台中将打印服务器运行信息（同日志内容相同）

daemonize yes|no

绑定主机地址

bind ip

设置服务器端口

port port

设置服务器文件保存地址

dir path

1.5.2 客户端配置

服务器允许客户端连接最大数量，默认0，表示无限制。当客户端连接到达上限后，Redis会拒绝新的连接

maxclients count

客户端闲置等待最大时长，达到最大值后关闭对应连接。如需关闭该功能，设置为 0

timeout seconds

1.5.3 日志配置

设置服务器以指定日志记录级别

loglevel debug|verbose|notice|warning

日志记录文件名

logfile filename

注意：日志级别开发期设置为verbose即可，生产环境中配置为notice，简化日志输出量，降低写日志IO的频度。

1.6 Redis基本操作

1.6.1 命令行模式工具使用思考

功能性命令

帮助信息查阅

退出指令

清除屏幕信息

1.6.2 信息读写

设置 key，value 数据

set key value

范例

set name itheima

根据 key 查询对应的 value，如果不存在，返回空（nil）

get key

范例

get name

1.6.3 帮助信息

获取命令帮助文档

help [command]

范例

help set

获取组中所有命令信息名称

help [@group-name]

范例

help @string

1.6.4 退出命令行客户端模式

退出客户端

quit
exit

快捷键

Ctrl+C

1.6.4 redis入门总结

到这里，Redis 入门的相关知识，我们就全部学习完了，再来回顾一下，这个部分我们主要讲解了哪些内容呢？

首先，我们对Redis进行了一个简单介绍，包括NoSQL的概念、Redis的概念等。

然后，我们介绍了Redis 的下载与安装。包括下载与安装、服务器与客户端启动、以及相关配置文件（3类）。

最后，我们介绍了Redis 的基本操作。包括数据读写、退出与帮助信息获取。

2. 数据类型

在这个部分，我们将学习一共要学习三大块内容，首先需要了解一下数据类型，接下来将针对着我们要学习的数据类型进行逐一的讲解，如string、hash、list、set等，最后我们通过一个案例来总结前面的数据类型的使用场景。

2.1 数据存储类型介绍

2.1.1 业务数据的特殊性

在讲解数据类型之前，我们得先思考一个问题，数据类型既然是用来描述数据的存储格式的，如果你不知道哪些数据未来会进入到我们来的redis中，那么对应的数据类型的选择，你就会出现问题，我们一块来看一下：

（1）原始业务功能设计

秒杀。他这个里边数据变化速度特别的快，访问量也特别的高，用户大量涌入以后都会针对着一部分数据进行操作，这一类要记住。

618活动。对于我们京东的618活动、以及天猫的双11活动，相信大家不用说都知道这些数据一定要进去，因为他们的访问频度实在太高了。

排队购票。我们12306的票务信息。这些信息在原始设计的时候，他们就注定了要进redis。

（2）运营平台监控到的突发高频访问数据

此类平台临时监控到的这些数据，比如说现在出来的一个八卦的信息，这个新闻一旦出现以后呢，顺速的被围观了，那么这个时候，这个数据就会变得访量特别高，那么这类信息也要进入进去。

（3）高频、复杂的统计数据

在线人数。比如说直播现在很火，直播里边有很多数据，例如在线人数。进一个人出一个人，这个数据就要跳动，那么这个访问速度非常的快，而且访量很高，并且它里边有一个复杂的数据统计，在这里这种信息也要进入到我们的redis中。

投票排行榜。投票投票类的信息他的变化速度也比较快，为了追求一个更快的一个即时投票的名次变化，这种数据最好也放到redis中。

2.1.2 Redis 数据类型(5种常用)

基于以上数据特征我们进行分析，最终得出来我们的Redis中要设计5种 数据类型：

string、hash、list、set、sorted_set/zset（应用性较低）

2.2 string数据类型

在学习第一个数据类型之前，先给大家介绍一下，在随后这部分内容的学习过程中，我们每一种数据类型都分成三块来讲：首先是讲下它的基本操作，接下来讲一些它的扩展操作，最后我们会去做一个小的案例分析。

2.2.1Redis 数据存储格式

在学习string这个数据形式之前，我们先要明白string到底是修饰什么的。我们知道redis 自身是一个 Map，其中所有的数据都是采用 key : value 的形式存储。

对于这种结构来说，我们用来存储数据一定是一个值前面对应一个名称。我们通过名称来访问后面的值。按照这种形势，我们可以对出来我们的存储格式。前面这一部分我们称为key。后面的一部分称为value，而我们的数据类型，他一定是修饰value的。

数据类型指的是存储的数据的类型，也就是 value 部分的类型，key 部分永远都是字符串。

2.2.2 string 类型

（1）存储的数据：单个数据，最简单的数据存储类型，也是最常用的数据存储类型。

string，他就是存一个字符串儿，注意是value那一部分是一个字符串，它是redis中最基本、最简单的存储数据的格式。

（2）存储数据的格式：一个存储空间保存一个数据

每一个空间中只能保存一个字符串信息，这个信息里边如果是存的纯数字，他也能当数字使用，我们来看一下，这是我们的数据的存储空间。

（3）存储内容：通常使用字符串，如果字符串以整数的形式展示，可以作为数字操作使用.

一个key对一个value，而这个itheima就是我们所说的string类型，当然它也可以是一个纯数字的格式。

2.2.3 string 类型数据的基本操作

（1）基础指令

添加/修改数据添加/修改数据

set key value

获取数据

get key

删除数据

del key

判定性添加数据

setnx key value

添加/修改多个数据

mset key1 value1 key2 value2 …

获取多个数据

mget key1 key2 …

获取数据字符个数（字符串长度）

strlen key

追加信息到原始信息后部（如果原始信息存在就追加，否则新建）

append key value

（2）单数据操作与多数据操作的选择之惑

即set 与mset的关系。这对于这两个操作来说，没有什么你应该选哪个，而是他们自己的特征是什么，你要根据这个特征去比对你的业务，看看究竟适用于哪个。

假如说这是我们现在的服务器，他要向redis要数据的话，它会发出一条指令。那么当这条指令发过来的时候，比如说是这个set指令过来，那么它会把这个结果返回给你，这个时候我们要思考这里边一共经过了多长时间。

首先，发送set指令要时间，这是网络的一个时间，接下来redis要去运行这个指令要消耗时间，最终把这个结果返回给你又有一个时间，这个时间又是一个网络的时间，那我们可以理解为：一个指令发送的过程中需要消耗这样的时间.

但是如果说现在不是一条指令了，你要发3个set的话，还要多长时间呢？对应的发送时间要乘3了，因为这是三个单条指令,而运行的操作时间呢，它也要乘3了，但最终返回的也要发3次，所以这边也要乘3。

于是我们可以得到一个结论：单指令发3条它需要的时间，假定他们两个一样，是6个网络时间加3个处理时间，如果我们把它合成一个mset呢，我们想一想。

假如说用多指令发3个指令的话，其实只需要发一次就行了。这样我们可以得到一个结论，多指令发3个指令的话，其实它是两个网络时间加上3个redis的操作时间，为什么这写一个小加号呢，就是因为毕竟发的信息量变大了，所以网络时间有可能会变长。

那么通过这张图，你就可以得到一个结论，我们单指令和多指令他们的差别就在于你发送的次数是多还是少。当你影响的数据比较少的时候，你可以用单指令，也可以用多指令。但是一旦这个量大了，你就要选择多指令了，他的效率会高一些。

2.3 string 类型数据的扩展操作

2.3.1 string 类型数据的扩展操作

下面我们来看一string的扩展操作，分成两大块：一块是对数字进行操作的，第二块是对我们的key的时间进行操作的。

设置数值数据增加指定范围的值

incr key
incrby key increment
incrbyfloat key increment

设置数值数据减少指定范围的值

decr key
decrby key increment

设置数据具有指定的生命周期

setex key seconds value
psetex key milliseconds value

2.3.2 string 类型数据操作的注意事项

(1)数据操作不成功的反馈与数据正常操作之间的差异

表示运行结果是否成功

(integer) 0 → false 失败

(integer) 1 → true 成功

表示运行结果值

(integer) 3 → 3 3个

(integer) 1 → 1 1个

(2)数据未获取到时，对应的数据为（nil），等同于null

(3)数据最大存储量：512MB

(4)string在redis内部存储默认就是一个字符串，当遇到增减类操作incr，decr时会转成数值型进行计算

(5)按数值进行操作的数据，如果原始数据不能转成数值，或超越了redis 数值上限范围，将报错
9223372036854775807（java中Long型数据最大值，Long.MAX_VALUE）

(6)redis所有的操作都是原子性的，采用单线程处理所有业务，命令是一个一个执行的，因此无需考虑并发带来的数据影响.

2.4string应用场景与key命名约定

2.4.1 应用场景

它的应用场景在于：主页高频访问信息显示控制，例如新浪微博大V主页显示粉丝数与微博数量。

我们来思考一下：这些信息是不是你进入大V的页面儿以后就要读取这写信息的啊，那这种信息一定要存储到我们的redis中，因为他的访问量太高了！那这种数据应该怎么存呢？我们来一块儿看一下方案！

2.4.2 解决方案

（1）在redis中为大V用户设定用户信息，以用户主键和属性值作为key，后台设定定时刷新策略即可。

eg:	user:id:3506728370:fans		→	12210947
eg:	user:id:3506728370:notes	→	6164
eg:	user:id:3506728370:focuses	→	83

（2）也可以使用json格式保存数据

eg:	user:id:3506728370    →	{“fans”：12210947，“notes”：6164，“ focuses ”：83 }

（3） key 的设置约定

数据库中的热点数据key命名惯例

表名 主键名 主键值 字段名
eg1： order id 29437595 name
eg2： equip id 390472345 type
eg3： news id 202004150 title

2.5 hash的基本操作

下面我们来学习第二个数据类型hash。

2.5.1 数据存储的困惑

对象类数据的存储如果具有较频繁的更新需求操作会显得笨重！

在正式学习之前，我们先来看一个关于数据存储的困惑：

比如说前面我们用以上形式存了数据，如果我们用单条去存的话，它存的条数会很多。但如果我们用json格式，它存一条数据就够了。问题来了，假如说现在粉丝数量发生变化了，你要把整个值都改了。但是用单条存的话就不存在这个问题，你只需要改其中一个就行了。这个时候我们就想，有没有一种新的存储结构，能帮我们解决这个问题呢。

我们一块儿来分析一下：

如上图所示：单条的话是对应的数据在后面放着。仔细观察：我们看左边是不是长得都一模一样啊，都是对应的表名、ID等的一系列的东西。我们可以将右边红框中的这个区域给他封起来。

那如果要是这样的形式的话，如下图，我们把它一合并，并把右边的东西给他变成这个格式，这不就行了吗？

这个图其实大家并不陌生，第一，你前面学过一个东西叫hashmap不就这格式吗？第二，redis自身不也是这格式吗？那是什么意思呢？注意，这就是我们要讲的第二种格式，hash。

在右边对应的值，我们就存具体的值，那左边儿这就是我们的key。问题来了，那中间的这一块叫什么呢？这个东西我们给他起个名儿，叫做field字段。那么右边儿整体这块儿空间我们就称为hash，也就是说hash是存了一个key value的存储空间。

2.5.2 hash 类型

新的存储需求：对一系列存储的数据进行编组，方便管理，典型应用存储对象信息

需要的存储结构：一个存储空间保存多个键值对数据

hash类型：底层使用哈希表结构实现数据存储

如上图所示，这种结构叫做hash，左边一个key，对右边一个存储空间。这里要明确一点，右边这块儿存储空间叫hash，也就是说hash是指的一个数据类型，他指的不是一个数据，是这里边的一堆数据，那么它底层呢，是用hash表的结构来实现的。

值得注意的是：

如果field数量较少，存储结构优化为类数组结构

如果field数量较多，存储结构使用HashMap结构

2.5.3 hash 类型数据的基本操作

添加/修改数据

hset key field value

获取数据

hget key field
hgetall key

删除数据

hdel key field1 [field2]

设置field的值，如果该field存在则不做任何操作

hsetnx key field value

添加/修改多个数据

hmset key field1 value1 field2 value2 …

获取多个数据

hmget key field1 field2 …

获取哈希表中字段的数量

hlen key

获取哈希表中是否存在指定的字段

hexists key field

2.6 hash的拓展操作

在看完hash的基本操作后，我们再来看他的拓展操作，他的拓展操作相对比较简单：

2.6.1 hash 类型数据扩展操作

获取哈希表中所有的字段名或字段值

hkeys key
hvals key

设置指定字段的数值数据增加指定范围的值

hincrby key field increment
hincrbyfloat key field increment

2.6.2 hash类型数据操作的注意事项

(1)hash类型中value只能存储字符串，不允许存储其他数据类型，不存在嵌套现象。如果数据未获取到，对应的值为（nil）。

(2）每个 hash 可以存储 232 - 1 个键值对
hash类型十分贴近对象的数据存储形式，并且可以灵活添加删除对象属性。但hash设计初衷不是为了存储大量对象而设计 的，切记不可滥用，更不可以将hash作为对象列表使用。

(3)hgetall 操作可以获取全部属性，如果内部field过多，遍历整体数据效率就很会低，有可能成为数据访问瓶颈。

2.7 hash应用场景

2.7.1 应用场景

双11活动日，销售手机充值卡的商家对移动、联通、电信的30元、50元、100元商品推出抢购活动，每种商品抢购上限1000 张。

也就是商家有了，商品有了，数量有了。最终我们的用户买东西就是在改变这个数量。那你说这个结构应该怎么存呢？对应的商家的ID作为key，然后这些充值卡的ID作为field，最后这些数量作为value。而我们所谓的操作是其实就是increa这个操作，只不过你传负值就行了。看一看对应的解决方案：

2.7.2 解决方案

以商家id作为key

将参与抢购的商品id作为field

将参与抢购的商品数量作为对应的value

抢购时使用降值的方式控制产品数量

注意：实际业务中还有超卖等实际问题，这里不做讨论

2.8 list基本操作

前面我们存数据的时候呢，单个数据也能存，多个数据也能存，但是这里面有一个问题，我们存多个数据用hash的时候它是没有顺序的。我们平时操作，实际上数据很多情况下都是有顺序的，那有没有一种能够用来存储带有顺序的这种数据模型呢，list就专门来干这事儿。

2.8.1 list 类型

数据存储需求：存储多个数据，并对数据进入存储空间的顺序进行区分

需要的存储结构：一个存储空间保存多个数据，且通过数据可以体现进入顺序

list类型：保存多个数据，底层使用双向链表存储结构实现

先来通过一张图，回忆一下顺序表、链表、双向链表。

list对应的存储结构是什么呢？里边存的这个东西是个列表，他有一个对应的名称。就是key存一个list的这样结构。对应的基本操作，你其实是可以想到的。

来看一下，因为它是双向的，所以他左边右边都能操作，它对应的操作结构两边都能进数据。这就是链表的一个存储结构。往外拿数据的时候怎么拿呢？通常是从一端拿，当然另一端也能拿。如果两端都能拿的话，这就是个双端队列，两边儿都能操作。如果只能从一端进一端出，这个模型咱们前面了解过，叫做栈。

2.8.2 list 类型数据基本操作

最后看一下他的基本操作

添加/修改数据

lpush key value1 [value2] ……
rpush key value1 [value2] ……

获取数据

lrange key start stop
lindex key index
llen key

获取并移除数据

lpop key
rpop key

2.9 list扩展操作

2.9.1 list 类型数据扩展操作

移除指定数据

lrem key count value

规定时间内获取并移除数据

blpop key1 [key2] timeout
brpop key1 [key2] timeout
brpoplpush source destination timeout

2.9.2 list 类型数据操作注意事项

（1）list中保存的数据都是string类型的，数据总容量是有限的，最多232 - 1 个元素(4294967295)。

（2）list具有索引的概念，但是操作数据时通常以队列的形式进行入队出队操作，或以栈的形式进行入栈出栈操作

（3）获取全部数据操作结束索引设置为-1

（4）list可以对数据进行分页操作，通常第一页的信息来自于list，第2页及更多的信息通过数据库的形式加载

2.10 list 应用场景

2.10.1 应用场景

企业运营过程中，系统将产生出大量的运营数据，如何保障多台服务器操作日志的统一顺序输出？

假如现在你有多台服务器，每一台服务器都会产生它的日志，假设你是一个运维人员，你想看它的操作日志，你怎么看呢？打开A机器的日志看一看，打开B机器的日志再看一看吗？这样的话你会可能会疯掉的！因为左边看的有可能它的时间是11:01，右边11:02，然后再看左边11:03，它们本身是连续的，但是你在看的时候就分成四个文件了，这个时候你看起来就会很麻烦。能不能把他们合并呢？答案是可以的！怎么做呢？建立起redis服务器。当他们需要记日志的时候，记在哪儿,全部发给redis。等到你想看的时候，通过服务器访问redis获取日志。然后得到以后，就会得到一个完整的日志信息。那么这里面就可以获取到完整的日志了，依靠什么来实现呢？就依靠我们的list的模型的顺序来实现。进来一组数据就往里加，谁先进来谁先加进去，它是有一定的顺序的。

2.10.2 解决方案

依赖list的数据具有顺序的特征对信息进行管理

使用队列模型解决多路信息汇总合并的问题

使用栈模型解决最新消息的问题

2.11 set 基本操作

2.11.1 set类型

新的存储需求：存储大量的数据，在查询方面提供更高的效率

需要的存储结构：能够保存大量的数据，高效的内部存储机制，便于查询

set类型：与hash存储结构完全相同，仅存储键，不存储值（nil），并且值是不允许重复的

通过这个名称，大家也基本上能够认识到和我们Java中的set完全一样。我们现在要存储大量的数据，并且要求提高它的查询效率。用list这种链表形式，它的查询效率是不高的，那怎么办呢？这时候我们就想，有没有高效的存储机制。其实前面咱讲Java的时候说过hash表的结构就非常的好，但是这里边我们已经有hash了，他做了这么一个设定，干嘛呢，他把hash的存储空间给改一下，右边你原来存数据改掉,全部存空，那你说数据放哪儿了？放到原来的filed的位置，也就在这里边存真正的值，那么这个模型就是我们的set 模型。

set类型：与hash存储结构完全相同，仅存储键，不存储值（nil），并且值是不允许重复的。

看一下它的整个结构：

2.11.2 set类型数据的基本操作

添加数据

sadd key member1 [member2]

获取全部数据

smembers key

删除数据

srem key member1 [member2]

获取集合数据总量

scard key

判断集合中是否包含指定数据

sismember key member

随机获取集合中指定数量的数据

srandmember key [count]

随机获取集中的某个数据并将该数据移除集合

spop key [count]

2.12 set 类型数据的扩展操作

2.12.1 set 类型数据的扩展操作

求两个集合的交、并、差集

sinter key1 [key2 …]  
sunion key1 [key2 …]  
sdiff key1 [key2 …]

求两个集合的交、并、差集并存储到指定集合中

sinterstore destination key1 [key2 …]  
sunionstore destination key1 [key2 …]  
sdiffstore destination key1 [key2 …]

将指定数据从原始集合中移动到目标集合中

smove source destination member

通过下面一张图回忆一下交、并、差

2.12.2 set 类型数据操作的注意事项

set 类型不允许数据重复，如果添加的数据在 set 中已经存在，将只保留一份。

set 虽然与hash的存储结构相同，但是无法启用hash中存储值的空间。

2.13 set应用场景

2.13.1 set应用场景

（1）黑名单

资讯类信息类网站追求高访问量，但是由于其信息的价值，往往容易被不法分子利用，通过爬虫技术， 快速获取信息，个别特种行业网站信息通过爬虫获取分析后，可以转换成商业机密进行出售。例如第三方火 车票、机票、酒店刷票代购软件，电商刷评论、刷好评。

同时爬虫带来的伪流量也会给经营者带来错觉，产生错误的决策，有效避免网站被爬虫反复爬取成为每个网站都要考虑的基本问题。在基于技术层面区分出爬虫用户后，需要将此类用户进行有效的屏蔽，这就是黑名单的典型应用。

ps:不是说爬虫一定做摧毁性的工作，有些小型网站需要爬虫为其带来一些流量。

（2）白名单

对于安全性更高的应用访问，仅仅靠黑名单是不能解决安全问题的，此时需要设定可访问的用户群体， 依赖白名单做更为苛刻的访问验证。

2.13.2 解决方案

基于经营战略设定问题用户发现、鉴别规则

周期性更新满足规则的用户黑名单，加入set集合

用户行为信息达到后与黑名单进行比对，确认行为去向

黑名单过滤IP地址：应用于开放游客访问权限的信息源

黑名单过滤设备信息：应用于限定访问设备的信息源

黑名单过滤用户：应用于基于访问权限的信息源

2.14 实践案例

2.14.1业务场景

使用微信的过程中，当微信接收消息后，会默认将最近接收的消息置顶，当多个好友及关注的订阅号同时发 送消息时，该排序会不停的进行交替。同时还可以将重要的会话设置为置顶。一旦用户离线后，再次打开微信时，消息该按照什么样的顺序显示。

我们分析一下：

100这台手机代表你。而200、300、400这三台代表你好友的手机。在这里有一些东西需要交代一下，因为我们每个人的都会对自己的微信中的一些比较重要的人设置会话置顶，将他的那条对话放在最上面。我们假定这个人有两个会话置顶的好友，分别是400和500，而这里边就包含400.

下面呢，我们就来发这个消息，第一个发消息的是300，他发了个消息给100。发完以后，这个东西应该怎么存储呢？在这里面一定要分开，记录置顶的这些人的会话，对应的会话显示顺序和非置顶的一定要分两。

这里面我们创建两个模型，一个是普通的，一个是置顶的，而上面的这个置顶的用户呢，我们用set来存储，因为不重复。而下面这些因为有顺序，很容易想到用list去存储,不然你怎么表达顺序呢？

那当300发给消息给100以后，这个时候我们先判定你在置顶人群中吗？不在,那好，300的消息对应的顺序就应该放在普通的列表里边。而在这里边，我们把300加进去。第一个数据也就是现在300。

接下来400，发了个消息。判断一下，他是需要置顶的，所以400将进入list的置顶里边放着。当前还没有特殊的地方。

再来200发消息了，和刚才的判定方法一样，先看在不在置顶里，不在的话进普通，然后在普通里边把200加入就行了，OK，到这里目前还没有顺序变化。

接下来200又发消息过来，同一个人给你连发了两条，那这个时候200的消息到达以后，先判断是否在置顶范围，不在，接下来他要放在list普通中，这里你要注意一点，因为这里边已经有200，所以进来以后先干一件事儿，把200杀掉，没有200，然后再把200加进来，那你想一下，现在这个位置顺序是什么呢？就是新的都在右边，对不对？

还记得我们说list模型，如果是一个双端队列，它是可以两头进两头出。当然我们双端从一头进一头出，这就是栈模型，现在咱们运用的就是list模型中的栈模型。

现在300发消息，先判定他在不在，不在，用普通的队列，接下来按照刚才的操作，不管你里边原来有没有300，我先把300杀掉，没了，200自然就填到300的位置了，他现在是list里面唯一一个，然后让300进来，注意是从右侧进来的，那么现在300就是最新的。

那么到这里呢，我们让100来读取消息。你觉得这个消息顺序应该是什么样的？首先置顶的400有一个，他跑在最上面，然后list普通如果出来的话，300是最新的消息，而200在他后面的。用这种形式，我们就可以做出来他的消息顺序来。

2.14.2 解决方案

看一下最终的解决方案：

依赖list的数据具有顺序的特征对消息进行管理，将list结构作为栈使用

置顶与普通会话分别创建独立的list分别管理

当某个list中接收到用户消息后，将消息发送方的id从list的一侧加入list（此处设定左侧）

多个相同id发出的消息反复入栈会出现问题，在入栈之前无论是否具有当前id对应的消息，先删除对应id

推送消息时先推送置顶会话list，再推送普通会话list，推送完成的list清除所有数据
消息的数量，也就是微信用户对话数量采用计数器的思想另行记录，伴随list操作同步更新

2.14.3 数据类型总结

总结一下，在整个数据类型的部分，我们主要介绍了哪些内容：

首先我们了解了一下数据类型，接下来针对着我们要学习的数据类型，进行逐一讲解了string、hash、list、set等，最后通过一个案例总结了一下前面的数据类型的使用场景。

3. 常用指令

在这部分中呢，我们家学习两个知识，第一个是key的常用指令，第二个是数据库的常用指令。和前面我们学数据类型做一下区分，前面你学的那些指令呢，都是针对某一个数据类型操作的，现在学的都是对所有的操作的，来看一下，我们在学习Key的操作的时候，我们先想一下的操作我们应该学哪些东西:

3.1 key 操作分析

3.1.1 key应该设计哪些操作？

key是一个字符串，通过key获取redis中保存的数据

对于key自身状态的相关操作，例如：删除，判定存在，获取类型等

对于key有效性控制相关操作，例如：有效期设定，判定是否有效，有效状态的切换等

对于key快速查询操作，例如：按指定策略查询key

3.1.2 key 基本操作

删除指定key

del key

获取key是否存在

exists key

获取key的类型

type key

3.1.3 拓展操作

排序

sort

改名

rename key newkey
renamenx key newkey

3.1.3 key 扩展操作（时效性控制）

为指定key设置有效期

expire key seconds
pexpire key milliseconds
expireat key timestamp
pexpireat key milliseconds-timestamp

获取key的有效时间

ttl key
pttl key

切换key从时效性转换为永久性

persist key

3.1.4 key 扩展操作（查询模式）

查询key

keys pattern

查询模式规则

*匹配任意数量的任意符号 ? 配合一个任意符号 [] 匹配一个指定符号

keys *  keys    查询所有
it*  keys       查询所有以it开头
*heima          查询所有以heima结尾
keys ??heima    查询所有前面两个字符任意，后面以heima结尾 查询所有以
keys user:?     user:开头，最后一个字符任意
keys u[st]er:1  查询所有以u开头，以er:1结尾，中间包含一个字母，s或t

3.2 数据库指令

3.2.1 key 的重复问题

在这个地方我们来讲一下数据库的常用指令，在讲这个东西之前，我们先思考一个问题：

假如说你们十个人同时操作redis，会不会出现key名字命名冲突的问题。

一定会，为什么?因为你的key是由程序而定义的。你想写什么写什么，那在使用的过程中大家都在不停的加，早晚有一天他会冲突的。

redis在使用过程中，伴随着操作数据量的增加，会出现大量的数据以及对应的key。

那这个问题我们要不要解决？要！怎么解决呢？我们最好把数据进行一个分类，除了命名规范我们做统一以外，如果还能把它分开，这样是不是冲突的机率就会小一些了，这就是咱们下面要说的解决方案！

3.2.2 解决方案

redis为每个服务提供有16个数据库，编号从0到15

每个数据库之间的数据相互独立

在对应的数据库中划出一块区域，说他就是几，你就用几那块，同时，其他的这些都可以进行定义，一共是16个，这里边需要注意一点，他们这16个共用redis的内存。没有说谁大谁小，也就是说数字只是代表了一块儿区域，区域具体多大未知。这是数据库的一个分区的一个策略！

3.2.3 数据库的基本操作

切换数据库

select index

其他操作

ping

3.2.4 数据库扩展操作

数据移动

move key db

数据总量

dbsize

数据清除

flushdb  flushall

4. Jedis

在学习完redis后，我们现在就要用Java来连接redis了，也就是我们的这一章要学的Jedis了。在这个部分，我们主要讲解以下3个内容：

HelloWorld（Jedis版）

Jedis简易工具类开发

可视化客户端

4.1 Jedis简介

4.1.1 编程语言与redis

对于我们现在的数据来说，它是在我们的redis中，而最终我们是要做程序。那么程序就要和我们的redis进行连接。干什么事情呢？两件事：程序中有数据的时候，我们要把这些数据全部交给redis管理。同时，redis中的数据还能取出来，回到我们的应用程序中。那在这个过程中，在Java与redis之间打交道的这个东西就叫做Jedis.简单说，Jedis就是提供了Java与redis的连接服务的，里边有各种各样的API接口，你可以去调用它。

除了Jedis外，还有没有其他的这种连接服务呢？其实还有很多，了解一下：

Java语言连接redis服务 Jedis（SpringData、Redis 、 Lettuce）

其它语言：C 、C++ 、C# 、Erlang、Lua 、Objective-C 、Perl 、PHP 、Python 、Ruby 、Scala

4.1.2 准备工作

(1)jar包导入

下载地址：https://mvnrepository.com/artifact/redis.clients/jedis

基于maven

<dependency>
<groupId>redis.clients</groupId>
<artifactId>jedis</artifactId>
<version>2.9.0</version>
</dependency>

(2)客户端连接redis

连接redis

Jedis jedis = new Jedis("localhost", 6379);

操作redis

jedis.set("name", "itheima");  jedis.get("name");

关闭redis连接

jedis.close();

API文档

http://xetorthio.github.io/jedis/

4.1.3 代码实现

创建：com.itheima.JedisTest

public class JedisTest {

    public static void main(String[] args) {
        //1.获取连接对象
        Jedis jedis = new Jedis("192.168.40.130",6379);
        //2.执行操作
        jedis.set("age","39");
        String hello = jedis.get("hello");
        System.out.println(hello);
        jedis.lpush("list1","a","b","c","d");
        List<String> list1 = jedis.lrange("list1", 0, -1);
        for (String s:list1 ) {
            System.out.println(s);
        }
        jedis.sadd("set1","abc","abc","def","poi","cba");
        Long len = jedis.scard("set1");
        System.out.println(len);
        //3.关闭连接
        jedis.close();
    }
}

4.2 Jedis简易工具类开发

前面我们做的程序还是有点儿小问题，就是我们的Jedis对象的管理是我们自己创建的，真实企业开发中是不可能让你去new一个的，那接下来咱们就要做一个工具类，简单来说，就是做一个创建Jedis的这样的一个工具。

4.2.1 基于连接池获取连接

JedisPool：Jedis提供的连接池技术

poolConfig:连接池配置对象

host:redis服务地址

port:redis服务端口号

JedisPool的构造器如下：

public JedisPool(GenericObjectPoolConfig poolConfig, String host, int port) {
this(poolConfig, host, port, 2000, (String)null, 0, (String)null);
}

4.2.2 封装连接参数

创建jedis的配置文件：jedis.properties

jedis.host=192.168.40.130  
jedis.port=6379  
jedis.maxTotal=50  
jedis.maxIdle=10

4.2.3 加载配置信息

创建JedisUtils：com.itheima.util.JedisUtils，使用静态代码块初始化资源

public class JedisUtils {
    private static int maxTotal;
    private static int maxIdel;
    private static String host;
    private static int port;
    private static JedisPoolConfig jpc;
    private static JedisPool jp;

    static {
        ResourceBundle bundle = ResourceBundle.getBundle("redis");
        maxTotal = Integer.parseInt(bundle.getString("redis.maxTotal"));
        maxIdel = Integer.parseInt(bundle.getString("redis.maxIdel"));
        host = bundle.getString("redis.host");
        port = Integer.parseInt(bundle.getString("redis.port"));
        //Jedis连接池配置
        jpc = new JedisPoolConfig();
        jpc.setMaxTotal(maxTotal);
        jpc.setMaxIdle(maxIdel);
        jp = new JedisPool(jpc,host,port);
    }

}

4.2.4 获取连接

对外访问接口，提供jedis连接对象，连接从连接池获取，在JedisUtils中添加一个获取jedis的方法：getJedis

public static Jedis getJedis(){
	Jedis jedis = jedisPool.getResource();
	return jedis;
}

4.3 可视化客户端

4.3.1 Redis Desktop Manager

5. 持久化

下面呢，进入到持久化的学习.这部分内容理解的东西多，操作的东西少。在这个部分，我们将讲解四个东西：

持久化简介

RDB

AOF

RDB与AOF区别

5.1 持久化简介

5.1.1 场景-意外断电

不知道大家有没有遇见过，就是正工作的时候停电了，如果你用的是笔记本电脑还好，你有电池，但如果你用的是台式机呢，那恐怕就比较灾难了，假如你现在正在写一个比较重要的文档，如果你要使用的是word，这种办公自动化软件的话，他一旦遇到停电，其实你不用担心，因为它会给你生成一些其他的文件。

其实他们都在做一件事儿，帮你自动恢复，有了这个文件，你前面的东西就不再丢了。那什么是自动恢复呢？你要先了解他的整个过程。

我们说自动恢复，其实基于的一个前提就是他提前把你的数据给存起来了。你平常操作的所有信息都是在内存中的，而我们真正的信息是保存在硬盘中的，内存中的信息断电以后就消失了，硬盘中的信息断电以后还可以保留下来！

我们将文件由内存中保存到硬盘中的这个过程，我们叫做数据保存，也就叫做持久化。但是把它保存下来不是你的目的，最终你还要把它再读取出来，它加载到内存中这个过程，我们叫做数据恢复，这就是我们所说的word为什么断电以后还能够给你保留文件，因为它执行了一个自动备份的过程，也就是通过自动的形式，把你的数据存储起来，那么有了这种形式以后，我们的数据就可以由内存到硬盘上实现保存。

5.1.2 什么是持久化

(1)什么是持久化

利用永久性存储介质将数据进行保存，在特定的时间将保存的数据进行恢复的工作机制称为持久化 。

持久化用于防止数据的意外丢失，确保数据安全性。

(2)持久化过程保存什么？

我们知道一点，计算机中的数据全部都是二进制，如果现在我要你给我保存一组数据的话，你有什么样的方式呢，其实最简单的就是现在长什么样，我就记下来就行了，那么这种是记录纯粹的数据，也叫做快照存储，也就是它保存的是某一时刻的数据状态。

还有一种形式，它不记录你的数据，它记录你所有的操作过程，比如说大家用idea的时候，有没有遇到过写错了ctrl+z撤销，然后ctrl+y还能恢复，这个地方它也是在记录，但是记录的是你所有的操作过程，那我想问一下，操作过程，我都给你留下来了，你说数据还会丢吗？肯定不会丢，因为你所有的操作过程我都保存了。这种保存操作过程的存储，用专业术语来说可以说是日志，这是两种不同的保存数据的形式啊。

总结一下：

第一种：将当前数据状态进行保存，快照形式，存储数据结果，存储格式简单，关注点在数据。

第二种：将数据的操作过程进行保存，日志形式，存储操作过程，存储格式复杂，关注点在数据的操作过程。

5.2 RDB

5.2.1 save指令

手动执行一次保存操作

save

save指令相关配置

设置本地数据库文件名，默认值为 dump.rdb，通常设置为dump-端口号.rdb

dbfilename filename

设置存储.rdb文件的路径，通常设置成存储空间较大的目录中，目录名称data

dir path

设置存储至本地数据库时是否压缩数据，默认yes，设置为no，节省 CPU 运行时间，但存储文件变大

rdbcompression yes|no

设置读写文件过程是否进行RDB格式校验，默认yes，设置为no，节约读写10%时间消耗，单存在数据损坏的风险

rdbchecksum yes|no

save指令工作原理

需要注意一个问题，来看一下，现在有四个客户端各自要执行一个指令，把这些指令发送到redis服务器后，他们执行有一个先后顺序问题，假定就是按照1234的顺序放过去的话，那会是什么样的？

记得redis是个单线程的工作模式，它会创建一个任务队列，所有的命令都会进到这个队列里边，在这儿排队执行，执行完一个消失一个，当所有的命令都执行完了，OK，结果达到了。

但是如果现在我们执行的时候save指令保存的数据量很大会是什么现象呢？

他会非常耗时，以至于影响到它在执行的时候，后面的指令都要等，所以说这种模式是不友好的，这是save指令对应的一个问题，当cpu执行的时候会阻塞redis服务器，直到他执行完毕，所以说我们不建议大家在线上环境用save指令。

5.2.2 bgsave指令

之前我们讲到了当save指令的数据量过大时，单线程执行方式造成效率过低，那应该如何处理？

此时我们可以使用：bgsave指令，bg其实是background的意思，后台执行的意思

手动启动后台保存操作，但不是立即执行

bgsave

bgsave指令相关配置

后台存储过程中如果出现错误现象，是否停止保存操作，默认yes

stop-writes-on-bgsave-error yes|no

其 他

dbfilename filename  
dir path  
rdbcompression yes|no  
rdbchecksum yes|no

bgsave指令工作原理

当执行bgsave的时候，客户端发出bgsave指令给到redis服务器。注意，这个时候服务器马上回一个结果告诉客户端后台已经开始了，与此同时它会创建一个子进程，使用Linux的fork函数创建一个子进程，让这个子进程去执行save相关的操作，此时我们可以想一下，我们主进程一直在处理指令，而子进程在执行后台的保存，它会不会干扰到主进程的执行吗？

答案是不会，所以说他才是主流方案。子进程开始执行之后，它就会创建啊RDB文件把它存起来，操作完以后他会把这个结果返回，也就是说bgsave的过程分成两个过程，第一个是服务端拿到指令直接告诉客户端开始执行了；另外一个过程是一个子进程在完成后台的保存操作，操作完以后回一个消息。

5.2.3 save配置自动执行

设置自动持久化的条件，满足限定时间范围内key的变化数量达到指定数量即进行持久化

save second changes

参数

second：监控时间范围

changes：监控key的变化量

范例：

save 900 1
save 300 10
save 60 10000

其他相关配置：

dbfilename filename
dir path
rdbcompression yes|no
rdbchecksum yes|no
stop-writes-on-bgsave-error yes|no

save配置工作原理

5.2.4 RDB三种启动方式对比

方式 save指令 bgsave指令
读写 同步 异步
阻塞客户端指令 是 否
额外内存消耗 否 是
启动新进程 否 是

RDB特殊启动形式

服务器运行过程中重启

debug reload

关闭服务器时指定保存数据

shutdown save

全量复制（在主从复制中详细讲解）

RDB优点：

  • RDB是一个紧凑压缩的二进制文件，存储效率较高
  • RDB内部存储的是redis在某个时间点的数据快照，非常适合用于数据备份，全量复制等场景
  • RDB恢复数据的速度要比AOF快很多
  • 应用：服务器中每X小时执行bgsave备份，并将RDB文件拷贝到远程机器中，用于灾难恢复。

RDB缺点

  • RDB方式无论是执行指令还是利用配置，无法做到实时持久化，具有较大的可能性丢失数据
  • bgsave指令每次运行要执行fork操作创建子进程，要牺牲掉一些性能
  • Redis的众多版本中未进行RDB文件格式的版本统一，有可能出现各版本服务之间数据格式无法兼容现象

5.3 AOF

为什么要有AOF,这得从RDB的存储的弊端说起：

  • 存储数据量较大，效率较低，基于快照思想，每次读写都是全部数据，当数据量巨大时，效率非常低
  • 大数据量下的IO性能较低
  • 基于fork创建子进程，内存产生额外消耗
  • 宕机带来的数据丢失风险

那解决的思路是什么呢？

  • 不写全数据，仅记录部分数据
  • 降低区分数据是否改变的难度，改记录数据为记录操作过程
  • 对所有操作均进行记录，排除丢失数据的风险

5.3.1 AOF概念

AOF(append only file)持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令 达到恢复数据的目的。与RDB相比可以简单理解为由记录数据改为记录数据产生的变化

AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式

AOF写数据过程

启动AOF相关配置

开启AOF持久化功能，默认no，即不开启状态

appendonly yes|no

AOF持久化文件名，默认文件名为appendonly.aof，建议配置为appendonly-端口号.aof

appendfilename filename

AOF持久化文件保存路径，与RDB持久化文件保持一致即可

dir

AOF写数据策略，默认为everysec

appendfsync always|everysec|no

5.3.2 AOF执行策略

AOF写数据三种策略(appendfsync)

  • always(每次）：每次写入操作均同步到AOF文件中数据零误差，性能较低，不建议使用。
  • everysec（每秒）：每秒将缓冲区中的指令同步到AOF文件中，在系统突然宕机的情况下丢失1秒内的数据 数据准确性较高，性能较高，建议使用，也是默认配置
  • no（系统控制）：由操作系统控制每次同步到AOF文件的周期，整体过程不可控

5.3.3 AOF重写

场景：AOF写数据遇到的问题，如果连续执行如下指令该如何处理

什么叫AOF重写？

随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制压缩文件体积。AOF文件重 写是将Redis进程内的数据转化为写命令同步到新AOF文件的过程。简单说就是将对同一个数据的若干个条命令执行结 果转化成最终结果数据对应的指令进行记录。

AOF重写作用

  • 降低磁盘占用量，提高磁盘利用率
  • 提高持久化效率，降低持久化写时间，提高IO性能
  • 降低数据恢复用时，提高数据恢复效率

AOF重写规则

  • 进程内具有时效性的数据，并且数据已超时将不再写入文件

  • 非写入类的无效指令将被忽略，只保留最终数据的写入命令

    如del key1、 hdel key2、srem key3、set key4 111、set key4 222等

    如select指令虽然不更改数据，但是更改了数据的存储位置，此类命令同样需要记录

  • 对同一数据的多条写命令合并为一条命令

如lpushlist1 a、lpush list1 b、lpush list1 c可以转化为：lpush list1 a b c。

为防止数据量过大造成客户端缓冲区溢出，对list、set、hash、zset等类型，每条指令最多写入64个元素

AOF重写方式

  • 手动重写
bgrewriteaof

手动重写原理分析：

  • 自动重写
auto-aof-rewrite-min-size size
auto-aof-rewrite-percentage percentage

自动重写触发条件设置

auto-aof-rewrite-min-size size
auto-aof-rewrite-percentage percent

自动重写触发比对参数（ 运行指令info Persistence获取具体信息 ）

aof_current_size  
aof_base_size

自动重写触发条件公式：

5.3.4 AOF工作流程及重写流程

5.4 RDB与AOF区别

5.4.1 RDB与AOF对比（优缺点）

持久化方式 RDB AOF
占用存储空间 小（数据级：压缩） 大（指令级：重写）
存储速度 慢 快
恢复速度 快 慢
数据安全性 会丢失数据 依据策略决定
资源消耗 高/重量级 低/轻量级
启动优先级 低 高

5.4.2 RDB与AOF应用场景

RDB与AOF的选择之惑

  • 对数据非常敏感，建议使用默认的AOF持久化方案

AOF持久化策略使用everysecond，每秒钟fsync一次。该策略redis仍可以保持很好的处理性能，当出 现问题时，最多丢失0-1秒内的数据。

注意：由于AOF文件存储体积较大，且恢复速度较慢

  • 数据呈现阶段有效性，建议使用RDB持久化方案

数据可以良好的做到阶段内无丢失（该阶段是开发者或运维人员手工维护的），且恢复速度较快，阶段 点数据恢复通常采用RDB方案

注意：利用RDB实现紧凑的数据持久化会使Redis降的很低，慎重总结：

综合比对

  • RDB与AOF的选择实际上是在做一种权衡，每种都有利有弊
  • 如不能承受数分钟以内的数据丢失，对业务数据非常敏感，选用AOF
  • 如能承受数分钟以内的数据丢失，且追求大数据集的恢复速度，选用RDB
  • 灾难恢复选用RDB
  • 双保险策略，同时开启 RDB和 AOF，重启后，Redis优先使用 AOF 来恢复数据，降低丢失数据的量

Redis高级

1.数据删除与淘汰策略

1.1 过期数据

1.1.1 Redis中的数据特征

Redis是一种内存级数据库，所有数据均存放在内存中，内存中的数据可以通过TTL指令获取其状态

TTL返回的值有三种情况：正数，-1，-2

  • 正数：代表该数据在内存中还能存活的时间
  • -1：永久有效的数据
  • 2 ：已经过期的数据 或被删除的数据 或 未定义的数据

删除策略就是针对已过期数据的处理策略，已过期的数据是真的就立即删除了吗？其实也不是，我们会有多种删除策略，是分情况的，在不同的场景下使用不同的删除方式会有不同效果，这也正是我们要将的数据的删除策略的问题

1.1.2 时效性数据的存储结构

在Redis中，如何给数据设置它的失效周期呢？数据的时效在redis中如何存储呢？看下图：

过期数据是一块独立的存储空间，Hash结构，field是内存地址，value是过期时间，保存了所有key的过期描述，在最终进行过期处理的时候，对该空间的数据进行检测， 当时间到期之后通过field找到内存该地址处的数据，然后进行相关操作。

1.2 数据删除策略

1.2.1 数据删除策略的目标

在内存占用与CPU占用之间寻找一种平衡，顾此失彼都会造成整体redis性能的下降，甚至引发服务器宕机或 内存泄露

针对过期数据要进行删除的时候都有哪些删除策略呢？

  • 1.定时删除
  • 2.惰性删除
  • 3.定期删除

1.2.2 定时删除

创建一个定时器，当key设置有过期时间，且过期时间到达时，由定时器任务立即执行对键的删除操作

  • 优点：节约内存，到时就删除，快速释放掉不必要的内存占用
  • 缺点：CPU压力很大，无论CPU此时负载量多高，均占用CPU，会影响redis服务器响应时间和指令吞吐量
  • 总结：用处理器性能换取存储空间（拿时间换空间）

1.2.3 惰性删除

数据到达过期时间，不做处理。等下次访问该数据时，我们需要判断

  1. 如果未过期，返回数据
  2. 发现已过期，删除，返回不存在
  • 优点：节约CPU性能，发现必须删除的时候才删除
  • 缺点：内存压力很大，出现长期占用内存的数据
  • 总结：用存储空间换取处理器性能（拿时间换空间）

1.2.4 定期删除

定时删除和惰性删除这两种方案都是走的极端，那有没有折中方案？

我们来讲redis的定期删除方案：

  • Redis启动服务器初始化时，读取配置server.hz的值，默认为10

  • 每秒钟执行server.hz次serverCron()————>databasesCron()————->activeExpireCycle()

  • activeExpireCycle()对每个expires[*]逐一进行检测，每次执行耗时：250ms/server.hz

  • 对某个expires[*]检测时，随机挑选W个key检测

如果key超时，删除key

如果一轮中删除的key的数量>W*25%，循环该过程

如果一轮中删除的key的数量≤W*25%，检查下一个expires[*]，0-15循环

W取值=ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP属性值

  • 参数current_db用于记录activeExpireCycle() 进入哪个expires[*] 执行

  • 如果activeExpireCycle()执行时间到期，下次从current_db继续向下执行

总的来说：定期删除就是周期性轮询redis库中的时效性数据，采用随机抽取的策略，利用过期数据占比的方式控制删除频度

  • 特点1：CPU性能占用设置有峰值，检测频度可自定义设置
  • 特点2：内存压力不是很大，长期占用内存的冷数据会被持续清理
  • 总结：周期性抽查存储空间（随机抽查，重点抽查）

1.2.5 删除策略对比

1：定时删除：

节约内存，无占用,
不分时段占用CPU资源，频度高,
拿时间换空间

2：惰性删除：

内存占用严重
延时执行，CPU利用率高
拿空间换时间

3：定期删除：

内存定期随机清理
每秒花费固定的CPU资源维护内存
随机抽查，重点抽查

1.3 数据淘汰策略（逐出算法）

1.3.1 淘汰策略概述

什么叫数据淘汰策略？什么样的应用场景需要用到数据淘汰策略？

当新数据进入redis时，如果内存不足怎么办？在执行每一个命令前，会调用freeMemoryIfNeeded()检测内存是否充足。如果内存不满足新 加入数据的最低存储要求，redis要临时删除一些数据为当前指令清理存储空间。清理数据的策略称为逐出算法。

注意：逐出数据的过程不是100%能够清理出足够的可使用的内存空间，如果不成功则反复执行。当对所有数据尝试完毕， 如不能达到内存清理的要求，将出现错误信息如下

(error) OOM command not allowed when used memory >'maxmemory'

1.3.2 策略配置

影响数据淘汰的相关配置如下：

1：最大可使用内存，即占用物理内存的比例，默认值为0，表示不限制。生产环境中根据需求设定，通常设置在50%以上

maxmemory ?mb

2：每次选取待删除数据的个数，采用随机获取数据的方式作为待检测删除数据

maxmemory-samples count

3：对数据进行删除的选择策略

maxmemory-policy policy

那数据删除的策略policy到底有几种呢？一共是3类8种

第一类：检测易失数据（可能会过期的数据集server.db[i].expires ）

volatile-lru：挑选最近最少使用的数据淘汰
volatile-lfu：挑选最近使用次数最少的数据淘汰
volatile-ttl：挑选将要过期的数据淘汰
volatile-random：任意选择数据淘汰

第二类：检测全库数据（所有数据集server.db[i].dict ）

allkeys-lru：挑选最近最少使用的数据淘汰
allkeLyRs-lfu：：挑选最近使用次数最少的数据淘汰
allkeys-random：任意选择数据淘汰，相当于随机

第三类：放弃数据驱逐

no-enviction（驱逐）：禁止驱逐数据(redis4.0中默认策略)，会引发OOM(Out Of Memory)

注意：这些策略是配置到哪个属性上？怎么配置？如下所示

maxmemory-policy volatile-lru

数据淘汰策略配置依据

使用INFO命令输出监控信息，查询缓存 hit 和 miss 的次数，根据业务需求调优Redis配置

2.主从复制

2.1 主从复制简介

2.1.1 高可用

首先我们要理解互联网应用因为其独有的特性我们演化出的三高架构

  • 高并发

    应用要提供某一业务要能支持很多客户端同时访问的能力，我们称为并发，高并发意思就很明确了

  • 高性能

    性能带给我们最直观的感受就是：速度快，时间短

  • 高可用

可用性：一年中应用服务正常运行的时间占全年时间的百分比，如下图：表示了应用服务在全年宕机的时间

我们把这些时间加在一起就是全年应用服务不可用的时间，然后我们可以得到应用服务全年可用的时间

4小时27分15秒+11分36秒+2分16秒=4小时41分7秒=16867秒

1年=3652460*60=31536000秒

可用性=（31536000-16867）/31536000*100%=99.9465151%

业界可用性目标5个9，即99.999%，即服务器年宕机时长低于315秒，约5.25分钟

2.1.2 主从复制概念

知道了三高的概念之后，我们想：你的“Redis”是否高可用？那我们要来分析单机redis的风险与问题

问题1.机器故障

  • 现象：硬盘故障、系统崩溃
  • 本质：数据丢失，很可能对业务造成灾难性打击
  • 结论：基本上会放弃使用redis.

问题2.容量瓶颈

  • 现象：内存不足，从16G升级到64G，从64G升级到128G，无限升级内存
  • 本质：穷，硬件条件跟不上
  • 结论：放弃使用redis

结论：

为了避免单点Redis服务器故障，准备多台服务器，互相连通。将数据复制多个副本保存在不同的服务器上，连接在一起，并保证数据是同步的。即使有其中一台服务器宕机，其他服务器依然可以继续提供服务，实现Redis的高可用，同时实现数据冗余备份。

多台服务器连接方案：

  • 提供数据方：master

主服务器，主节点，主库主客户端

  • 接收数据方：slave

从服务器，从节点，从库

从客户端

  • 需要解决的问题：

数据同步（master的数据复制到slave中）

这里我们可以来解释主从复制的概念：

概念：主从复制即将master中的数据即时、有效的复制到slave中

特征：一个master可以拥有多个slave，一个slave只对应一个master

职责：master和slave各自的职责不一样

master:

写数据

执行写操作时，将出现变化的数据自动同步到slave

读数据（可忽略）

slave:

读数据

写数据（禁止）

2.1.3 主从复制的作用

  • 读写分离：master写、slave读，提高服务器的读写负载能力
  • 负载均衡：基于主从结构，配合读写分离，由slave分担master负载，并根据需求的变化，改变slave的数 量，通过多个从节点分担数据读取负载，大大提高Redis服务器并发量与数据吞吐量
  • 故障恢复：当master出现问题时，由slave提供服务，实现快速的故障恢复
  • 数据冗余：实现数据热备份，是持久化之外的一种数据冗余方式
  • 高可用基石：基于主从复制，构建哨兵模式与集群，实现Redis的高可用方案

2.2 主从复制工作流程

主从复制过程大体可以分为3个阶段

  • 建立连接阶段（即准备阶段）
  • 数据同步阶段
  • 命令传播阶段（反复同步）

而命令的传播其实有4种，分别如下：

2.2.1 主从复制的工作流程（三个阶段）

2.2.1.1 阶段一：建立连接

建立slave到master的连接，使master能够识别slave，并保存slave端口号

流程如下：

  1. 步骤1：设置master的地址和端口，保存master信息
  2. 步骤2：建立socket连接
  3. 步骤3：发送ping命令（定时器任务）
  4. 步骤4：身份验证
  5. 步骤5：发送slave端口信息

至此，主从连接成功！

当前状态：

slave：保存master的地址与端口

master：保存slave的端口

总体：之间创建了连接的socket

master和slave互联

接下来就要通过某种方式将master和slave连接到一起

方式一：客户端发送命令

slaveof masterip masterport

方式二：启动服务器参数

redis-server --slaveof masterip masterport

方式三：服务器配置（主流方式）

slaveof masterip masterport

slave系统信息

master_link_down_since_seconds
masterhost & masterport

master系统信息

uslave_listening_port(多个)

主从断开连接

断开slave与master的连接，slave断开连接后，不会删除已有数据，只是不再接受master发送的数据

slaveof no one

授权访问

master客户端发送命令设置密码

requirepass password

master配置文件设置密码

config set requirepass password
config get requirepass

slave客户端发送命令设置密码

auth password

slave配置文件设置密码

masterauth password

slave启动服务器设置密码

redis-server –a password
2.2.1.2 阶段二：数据同步
  • 在slave初次连接master后，复制master中的所有数据到slave
  • 将slave的数据库状态更新成master当前的数据库状态

同步过程如下：

  1. 步骤1：请求同步数据
  2. 步骤2：创建RDB同步数据
  3. 步骤3：恢复RDB同步数据
  4. 步骤4：请求部分同步数据
  5. 步骤5：恢复部分同步数据

至此，数据同步工作完成！

当前状态：

slave：具有master端全部数据，包含RDB过程接收的数据

master：保存slave当前数据同步的位置

总体：之间完成了数据克隆

数据同步阶段master说明

1：如果master数据量巨大，数据同步阶段应避开流量高峰期，避免造成master阻塞，影响业务正常执行

2：复制缓冲区大小设定不合理，会导致数据溢出。如进行全量复制周期太长，进行部分复制时发现数据已经存在丢失的情况，必须进行第二次全量复制，致使slave陷入死循环状态。

repl-backlog-size ?mb
  1. master单机内存占用主机内存的比例不应过大，建议使用50%-70%的内存，留下30%-50%的内存用于执 行bgsave命令和创建复制缓冲区

数据同步阶段slave说明

  1. 为避免slave进行全量复制、部分复制时服务器响应阻塞或数据不同步，建议关闭此期间的对外服务

    slave-serve-stale-data yes|no

  2. 数据同步阶段，master发送给slave信息可以理解master是slave的一个客户端，主动向slave发送命令

  3. 多个slave同时对master请求数据同步，master发送的RDB文件增多，会对带宽造成巨大冲击，如果master带宽不足，因此数据同步需要根据业务需求，适量错峰

  4. slave过多时，建议调整拓扑结构，由一主多从结构变为树状结构，中间的节点既是master，也是 slave。注意使用树状结构时，由于层级深度，导致深度越高的slave与最顶层master间数据同步延迟 较大，数据一致性变差，应谨慎选择

2.2.1.3 阶段三：命令传播
  • 当master数据库状态被修改后，导致主从服务器数据库状态不一致，此时需要让主从数据同步到一致的状态，同步的动作称为命令传播
  • master将接收到的数据变更命令发送给slave，slave接收命令后执行命令

命令传播阶段的部分复制

命令传播阶段出现了断网现象：

网络闪断闪连：忽略

短时间网络中断：部分复制

长时间网络中断：全量复制

这里我们主要来看部分复制，部分复制的三个核心要素

  1. 服务器的运行 id（run id）
  2. 主服务器的复制积压缓冲区
  3. 主从服务器的复制偏移量
  • 服务器运行ID（runid）
概念：服务器运行ID是每一台服务器每次运行的身份识别码，一台服务器多次运行可以生成多个运行id

组成：运行id由40位字符组成，是一个随机的十六进制字符
例如：fdc9ff13b9bbaab28db42b3d50f852bb5e3fcdce

作用：运行id被用于在服务器间进行传输，识别身份
如果想两次操作均对同一台服务器进行，必须每次操作携带对应的运行id，用于对方识别

实现方式：运行id在每台服务器启动时自动生成的，master在首次连接slave时，会将自己的运行ID发送给slave，
slave保存此ID，通过info Server命令，可以查看节点的runid
  • 复制缓冲区
概念：复制缓冲区，又名复制积压缓冲区，是一个先进先出（FIFO）的队列，用于存储服务器执行过的命令，每次传播命令，master都会将传播的命令记录下来，并存储在复制缓冲区
	复制缓冲区默认数据存储空间大小是1M
	当入队元素的数量大于队列长度时，最先入队的元素会被弹出，而新元素会被放入队列
作用：用于保存master收到的所有指令（仅影响数据变更的指令，例如set，select）

数据来源：当master接收到主客户端的指令时，除了将指令执行，会将该指令存储到缓冲区中

复制缓冲区内部工作原理：

组成

  • 偏移量

    概念：一个数字，描述复制缓冲区中的指令字节位置

    分类：

    • master复制偏移量：记录发送给所有slave的指令字节对应的位置（多个）
    • slave复制偏移量：记录slave接收master发送过来的指令字节对应的位置（一个）

    作用：同步信息，比对master与slave的差异，当slave断线后，恢复数据使用

    数据来源：

    • master端：发送一次记录一次
    • slave端：接收一次记录一次

  • 字节值

工作原理

  • 通过offset区分不同的slave当前数据传播的差异
  • master记录已发送的信息对应的offset
  • slave记录已接收的信息对应的offset

2.2.2 流程更新(全量复制/部分复制)

我们再次的总结一下主从复制的三个阶段的工作流程：

2.2.3 心跳机制

什么是心跳机制？

进入命令传播阶段候，master与slave间需要进行信息交换，使用心跳机制进行维护，实现双方连接保持在线

master心跳：

  • 内部指令：PING
  • 周期：由repl-ping-slave-period决定，默认10秒
  • 作用：判断slave是否在线
  • 查询：INFO replication 获取slave最后一次连接时间间隔，lag项维持在0或1视为正常

slave心跳任务

  • 内部指令：REPLCONF ACK {offset}
  • 周期：1秒
  • 作用1：汇报slave自己的复制偏移量，获取最新的数据变更指令
  • 作用2：判断master是否在线

心跳阶段注意事项：

  • 当slave多数掉线，或延迟过高时，master为保障数据稳定性，将拒绝所有信息同步
min-slaves-to-write 2
min-slaves-max-lag 8

slave数量少于2个，或者所有slave的延迟都大于等于8秒时，强制关闭master写功能，停止数据同步

  • slave数量由slave发送REPLCONF ACK命令做确认
  • slave延迟由slave发送REPLCONF ACK命令做确认

至此：我们可以总结出完整的主从复制流程：

2.3 主从复制常见问题

2.3.1 频繁的全量复制

  • 伴随着系统的运行，master的数据量会越来越大，一旦master重启，runid将发生变化，会导致全部slave的全量复制操作

内部优化调整方案：

1：master内部创建master_replid变量，使用runid相同的策略生成，长度41位，并发送给所有slave

2：在master关闭时执行命令shutdown save，进行RDB持久化,将runid与offset保存到RDB文件中

repl-id  repl-offset

通过redis-check-rdb命令可以查看该信息

3：master重启后加载RDB文件，恢复数据，重启后，将RDB文件中保存的repl-id与repl-offset加载到内存中

master_repl_id=repl  master_repl_offset =repl-offset

通过info命令可以查看该信息

作用：本机保存上次runid，重启后恢复该值，使所有slave认为还是之前的master

  • 第二种出现频繁全量复制的问题现象：网络环境不佳，出现网络中断，slave不提供服务

问题原因：复制缓冲区过小，断网后slave的offset越界，触发全量复制

最终结果：slave反复进行全量复制

解决方案：修改复制缓冲区大小

repl-backlog-size ?mb

建议设置如下：

1.测算从master到slave的重连平均时长second

2.获取master平均每秒产生写命令数据总量write_size_per_second

3.最优复制缓冲区空间 = 2 second write_size_per_second

2.3.2 频繁的网络中断

  • 问题现象：master的CPU占用过高 或 slave频繁断开连接

问题原因

slave每1秒发送REPLCONFACK命令到master

当slave接到了慢查询时（keys * ，hgetall等），会大量占用CPU性能

master每1秒调用复制定时函数replicationCron()，比对slave发现长时间没有进行响应

最终结果：master各种资源（输出缓冲区、带宽、连接等）被严重占用

解决方案：通过设置合理的超时时间，确认是否释放slave

repl-timeout seconds

该参数定义了超时时间的阈值（默认60秒），超过该值，释放slave

  • 问题现象：slave与master连接断开

问题原因

master发送ping指令频度较低

master设定超时时间较短

ping指令在网络中存在丢包

解决方案：提高ping指令发送的频度

repl-ping-slave-period seconds

超时时间repl-time的时间至少是ping指令频度的5到10倍，否则slave很容易判定超时

2.3.3 数据不一致

问题现象：多个slave获取相同数据不同步

问题原因：网络信息不同步，数据发送有延迟

解决方案

优化主从间的网络环境，通常放置在同一个机房部署，如使用阿里云等云服务器时要注意此现象

监控主从节点延迟（通过offset）判断，如果slave延迟过大，暂时屏蔽程序对该slave的数据访问
slave-serve-stale-data	yes|no

开启后仅响应info、slaveof等少数命令（慎用，除非对数据一致性要求很高）

3.哨兵模式

3.1 哨兵简介

3.1.1 哨兵概念

首先我们来看一个业务场景：如果redis的master宕机了，此时应该怎么办？

那此时我们可能需要从一堆的slave中重新选举出一个新的master，那这个操作过程是什么样的呢？这里面会有什么问题出现呢？

要实现这些功能，我们就需要redis的哨兵，那哨兵是什么呢？

哨兵

哨兵(sentinel) 是一个分布式系统，用于对主从结构中的每台服务器进行监控，当出现故障时通过投票机制选择新的master并将所有slave连接到新的master。

3.1.2 哨兵作用

哨兵的作用：

  • 监控：监控master和slave

    不断的检查master和slave是否正常运行

    master存活检测、master与slave运行情况检测

  • 通知（提醒）：当被监控的服务器出现问题时，向其他（哨兵间，客户端）发送通知
  • 自动故障转移：断开master与slave连接，选取一个slave作为master，将其他slave连接新的master，并告知客户端新的服务器地址

注意：哨兵也是一台redis服务器，只是不提供数据相关服务，通常哨兵的数量配置为单数

3.2 启用哨兵

配置哨兵

  • 配置一拖二的主从结构（利用之前的方式启动即可）

  • 配置三个哨兵（配置相同，端口不同），参看sentinel.conf

1：设置哨兵监听的主服务器信息， sentinel_number表示参与投票的哨兵数量

sentinel monitor master_name  master_host	master_port	 sentinel_number

2：设置判定服务器宕机时长，该设置控制是否进行主从切换

sentinel down-after-milliseconds master_name	million_seconds

3：设置故障切换的最大超时时

sentinel failover-timeout master_name	million_seconds

4：设置主从切换后，同时进行数据同步的slave数量，数值越大，要求网络资源越高，数值越小，同步时间越长

sentinel parallel-syncs master_name sync_slave_number
  • 启动哨兵
redis-sentinel filename

3.3 哨兵工作原理

哨兵在进行主从切换过程中经历三个阶段

  • 监控
  • 通知
  • 故障转移

3.3.1 监控

用于同步各个节点的状态信息

  • 获取各个sentinel的状态（是否在线）
  • 获取master的状态
master属性
	prunid
	prole：master
各个slave的详细信息
  • 获取所有slave的状态（根据master中的slave信息）
slave属性
	prunid
	prole：slave
	pmaster_host、master_port
	poffset

其内部的工作原理具体如下：

3.3.2 通知

sentinel在通知阶段要不断的去获取master/slave的信息，然后在各个sentinel之间进行共享，具体的流程如下：

3.3.3 故障转移

当master宕机后sentinel是如何知晓并判断出master是真的宕机了呢？我们来看具体的操作流程

当sentinel认定master下线之后，此时需要决定更换master，那这件事由哪个sentinel来做呢？这时候sentinel之间要进行选举，如下图所示：

在选举的时候每一个人手里都有一票，而每一个人的又都想当这个处理事故的人，那怎么办？大家就开始抢，于是每个人都会发出一个指令，在内网里边告诉大家我要当选举人，比如说现在的sentinel1和sentinel4发出这个选举指令了，那么sentinel2既能接到sentinel1的也能接到sentinel4的，接到了他们的申请以后呢，sentinel2他就会把他的一票投给其中一方，投给谁呢？谁先过来我投给谁，假设sentinel1先过来，所以这个票就给到了sentinel1。那么给过去以后呢，现在sentinel1就拿到了一票，按照这样的一种形式，最终会有一个选举结果。对应的选举最终得票多的，那自然就成为了处理事故的人。需要注意在这个过程中有可能会存在失败的现象，就是一轮选举完没有选取，那就会接着进行第二轮第三轮直到完成选举。

接下来就是由选举胜出的sentinel去从slave中选一个新的master出来的工作，这个流程是什么样的呢？

首先它有一个在服务器列表中挑选备选master的原则

  • 不在线的OUT
  • 响应慢的OUT
  • 与原master断开时间久的OUT

  • 优先原则

    ​ 优先级
    ​ offset
    ​ runid

选出新的master之后，发送指令（ sentinel ）给其他的slave：

  • 向新的master发送slaveof no one
  • 向其他slave发送slaveof 新masterIP端口

总结：故障转移阶段

  1. 发现问题，主观下线与客观下线
  2. 竞选负责人
  3. 优选新master
  4. 新master上任，其他slave切换master，原master作为slave故障恢复后连接

4.集群cluster

现状问题：业务发展过程中遇到的峰值瓶颈

  • redis提供的服务OPS可以达到10万/秒，当前业务OPS已经达到10万/秒
  • 内存单机容量达到256G，当前业务需求内存容量1T
  • 使用集群的方式可以快速解决上述问题

4.1 集群简介

集群就是使用网络将若干台计算机联通起来，并提供统一的管理方式，使其对外呈现单机的服务效果

集群作用：

  • 分散单台服务器的访问压力，实现负载均衡
  • 分散单台服务器的存储压力，实现可扩展性
  • 降低单台服务器宕机带来的业务灾难

4.2 Cluster集群结构设计

数据存储设计：

  1. 通过算法设计，计算出key应该保存的位置

  2. 将所有的存储空间计划切割成16384份，每台主机保存一部分

    注意：每份代表的是一个存储空间，不是一个key的保存空间

  3. 将key按照计算出的结果放到对应的存储空间

那redis的集群是如何增强可扩展性的呢？譬如我们要增加一个集群节点

当我们查找数据时，集群是如何操作的呢？

  • 各个数据库相互通信，保存各个库中槽的编号数据
  • 一次命中，直接返回
  • 一次未命中，告知具体位置

4.3 Cluster集群结构搭建

首先要明确的几个要点：

  • 配置服务器（3主3从）
  • 建立通信（Meet）
  • 分槽（Slot）
  • 搭建主从（master-slave）

Cluster配置

  • 是否启用cluster，加入cluster节点
cluster-enabled yes|no
  • cluster配置文件名，该文件属于自动生成，仅用于快速查找文件并查询文件内容
cluster-config-file filename
  • 节点服务响应超时时间，用于判定该节点是否下线或切换为从节点
cluster-node-timeout milliseconds
  • master连接的slave最小数量
cluster-migration-barrier min_slave_number

Cluster节点操作命令

  • 查看集群节点信息
cluster nodes
  • 更改slave指向新的master
cluster replicate master-id
  • 发现一个新节点，新增master
cluster meet ip:port
  • 忽略一个没有solt的节点
cluster forget server_id
  • 手动故障转移
cluster failover

集群操作命令：

  • 创建集群
redis-cli –-cluster create masterhost1:masterport1 masterhost2:masterport2  masterhost3:masterport3 [masterhostn:masterportn …] slavehost1:slaveport1  slavehost2:slaveport2 slavehost3:slaveport3 -–cluster-replicas n

注意：master与slave的数量要匹配，一个master对应n个slave，由最后的参数n决定

master与slave的匹配顺序为第一个master与前n个slave分为一组，形成主从结构

  • 添加master到当前集群中，连接时可以指定任意现有节点地址与端口
redis-cli --cluster add-node new-master-host:new-master-port now-host:now-port
  • 添加slave
redis-cli --cluster add-node new-slave-host:new-slave-port master-host:master-port --cluster-slave --cluster-master-id masterid
  • 删除节点，如果删除的节点是master，必须保障其中没有槽slot
redis-cli --cluster del-node del-slave-host:del-slave-port del-slave-id
  • 重新分槽，分槽是从具有槽的master中划分一部分给其他master，过程中不创建新的槽
redis-cli --cluster reshard new-master-host:new-master:port --cluster-from src-  master-id1, src-master-id2, src-master-idn --cluster-to target-master-id --  cluster-slots slots

注意：将需要参与分槽的所有masterid不分先后顺序添加到参数中，使用，分隔

指定目标得到的槽的数量，所有的槽将平均从每个来源的master处获取

  • 重新分配槽，从具有槽的master中分配指定数量的槽到另一个master中，常用于清空指定master中的槽
redis-cli --cluster reshard src-master-host:src-master-port --cluster-from src-  master-id --cluster-to target-master-id --cluster-slots slots --cluster-yes

5.企业级解决方案

5.1 缓存预热

场景：“宕机”

服务器启动后迅速宕机

问题排查：

1.请求数量较高，大量的请求过来之后都需要去从缓存中获取数据，但是缓存中又没有，此时从数据库中查找数据然后将数据再存入缓存，造成了短期内对redis的高强度操作从而导致问题

2.主从之间数据吞吐量较大，数据同步操作频度较高

解决方案：

  • 前置准备工作：

1.日常例行统计数据访问记录，统计访问频度较高的热点数据

2.利用LRU数据删除策略，构建数据留存队列例如：storm与kafka配合

  • 准备工作：

1.将统计结果中的数据分类，根据级别，redis优先加载级别较高的热点数据

2.利用分布式多服务器同时进行数据读取，提速数据加载过程

3.热点数据主从同时预热

  • 实施：

4.使用脚本程序固定触发数据预热过程

5.如果条件允许，使用了CDN（内容分发网络），效果会更好

总的来说：缓存预热就是系统启动前，提前将相关的缓存数据直接加载到缓存系统。避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题！用户直接查询事先被预热的缓存数据！

5.2 缓存雪崩

场景：数据库服务器崩溃，一连串的场景会随之儿来

1.系统平稳运行过程中，忽然数据库连接量激增

2.应用服务器无法及时处理请求

3.大量408，500错误页面出现

4.客户反复刷新页面获取数据

5.数据库崩溃

6.应用服务器崩溃

7.重启应用服务器无效

8.Redis服务器崩溃

9.Redis集群崩溃

10.重启数据库后再次被瞬间流量放倒

问题排查：

1.在一个较短的时间内，缓存中较多的key集中过期

2.此周期内请求访问过期的数据，redis未命中，redis向数据库获取数据

3.数据库同时接收到大量的请求无法及时处理

4.Redis大量请求被积压，开始出现超时现象

5.数据库流量激增，数据库崩溃

6.重启后仍然面对缓存中无数据可用

7.Redis服务器资源被严重占用，Redis服务器崩溃

8.Redis集群呈现崩塌，集群瓦解

9.应用服务器无法及时得到数据响应请求，来自客户端的请求数量越来越多，应用服务器崩溃

10.应用服务器，redis，数据库全部重启，效果不理想

总而言之就两点：短时间范围内，大量key集中过期

解决方案

  • 思路：

1.更多的页面静态化处理

2.构建多级缓存架构

​ Nginx缓存+redis缓存+ehcache缓存

3.检测Mysql严重耗时业务进行优化

​ 对数据库的瓶颈排查：例如超时查询、耗时较高事务等

4.灾难预警机制

​ 监控redis服务器性能指标

​ CPU占用、CPU使用率

​ 内存容量

​ 查询平均响应时间

​ 线程数

5.限流、降级

短时间范围内牺牲一些客户体验，限制一部分请求访问，降低应用服务器压力，待业务低速运转后再逐步放开访问

  • 落地实践：

1.LRU与LFU切换

2.数据有效期策略调整

​ 根据业务数据有效期进行分类错峰，A类90分钟，B类80分钟，C类70分钟

​ 过期时间使用固定时间+随机值的形式，稀释集中到期的key的数量

3.超热数据使用永久key

4.定期维护（自动+人工）

​ 对即将过期数据做访问量分析，确认是否延时，配合访问量统计，做热点数据的延时

5.加锁：慎用！

总的来说：缓存雪崩就是瞬间过期数据量太大，导致对数据库服务器造成压力。如能够有效避免过期时间集中，可以有效解决雪崩现象的 出现（约40%），配合其他策略一起使用，并监控服务器的运行数据，根据运行记录做快速调整。

5.3 缓存击穿

场景：还是数据库服务器崩溃，但是跟之前的场景有点不太一样

1.系统平稳运行过程中

2.数据库连接量瞬间激增

3.Redis服务器无大量key过期

4.Redis内存平稳，无波动

5.Redis服务器CPU正常

6.数据库崩溃

问题排查：

1.Redis中某个key过期，该key访问量巨大

2.多个数据请求从服务器直接压到Redis后，均未命中

3.Redis在短时间内发起了大量对数据库中同一数据的访问

总而言之就两点：单个key高热数据，key过期

解决方案：

1.预先设定

​ 以电商为例，每个商家根据店铺等级，指定若干款主打商品，在购物节期间，加大此类信息key的过期时长 注意：购物节不仅仅指当天，以及后续若干天，访问峰值呈现逐渐降低的趋势

2.现场调整

​ 监控访问量，对自然流量激增的数据延长过期时间或设置为永久性key

3.后台刷新数据

​ 启动定时任务，高峰期来临之前，刷新数据有效期，确保不丢失

4.二级缓存

​ 设置不同的失效时间，保障不会被同时淘汰就行

5.加锁

​ 分布式锁，防止被击穿，但是要注意也是性能瓶颈，慎重！

总的来说：缓存击穿就是单个高热数据过期的瞬间，数据访问量较大，未命中redis后，发起了大量对同一数据的数据库访问，导致对数 据库服务器造成压力。应对策略应该在业务数据分析与预防方面进行，配合运行监控测试与即时调整策略，毕竟单个key的过 期监控难度较高，配合雪崩处理策略即可。

5.4 缓存穿透

场景：数据库服务器又崩溃了，跟之前的一样吗？

1.系统平稳运行过程中

2.应用服务器流量随时间增量较大

3.Redis服务器命中率随时间逐步降低

4.Redis内存平稳，内存无压力

5.Redis服务器CPU占用激增

6.数据库服务器压力激增

7.数据库崩溃

问题排查：

1.Redis中大面积出现未命中

2.出现非正常URL访问

问题分析：

  • 获取的数据在数据库中也不存在，数据库查询未得到对应数据
  • Redis获取到null数据未进行持久化，直接返回
  • 下次此类数据到达重复上述过程
  • 出现黑客攻击服务器

解决方案：

1.缓存null

​ 对查询结果为null的数据进行缓存（长期使用，定期清理），设定短时限，例如30-60秒，最高5分钟

2.白名单策略

​ 提前预热各种分类数据id对应的bitmaps，id作为bitmaps的offset，相当于设置了数据白名单。当加载正常数据时放行，加载异常数据时直接拦截（效率偏低）

​ 使用布隆过滤器（有关布隆过滤器的命中问题对当前状况可以忽略）

2.实施监控

​ 实时监控redis命中率（业务正常范围时，通常会有一个波动值）与null数据的占比

​ 非活动时段波动：通常检测3-5倍，超过5倍纳入重点排查对象

​ 活动时段波动：通常检测10-50倍，超过50倍纳入重点排查对象

​ 根据倍数不同，启动不同的排查流程。然后使用黑名单进行防控（运营）

4.key加密

​ 问题出现后，临时启动防灾业务key，对key进行业务层传输加密服务，设定校验程序，过来的key校验

​ 例如每天随机分配60个加密串，挑选2到3个，混淆到页面数据id中，发现访问key不满足规则，驳回数据访问

总的来说：缓存击穿是指访问了不存在的数据，跳过了合法数据的redis数据缓存阶段，每次访问数据库，导致对数据库服务器造成压力。通常此类数据的出现量是一个较低的值，当出现此类情况以毒攻毒，并及时报警。应对策略应该在临时预案防范方面多做文章。

无论是黑名单还是白名单，都是对整体系统的压力，警报解除后尽快移除。

5.5 性能指标监控

redis中的监控指标如下：

  • 性能指标：Performance

响应请求的平均时间:

>latency

平均每秒处理请求总数

>instantaneous_ops_per_sec

缓存查询命中率（通过查询总次数与查询得到非nil数据总次数计算而来）

>hit_rate(calculated)

  • 内存指标：Memory

    当前内存使用量

    >used_memory

    内存碎片率（关系到是否进行碎片整理）

    >mem_fragmentation_ratio

    为避免内存溢出删除的key的总数量

    >evicted_keys

    基于阻塞操作（BLPOP等）影响的客户端数量

    >blocked_clients

  • 基本活动指标：Basic_activity

当前客户端连接总数

>connected_clients

当前连接slave总数

>connected_slaves

最后一次主从信息交换距现在的秒

>master_last_io_seconds_ago

key的总数

>keyspace
  • 持久性指标：Persistence

当前服务器最后一次RDB持久化的时间

>rdb_last_save_time

当前服务器最后一次RDB持久化后数据变化总量

>rdb_changes_since_last_save
  • 错误指标：Error

被拒绝连接的客户端总数（基于达到最大连接值的因素）

>rejected_connections

key未命中的总次数

>keyspace_misses

主从断开的秒数

>master_link_down_since_seconds

要对redis的相关指标进行监控，我们可以采用一些用具：

  • CloudInsight Redis
  • Prometheus
  • Redis-stat
  • Redis-faina
  • RedisLive
  • zabbix

也有一些命令工具：

  • benchmark

测试当前服务器的并发性能

>redis-benchmark [-h ] [-p ] [-c ] [-n <requests]> [-k ]

范例1：50个连接，10000次请求对应的性能

>redis-benchmark

范例2：100个连接，5000次请求对应的性能

>redis-benchmark -c 100 -n 5000

  • redis-cli

    ​ monitor：启动服务器调试信息

>monitor
  slowlog：慢日志

获取慢查询日志

>slowlog [operator]

​ get ：获取慢查询日志信息

​ len ：获取慢查询日志条目数

​ reset ：重置慢查询日志

相关配置

>slowlog-log-slower-than 1000 #设置慢查询的时间下线，单位：微妙
>slowlog-max-len 100	#设置慢查询命令对应的日志显示长度，单位：命令数