Redis—从入门到入土

传统DB的缺点

像Mysql、和Oracle 这种关系型数据库，虽然有着数据稳定和服务稳定、数据一致性的特点，但也存在一个致命的缺陷:

高并发下DB不稳定

在高并发的情况下，DB的不稳定性，在大量用户访问时DB出奇的慢，因为对磁盘操作需要使用IO流，一个字节一个字节存取操作。要将所有数据读取到内存中后才可以操作。所以在高并发下DB的高可用便成了问题。这时NoSQL便应运而生。

什么是NOSQl

NoSQL是对不同于传统的关系数据库的数据库管理系统的统称。即非关系型数据库
NOSQL：因为是内存操作数据，非常快,解决了三高问题（高并发、高海量、高可用）

非关系型数据库与非关系型数据库的区别

关系型数据库	非关系型数据库
以文件方式保存	存储在内存中，服务器关闭数据可能会丢失
数据可以永久保存	不能持久化保存，可能导致数据丢失
查询速度慢	存取速度快

常见的NOSQL数据库

Redis

在这里插入图片描述
简单翻译下

Redis是一个开源(BSD许可)的内存数据结构存储，用作数据库、缓存和消息代理。它支持诸如字符串、散列、列表、集、带范围查询的排序集、位图、hyperloglogs、带半径查询和流的地理空间索引等数据结构。Redis具有内置的复制、Lua脚本、LRU清除、事务和不同级别的磁盘持久性，并通过Redis Sentinel和带有Redis集群的自动分区提供高可用性

redis的安装可以到官网下载，这里就不演示了。

Redis是一种高级的key:value存储系统，其中value支持五种数据类型

字符串（strings）
字符串无序集合（Set）
有序字符串集合（zset）
字符串列表（List）
-哈希类型（hash）

String类型

字符串类型是 Redis 中最为基础的数据存储类型，它在 Redis 中以二进制保存，没有编码和解码的过程，String字符串类型的Value数据长度512M

操作	作用
set key 值	添加字符串类型键和值
get key 值	取出指定类型的值，没有返回null
del key	删除指定的key 返回删除的个数没有返回0

Set类型

我们可以将 Set 类型看作为没有排序的字符集合

操作	作用
sadd key 值1、值2	向集合中添加一个或多个元素
smembers key	查询指定集合所有的元素
sismember key 值	查询某个值是否存在存在返回1、反则
srem key 值1、值2	删除指定元素

Zset类型

集合一样也是string类型元素的集合,且不允许重复的成员。
不同的是每个元素都会关联一个分数。redis正是通过分数来为集合中的成员进行从小到大的排序。有序集合的成员是唯一的,但分数(score)却可以重复，每个集合可存储40多亿个成员

操作	作用
zadd key 分数值	向集合添加一个或多个元素
zrang key 开始结束	返回集合中指定区间内的元素
zrem key 值	删除集合的一个元素或多个元素
zcard key	获取集合中的元素数
zrank key 值	返回集合中指定成员的索引

list类型

List 类型是按照插入顺序排序的字符串链表。和数据结构中的普通链表一样，我们可以在其左部(left)和右部(right)添加新的元素。

操作	作用
lpush key 元素1 元素2	往链表左边添加元素键不存在则创建新链表
rpush key 元素1 元素2	往链表右边添加元素键不存在则创建新链表
lrange key 开始结束	取出指定范围的元素列表左边数第一个为0 右边数第一个为-1
lpop key	从左边删除一个元素
rpop key	从右边删除一个元素
llen key	得到指定链表的长度

Hash类型

Redis 中的 Hash 类型可以看成具 String 的键和 String 的值 Map 容器，每一个 Hash 可以存储 40（42 亿 9千多个）亿个键值对。

操作	作用
hset key MapKey 值	向指定的key中添加 hasnMap类型
hget key MapKey	获取指定key中的指定HashMap
hmset key MapKey1 值 MapKey2 值	向一个键中设置多个Map和值
hmget key MapKey1 MapKey2	获取一个键中的多个Map
hdel key MapKey1 MapKey1	删除一个键中的多个Map
hgetall key	得到一个键中的所有Map

批量插入Map

删除Map

其他操作命令

操作	作用
keys 匹配字符	查询数据库的键（ * 为匹配全部字符）
del key1 key2	删除任意键
exists key	判断指定键是否存在
type key	判断该key 属于哪种类型
select 数据库编号	选择指定的数据库
move key 数据库编号	将某个键移动到另一个数据库
Expire key 秒	设置过期时间
TTL key	返回剩余生存时间

Redis数据库，Redis默认有16个数据库，我们可以通过Redis的一个图形化工具查看

设置过期时间（过期时为-2）

Redis持久化

Redis的最大特色就是持久化机制，当发生服务器宕机等不可预料因素时，Redis会将符合条件的数据进行持久化，在重启时恢复数据。RDB 和 AOF 是 Redis 内部的两种数据持久化策略，这是两种不同的持久化策略，一种是基于内存快照，一种是基于操作日志

RDB持久化策略（基于内存快照）

RDB(Redis DataBase)持久化策略就是在符合一定条件下将内存所有数据持久化到磁盘中dump.rdb文件中。RDB策略是redis默认持久化策略。也叫快照策略。

什么是快照策略，RDB持久化是指在某一段时间内将该内存下所有的数据存储为文件，当服务器丢失时，自动恢复到最新的一份RDB文件，简单点说就是相当于每隔一段时间就将Redis的文件
做一次备份，当然要满足一定的要求 RDB持久化是Redis默认的持久化机制

在安装完Redis的目录下有个config文件

在该文件下我们可以找到这样一段话

简单翻译一下就是

将DB保存到磁盘上:
在下面的例子中行为将保存DB
900秒后(15分钟)如果至少1键改变了
300秒(5分钟)如果至少10键改变
60秒后如果至少10000键改变

也就是说：
当数据在15分钟内改变了一个key，就会执行持久化机制
如果数据在5分钟内有10个key改变，就会执行持久化机制
如果数据在1分钟内有10000key改变，就会执行持久化机制

而我们持久化完的数据在哪里显示呢？
在该文件下面也有进行说明

简单翻译下

要将数据库转储到何处的文件名

于是我们就可以在Redis的安装目录下找到这个文件

关于RDB持久化机制

RDB的持久化机制，我们可以在配置文件中修改持久化时间，但一般不建议修改，因为在Redis达到一定数据量时，频繁的进行RDB的持久化机制便是一个非常浪费性能的事。RDB的持久机制
不高，便意味可能RDB持久化会导致丢失一定的数据。以快的持久化时间来说，相当于我们还是有60秒的空档期。而这可以靠另一个持久化机制来解决。

AOF持久化策略（基于操作日志）

AOF(append only file)策略，是基于操作日志实现的
它的特点持久化的频率非常高了，默认每秒持久化1次。每一秒内将最新的写入与删除的命令进行持久化。

AOF的持久化机制和RDB的持久化机制完全不同，AOF是基于日志文件操作的，简单点说就是RDB会将数据进行备份，而AOF备份的是操作 , 就是说，AOF将你所有的写入和删除操作进行备份，当服务器宕机时，可以通过备份的操作还原数据。

在配置文件中有这么一小段

简单翻译下

可以同时启用AOF和RDB持久性，没有问题。如果在启动时启用了AOF，那么Redis将加载AOF，即具有更好持久性保证的文件

开启AOF机制

AOF持久化选择

简单翻译下

默认设置是“每隔一秒”，因为这通常是正确的折衷
速度和数据安全。这取决于你是否能慢下来
“no”将允许操作系统在何时刷新输出缓冲区
为了更好的表现(但是如果你能接受一些数据丢失更多考虑的是快照的默认RDB持久性模式)，或者相反，使用“always”，虽然很慢，但是更安全。

这里指的是AOF提供持久化的频率
在这里插入图片描述
always：指每次修改都进行持久化操作，效率是最低的，但也是最安全的。
everysec：指每秒持久化一次，默认使用
no：指的是不进行持久化，效率最高

AOF的重写机制

当AOF开启时每秒的操作都会进行持久化，这样会导致日志文件的过大
于是AOF就有了重写机制，同样在配置文件下

简单翻译下

这个基本大小与当前大小进行比较。如果当前大小大于指定的百分比，将触发重写。您需要为要重写的AOF文件指定一个最小的大小

默认当日志文件大小超过内存数据100%时触发重写
当日志文件达到64M时也触发重写

关于AOF持久化机制

AOF策略的优点是显而易见的，每秒持久化，具有更高的数据安全，如果服务器崩溃只会丢1秒内的数据，但缺点也是一样明显：由于持久化频率高，Redis的性能会变低。

值得注意的是AOF和RDB同时开启，默认使用AOF恢复数据，
因为AOF是秒级以内的容错。

关于两者的选用

官方建议

通常，如果你要想提供很高的数据保障性，那么建议你同时使用两种持久化方式。
如果你可以接受灾难带来的几分钟的数据丢失，那么你可以仅使用RDB。很多用户仅使用了AOF，但是我们建议，既然RDB可以时不时的给数据做个完整的快照，并且提供更快的重启，所以最好还是也使用RDB。
因此，我们希望可以在未来（长远计划）统一AOF和RDB成一种持久化模式。