redis -速成

目录

（一）认识 Redis

 1.1数据库分类

 1.2 什么是Redis

1.2.1 redis简介

1.2.2 谁在用Redis

1.2.3 怎么学redis

1.2.4 Redis的安装

2 数据类型 

2.1 概况

2.2 String类型

 2.2.1 常用的命令

2.2.2  非常用命令

2.2.3 举例

2.2.4应用场景：

2.3 Hash类型

2.3.1 常用的命令

2.3.2 应用举例

2.3.3 应用场景

2.4 List类型

2.4.1 常用的命令

 2.4.2 非常用命令

2.4.3 应用举例、

2.4.4 应用场景

2.5 Set类型

2.5.1 常用的命令 

2.5.2 非常用命令

2.5.3 应用举例

2.5.4  应用场景

2.6  Sorted set 类型

 2.6.1 常用的命令

 2.6.2 非常用的命令

2.6.3 应用举例

2.6.4 应用场景

2.7 类型总结

2.7.1Value设计

2.7.2  Key设计

3.Redis全局命令

3.1  Redis安全性

3.2 Redis事务

3.3Redis持久化机制

3.3.1 RDB方式

3.3.2 AOF方式

3.4.3 Redis内存淘汰机制

3.3.4 过期Key处理

（一）认识 Redis

        1.1数据库分类

        目前数据库分：关系型数据库与非关系型数据库常用的关系型数据库： Oracle **MySQL**，SqlServer，DB2 常用的非关系数据库：**Redis**，MongoDB，ElasticSearch， Hbase，Neo4j 那啥是非关系数据库呢？此处涉及到新名词：NoSQL NoSQL最常见的解释是“non-relational”， “Not Only SQL”也被很多人接受。NoSQL仅仅是一个概念，泛指非关系型的数据库，区别于关系数据库，它们不保证关系数据的ACID特性。详情见：百度百科：https://baike.baidu.com/item/NoSQL/8828247?fr=aladdin

经典案例

NoSQL分类:

 1.2 什么是Redis

   1.2.1 redis简介

是以key-value形式存储,和传统的关系型数据库不一样.不一定遵循传统数据库的一些基本要求.(非关系型的,分布式的,开源的,水平可拓展的)

优点: 对数据高并发读写(直接是内存中进行读写的) 对海量数据的高效率存储和访问 对数据的可拓展性和高可用性. 单线程操作,每个操作都是原子操作,没有并发相关问题(redis 6).

缺点: redis(ACID处理非常简单) 无法做太复杂的关系数据库模型.

1.2.2 谁在用Redis

        比较著名的公司有： github、blizzard、stackoverflow、flickr国内 新浪微博（全球最大的redis集群）【2017】 2200+亿 commands/day 5000亿Read/day 500亿Write/day 18TB+ Memory
500+ Servers in 6 IDC 2000+instances 淘宝 腾讯微博

1.2.3 怎么学redis

        redis在线入门 ： http://try.redis.io/ redis 中文资料站： http://www.redis.cn/ https://www.runoob.com/redis/redis-tutorial.html.

1.2.4 Redis的安装

    题外话：
Redis是使用C写的程序，目前主流在Linux操作系统，官方不提供Window版，最新的Redis版：Redis7.x.

官网下载：https://redis.io/download/

Redis 的Window版是微软公司自行移植的，目前最新版：Redis-x64-3.2.100

window版：https://github.com/microsoftarchive/redis/releases/tag/win-3.2.100。

服务端

 版本：Redis-x64-3.2.100.msi
傻瓜式安装,下一步,下一步就可以了
注意：添加到环境变量中

注意：默认端口

客户端--redisclient

 客户端--RedisDesktopClient

客户端--rdm

2 数据类型 

        2.1 概况

Redis支持的存储数据类型有很多：
常用：**string**（字符串），**hash**（哈希），**list**（列表），**set**（集合）及**zset**(sorted set：有序集合)
不常用：HyperLogLog，Bitmap(位图)，Bloom Filter(布隆过滤器)，Geospatial(地理位置) ，Module(模块)， Streams(流信息) 此处重点讲解常用的类型。

命令格式

类型命令 key 参数数据
set name dafei
操作建议Redis操作有点类似Java的Map集合，都是key-value形式存储数据，在学习过程中，可以进行类比。另外Redis中的key大部分为String类型，value值根据缓存数据结构可以选用：string，hash，list，set，zset等类型。
注意：下面讲的各种类型，表述的是缓存数据的value类型。

2.2 String类型

        String类型包含多种类型的特殊类型，并且是二进制安全的，其值可以是数值，可以是字符串，也可以是二进制数据。类似Java中：**Map map**

在Redis内容数据存储结构：

 2.2.1 常用的命令

2.2.2  非常用命令

2.2.3 举例

2.2.4应用场景：

1> 计数器

如：视频播放数系统就是使用redis作为视频播放数计数的基础组件。

incr viewnum 1

2>共享session

出于负载均衡的考虑，分布式服务会将用户信息的访问均衡到不同服务器上，用户刷新一次访问可能会需要重新登录，为避免这个问题可以用redis将用户session集中管理， 在这种模式下只要保证redis的高可用和扩展性的，每次获取用户更新或查询登录信息都直接从redis中集中获取。

image]
user_login_info:uid---->{"id":1, "name":"dafei", "age":18}

2.3 Hash类型

        Hash类型是String类型的field和value的映射表，或者说是一个String集合。它特别适合存储对象，相比较而言，将一个对象存储在Hash类型里要比存储在String类型里占用更少的内存空间。

2.3.1 常用的命令

2.3.2 应用举例

2.3.3 应用场景

Hash结构相对于字符串序列化缓存信息更加直观，并且在更新操作上更加便捷。

共享session设计。

        public class User{
private String userame;
private String password;
private int age;
}

登录用户：

User user = new User("dafei", "666", 18);

登录缓存：

        key：**user_token** value：**new User("dafei", "666", 18)**

方案1： 将user对象转换json格式字符串存redis 【侧重于查， 改非常麻烦】

key value

user_token ： "{name:dafei, age:18, password:666}"

方案2： 将user对象转换hash对象存redis【侧重于改，查询相对麻烦】

key value

user_token ： {
​ name：ddafei
​ age ： 18
​ password： 666
​ }

2.4 List类型

        Redis中的List类似Java中的Queue,也可以当做List来用.List类型是一个链表结构的集合，其主要功能有push、pop、获取元素等，更详细的说,List类型是一个双端链表的结构，我们可以通过相关操作进行集合的头部或者尾部添加删除元素，List的设计非常简单精巧，即可以作为栈,又可以作为队列，满足绝大多数需求.

        类似Java中：**Map map**

2.4.1 常用的命令

 2.4.2 非常用命令

2.4.3 应用举例、

2.4.4 应用场景

1>用户收藏文章列表：key：user_favor_article_list value: [aid1, aid2, aid3......]

2.5 Set类型

        Set集合是String类型的无序集合,set是通过HashTable实现的，对集合我们可以取**交集、并集、差集。**类似Java中：**Map map**

2.5.1 常用的命令 

2.5.2 非常用命令

2.5.3 应用举例

2.5.4  应用场景

   1，去重；

2，抽奖;
1：准备一个抽奖池:sadd luckydraw 1 2 3 4 5 6 7 8 9 10 11 12 13
​2：抽3个三等奖:spop luckydraw 3
​3：抽2个二等奖:spop luckydraw 2
​4：抽1个:一等奖:spop luckydraw 1

2.6  Sorted set 类型

       Sorted set 也称Zset类型，是一种具有排序效果的set集合。它跟set集合一样也是 string 类型元素的集合，且不允许重复的成员。并且要求每个元素都会关联一个double 类型的分数。后续可以通过分数来为集合中的成员进行从小到大的排序。Sorted set集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是 O(1)。 集合中最大的成员数为 232 - 1 (4294967295,每个集合可存储40多亿个成员)。

数据缓存结构：

 2.6.1 常用的命令

 2.6.2 非常用的命令

2.6.3 应用举例

2.6.4 应用场景

  排行榜：有序集合经典使用场景。例如视频网站需要对用户上传的视频做排行榜，榜单维护可能是多方面：按照时间、按照播放量、按照获得的赞数等。

2.7 类型总结

一个问题，Redis在项目中如何使用？
思考点：
1>项目是否需要使用到缓存？使用
2>使用缓存是否选用Redis？选用
3>使用Redis那该怎么设计Key-Value值？
这里重点讨论Redis的KV对的设计

2.7.1Value设计

先说value值的设计其实就是value类型选用： String， Hash， List， Set， Sort Set。

一般考虑：
● 是否需要排序？要使用Sort Set
● 缓存的数据是多个值还是单个值，
● 多个值：允许重复选List 不允许重复选择Set
● 单个值：简单值选择String， 对象值选择Hash

一种取巧的方式：

● 是否需要排序？要使用Sort Set
● 剩下使用String

操作方式：
所有value之后都转换成json格式字符串，然后缓存到Redis，原因：Java操作方便，减少泛型操作麻烦比如

List<String>list = ...
Set<String> set = ....
Map<String, Object> map = ....
List<Object> list = redis对象.getList
Set<Object> set =redis对象.getSet
Map<Object, Object> map = redis对象.getMap

不管存放啥数据类型，从reds中获取出来都是Object类型，后续对象强制转换麻烦，干脆直接使用字符串。

2.7.2  Key设计

Redis 的key 设计讲究4个性：

唯一性
Redis 类似Map集合，key必须保证唯一，缓存同一个key时，后者会覆盖前者，所有必须要求唯一，那如何保证唯一呢？最常用的方式：**使用缓存数据的主键作为key**。

比如：缓存员工信息

key value
----------------------------------------------------------------
1 员工1
2 员工2
其中的1， 2 是员工的id

可读性
可读性是保证Redis的key能做到见名知意，上面的员工id1， 员工id2 虽说能保证key唯一，但可读性非常差，维护key时，无法从， 1， 2中快速判断该key对应value值。所以一一般在保证key唯一的前提下，给key加上前缀：

key value

----------------------------------------------------------------
employee_info:id1 员工1
employee_info:id2 员工2
employee_info:id1 employee_info:id2 这样子设计key，可读性就好多了。
可读性前缀的设计规范千奇百怪，我个人比较推崇的：

● 普通单值
key value
----------------------------------------------------------------
employe_info:id1 员工对象信息
● 类似关系型数据库设计
表名:主键名:主键值:列名
key value
----------------------------------------------------------------
employee : id : 1:info 员工对象信息
● 通用玩法
业务模块名:业务逻辑含义:其他:value类型
key value

-----------------------------------------------------------------------
employee :base.info:id1:hash 员工对象信息
业务模块名：表示该key属于哪个功能模块
业务逻辑含义段：这里可以使用 . 分开， 具体业务逻辑表示
​ 比如：缓存员工权限
​ employee:auth.permission:id1:set 员工权限集合
其他：一般设置唯一标识，比如主键
value类型：key对应value类型值，提高可读性。

灵活性

这个难介绍，一般key保证唯一时，可以使用主键，有的使用，一个主键不能表达出全部意思，可以使用联合主键。
比如：
id为1的朋友圈下id为A的评论。
key value
-----------------------------------------------------------------------
post:1:reply:A 评论内容
post:1:reply:B 评论内容

时效性
Redis key一定要设置过期时间。要跟自己的业务场景，需要对key设置合理的过期时间。可以在写入key时，就要追加过期时
间；也可以在按照需要动态设置。
这里要注意：
● 不设置过期时间，这种key为永久key，会一直占用内存不释放，时间久了，数量一多，就容易达到服务器的内存上限，导
致宕机，开发时一般配合Key过期策略使用哦。
● key的时效性设置，必须根据业务场景进行评估，设置合理有效期；

3.Redis全局命令

        全局命令针对的是所有的key，大部分用来做运维，做管理的

常用的全局key

3.1  Redis安全性

        因为Redis速度非常快，所以在一台比较好的服务器下,一个外部用户在一秒内可以进行15w次的密码尝试，这意味你需要设定非常强大的密码来方式暴力破解。此时就需要对Redis进行密码设置啦。
Linux系统
编辑 redis.conf文件，找到下面进行保存修改 requirepass 自定义密码
重启Redis服务，访问时，使用带密码的命令：
redis-cli -a 自定义密码 否则会提示： (error)NOAUTH Authentication required.
Window系统
跟Linux系统一样，区别是，window系统的文件是redis.window-service.config

3.2 Redis事务

        一个事务从开始到执行会经历以下三个阶段：
● 开始事务。
● 命令入队。
● 执行事务。
借用：菜鸟教程中例子 它先以 MULTI 开始一个事务， 然后将多个命令入队到事务中， 最后由 EXEC 命令触发事务， 一并执行事务中的所有命令：

 redis 127.0.0.1:6379> MULTI
OK
redis 127.0.0.1:6379> SET book-name "Mastering C++ in 21 days"
QUEUED
redis 127.0.0.1:6379> GET book-name
QUEUED
redis 127.0.0.1:6379> SADD tag "C++" "Programming" "Mastering Series"
QUEUED
redis 127.0.0.1:6379> SMEMBERS tag
QUEUED
redis 127.0.0.1:6379> EXEC
1) OK
2) "Mastering C++ in 21 days"
3) (integer) 3
4) 1) "Mastering Series"
2) "C++"
3) "Programming"

单个 Redis 命令的执行是原子性的，但 Redis 没有在事务上增加任何维持原子性的机制，所以 Redis 事务的执行并不是原子性的。Redis事务可以理解为一个**打包的批量执行脚本**，但批量指令并非原子化的操作，中间某条指令的失败不会导致前面已做指令的回滚，也不会造成后续的指令不做。

127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> set name dafei
QUEUED
127.0.0.1:6379(TX)> set age 18
QUEUED
127.0.0.1:6379(TX)> incr age
QUEUED
127.0.0.1:6379(TX)> incr name
QUEUED
127.0.0.1:6379(TX)> get age
QUEUED
127.0.0.1:6379(TX)> get name
QUEUED
127.0.0.1:6379(TX)> exec
1) OK
2) OK
3) (integer) 19
4) (error) ERR value is not an integer or out of range
5) "19"
6) "dafei"
127.0.0.1:6379>

Redis 事务可以一次执行多个命令， 并且带有以下三个重要的保证：
● 批量操作在发送 EXEC 命令前被放入队列缓存。
● 收到 EXEC 命令后进入事务执行，事务中任意命令执行失败，其余的命令依然被执行。
● 在事务执行过程，其他客户端提交的命令请求不会插入到事务执行命令序列中。

3.3Redis持久化机制

引言

先来一个小实验，大家可以一起实现一下
步骤1：在Redis中添加2个key-value对

127.0.0.1:6379> set aa aa
OK
127.0.0.1:6379> set bb bb
OK
127.0.0.1:6379> keys *

步骤2：重启Redis 服务器，在执行keys * 观察数据
步骤3：分析结果
会出现一下几种结果：
● 之前的key在，aa bb 都在（最理想的结果）
● 之前的key在，aa也在，bb不见了
● 之前的key在，aa， bb 不在
● 之前的key， aa， bb 都不在了（最坏的结果）
思考：
为啥会这样？以我们对内存的操作理解，按道理重启之后数据应该全丢失了，为啥Redis 可能丢失，也可能不丢失，为何？这里就涉及到Redis的持久化机制了。

 Redis持久化机制目前以后3种，分别为：
1>快照方式（RDB, Redis DataBase）
2>文件追加方式（AOF, Append Only File）
3>混合持久化方式（Redis4版本之后）

3.3.1 RDB方式

Snapshotting(快照)默认方式，将内存数据中以快照的方式写入到二进制文件中，默认为dump.rdb。触发RDB持久化过程分手动触发与自动触发。

触发机制

手动触发
使用save命令：会阻塞当前Redis服务器，知道RDB过程完成为主，如果内存数据较多，会造成长时间阻塞，影响其他命令的使用，不建议轻易使用
使用bgsave命令：Redis进程执行fork指令创建子进程，由子进程实现RDB持久化，有需要时建议使用bgsave命令。
自动触发
使用save相关配置，格式： save m n 表示m秒内数据集存在n次修改时会自动触发bgsave命令。 

save 900 1 #900秒内如果超过1个Key被修改则发起快照保存
save 300 10 #300秒内如果超过10个key被修改,则发起快照保存
save 60 10000

优点

● RDB快照文件是一个紧凑压缩的二进制文件，非常使用用于备份，全量复制等场景。开发中可以按照每6小时执行一次bgsave备份，用于容灾备份。
● Redis加载RDB恢复数据远远快于AOF方式

缺点
● RDB无法做到实时持久化/秒级持久化，每次bgsave时都需要fork子进程，频繁执行有时间本。
● RDB快照文件不同版本格式不一样，容易引起兼容问题。

3.3.2 AOF方式

AOF与RDB不一样，它是一独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令达到恢复数据的目的。解决了数据持久化的实时性的问题。Redis默认是不开启的，需要使用时，需要配置： appendonly yes AOF 有3种文件同步策略

 优点
● AOF方式数据安全性更高，配置得当，最多损失1秒的数据量
● 在不小心执行flushall命令，也可以通过AOF方式恢复(删除最后一个命令即可)
● AOF 日志是一个增量日志文件，不会存在断电时出现损坏问题。即使出现问题，redis-check-aof 工具也能够轻松修复它。
● 当 AOF 变得太大时，Redis 能够在后台自动重写 AOF

缺点
● 相同数据量来说，AOF文件体积通常大于RDB文件
● 数据持久化性能上来说，AOF 比 RDB 慢

RDB-AOF混合方式
混合持久化是结合了 RDB 和 AOF 的优点，在写入的时候，先把当前的数据以 RDB 的形式写入文件的开头，再将后续的操作命令以 AOF 的格式存入文件。即以 RDB 作为全量备份，AOF 作为增量备份，来提高备份效率。这样既能保证 Redis 重启时的速度，又能防止数据丢失的风险， 这就是 Redis 4.0 之后推出的 RDB-AOF 混合持久化模式，其作为默认配置来使用。

持久化机制选择

● 如果对数据安全性有非常高的要求，建议 RDB 和 AOF 同时启用。
● 如果对数据安全性要求不是很高，能够容忍数据的丢失，建议单独使用 RDB。
● 不推荐单独使用 AOF，因为对于进行数据库备份、更快重启以及 AOF 引擎中出现错误的情况来说，RDB 是更好的选择。
● 如果没特殊要求，Redis又是4.x版本以上，可以选择RDB-AOF混合方式。
如果不是混合模式，而是普通的RDB与AOF一起启动时，Redis加载数据执行流程 

 3.433 Redis内存淘汰机制

        引言
Redis 启动会加载一个配置：maxmemory <byte> //内存上限,默认值为 0 (window版的限制为100M)，表示默认设置Redis内存上限。但是真实开发还是需要提前评估key的体量，提前设置好
内容上限。此时思考一个问题，开发中，在设置完内存上限之后，如果Redis key达到上限了，该怎么办？这就设置到Redis的内存淘汰机制了。

内存淘汰算法

Redis内存淘汰机制也可以称之为key内卷机制，当资源不足时，该如何选择？常见的内存淘汰机制分为四大类 

       ● LRU：LRU是Least recently used，最近最少使用的意思，简单的理解就是从数据库中删除最近最少访问的数据，该算法认为，你长期不用的数据，那么被再次访问的概率也就很小了，淘汰的数据为最长时间没有被使用，仅与时间相关.

 ● LFU：LFU是Least Frequently Used，最不经常使用的意思，简单的理解就是淘汰一段时间内，使用次数最少的数据，这个与频次和时间相关。

● TTL：Redis中，有的数据是设置了过期时间的，而设置了过期时间的这部分数据，就是该算法要解决的对象。如果你快过期了，不好意思，我内存现在不够了，反正你也要退休了，提前送你一程，把你干掉吧。

Redis淘汰策略

Redis 通过配置

maxmemroy-policy

来配置指定具体的淘汰机制，可供选择的值有

通过maxmemroy-policy可以配置具体的淘汰机制，看了网上很多文章说只有6种，其实有8种，可以看Redis5.0的配置文件，
上面有说明：
● volatile-lru -> 找出已经设置过期时间的数据集，将最近最少使用（被访问到）的数据干掉。
● volatile-ttl -> 找出已经设置过期时间的数据集，将即将过期的数据干掉。
● volatile-random -> 找出已经设置过期时间的数据集，进行无差别攻击，随机干掉数据。
● volatile-lfu -> 找出已经设置过期时间的数据集，将一段时间内，使用次数最少的数据干掉。
● allkeys-lru ->与第1个差不多，数据集从设置过期时间数据变为全体数据。
● allkeys-lfu -> 与第4个差不多，数据集从设置过期时间数据变为全体数据。
● allkeys-random -> 与第3个差不多，数据集从设置过期时间数据变为全体数据。
● no-enviction -> 什么都不干，报错，告诉你内存不足，这样的好处是可以保证数据不丢失
系统默认选择： noenviction.

3.3.4 过期Key处理

        接下讨论一个问题：Redis的key过期了，该如何清理问题。
Redis给出3种实现方案：

惰性删除：当访问Key时，才去判断它是否过期，如果过期，直接干掉。这种方式对CPU很友好，但是一个key如果长期不用，一直存在内存里，会造成内存浪费。

定时删除：设置键的过期时间的同时，创建一个定时器，当到达过期时间点，立即执行对Key的删除操作，这种方式对CPU不友好，得额外让出CPU维护定时器。

定期删除：隔一段时间，对数据进行一次检查，删除里面的过期Key，至于要删除多少过期Key，检查多少数据，则由算法决定。Redis服务器实际使用的是惰性删除和定期删除两种策略：通过配合使用这两种删除策略，可以很好地在合理使用CPU和避免浪费内存之间取得平衡。

主要参考教程：

【Redis极简入门：纯小白成长为大白，只需4个半小时~】https://www.bilibili.com/video/BV15L411D7 yop=20&vd_source=0ddb24a02523448baa69b0b871ab50f7文章来源地址https://www.toymoban.com/news/detail-576611.html

到了这里，关于redis -速成的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！