Redis-介绍

NoSQL

简介

1. 关系型数据库：表与表之间建立关联关系
2. 非关系数据库：数据与数据之间没有关联关系

特点

1. 数据模型比较简单
2. 需要灵活性更强的IT系统
3. 对数据库性能要求较高
4. 不需要高度的数据一致性
5. 对于给定key，比较容易映射复杂值的环境

四大分类

1. 键值存储数据库：redis
2. 列存储数据库：HBase
3. 文档型数据库：MangoDb
4. 图形数据库：Neo4J

Redis与其他key-value区别

1. redis支持数据的持久化，可以将内存中的数据保存在磁盘中，重启时可以再次加载进行使用
2. Redis不仅仅支持简单的key-value类型的数据，同时还提供list，set，zset，hash等数据结构的存储
3. redis支持数据的备份，集群等高可用功能

Redis

基本

1. Redis：REmote DIctionary Server （远程字典服务器）
2. 内存存储和持久化：redis支持异步将内存中的数据写到硬盘上，同时不影响继续服务
3. 区最新N个数据的操作，如：可以将最新的10条评论的ID放在Redis的List集合里面
4. 模拟类似于HttpSession这种需要设定过期时间的功能
5. 发布、订阅消息系统
6. 定时器、计数器
7. 单进程
8. 默认16个数据库：配置文件中：database 16

特点

1. 性能极高
2. 丰富的数据类型
3. 原子性
4. 丰富的特性

Redis五大数据类型

String

1. String是redis最基本的类型，一个key对应一个value
2. String类型是二进制安全的。意思是redis的String可以包含任何数据。比如jps图片或者序列化的对象
3. String类型是Redis最基本的数据类型，一个redis中字符串value最多可以是512M

Hash

1. 哈希，类似java的Map<String,Object>
2. Redis hash是一个键值对集合
3. Redis hash是一个String类型的field和value的映射表，hash特别适合用于存储对象

List

1. 列表，底层实际是个链表
2. Redis列表是简单的字符串列表，按照插入顺序排序。可以添加一个元素到列表的头部（左边）或者尾部（右边）

Set

1. set（集合）
2. Redis的Set是String类型的无序集合。它是通过HashTable实现的

Zset

1. zset（sorted set：有序集合）
2. Redis zset 和 set一样也是String类型的集合，且不允许重复的成员
3. 不同的是每个元素都会关联一个double类型的分数（可理解为学生成绩）
4. redis正式通过分数来为集合中的成员进行从小到大的排序。zset的成员是唯一的，但分数却可以重复

Redis持久化-RDB（Redis DataBase）

基本

1. 在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它回复时将快找文件直接读到内存里
2. Redis会单独创建（fork）一个子进程来进行持久化，会将数据写入到一个临时文件中，待持久化过程都结束了，在用这个临时文件替换上次持久化好的文件
3. 整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能，如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失
4. flushall操作和shutdown操作会提交，即马上生成dump.rdb
5. 默认修改dump.rdb条件：
   • 1分钟改1万次
   • 5分钟改10次
   • 15分钟改1次

概念

1. Fork：Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和袁金成一只，但是是一个全新的进程，并作为原进程的子进程
2. dump.rdb：RDB保存的是dump.rdb文件

如何触发RDB快照

1. 配置文件中默认的快照配置（可以冷拷贝后重新使用，即复制到另一台机器）
2. 命令 save 或者 bgsave
   • 只管保存，其他不管全部阻塞
   • 后台异步进行快照操作
3. 执行flushall命令，也会产生dump.rdb，但里面是空的，无意义

如何恢复

1. 将备份文件移动到redis安装目录并启动服务即可
2. config get dir：获取目录

优势和劣势

1. 优势：适合大规模的数据恢复
2. 优势：对数据完整性和一致性要求高
3. 劣势：在一定间隔时间做一次备份，所以如果redis意外down掉的话，有可能丢失最后一次快照后的所有修改
4. 劣势：Fork的时候，内存中数据被克隆了一份，大致2倍的膨胀性需要考虑

图

Redis持久化-AOF（Append Only File）

基本

1. 以日志形式来记录每个写操作，将Redis执行过的所有写指令记录下来（读操作不记录）
2. 只允许追加文件但不可以改写文件
3. redis启动之初会读取该文件重新构建数据结构，即redis重启的话就根据日志文件的内容将指令从前到后执行一次以完成数据的恢复工作
4. 如果appendonly.aof和dump.rdb同时存在
   • 先加载aof

AOF启动/修复/恢复

1. 正常恢复
   • 启动：设置Yes，修改appendonly no，改为yes
   • 将有数据的aof文件复制一份保存到对应目录（config get dir）
   • 恢复：重启redis然后重新加载
2. 异常恢复
   • 启动，设置yes
   • 备份被写坏的AOF文件
   • 修复：Redis-check-aof --fix进行修复
   • 恢复：重启redis

Rewrite

基本

1. AOF采用文件追加方式，文件会越来越大，为了避免出现此种情况，新增了重写机制
2. 当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集
3. 可用命令bgrewriteaof

重写原理

1. AOF文件持续增大而过大时，会fork出一条新进程来将文件重写（也是先写临时文件最后再rename）
2. 遍历新进程的内存数据，每条记录有一条Set语句
3. 重写aof文件的操作并没有读取旧的aof，而是将整个内存中的数据库用命令的方式重写了一个新的aof，这点和快照有点类似

触发机制

1. Reids会记录上次重写时的AOF大小
2. 默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发

优势和劣势

1. 优势：
   • 每秒同步： appendfsync always 同步持久化，即每次变化都会更新
   • 每次修改同步：appendfsync everysec 异步操作，每秒记录
   • 不同步：appendfsync
2. 劣势：
   • 相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb
   • aof运行效率要慢于rdb，每秒同步策略效率较好，不同步效率和rdb相同

图

AOF和RDB

1. 只做缓存：如果希望只在服务器运行的时候存在，也可以不使用任何持久化方式
2. 同时开启两种持久化方式
   • 同时开启时，当redis重启的时候会优先载入aof文件（正常就不找rdb）来恢复原始的数据，因为在通常情况下aof文件保存的数据集要比rdb文件保存的数据集要完整
   • 建议不要只开启aof，因为RDB更适合用于备份数据库（AOF在不断变化不好备份），快速重启，而且不会有AOF可能潜在的bug，留着做万一的手段
3. 性能建议