关系型数据库 vs 非关系型数据库

目录

[1. 关系型数据库（SQL）](#1. 关系型数据库（SQL）)

[2. 非关系型数据库（NoSQL）](#2. 非关系型数据库（NoSQL）)

[3.Redis 简介](#3.Redis 简介)

[4.Redis 安装与部署](#4.Redis 安装与部署)

4.1安装流程

[4.2 配置文件参数](#4.2 配置文件参数)

[5.Redis 命令工具](#5.Redis 命令工具)

[6.Redis 常用命令](#6.Redis 常用命令)

[7.Redis 高可用](#7.Redis 高可用)

[1. 持久化](#1. 持久化)

[2. 主从复制](#2. 主从复制)

[3. 哨兵（Sentinel）](#3. 哨兵（Sentinel）)

[4. Cluster 集群](#4. Cluster 集群)

8.持久化机制

[8.1RDB 持久化](#8.1RDB 持久化)

8.1.1RDB（快照）

[8.2 触发条件](#8.2 触发条件)

[8.2.1 手动触发](#8.2.1 手动触发)

[8.2.2 自动触发](#8.2.2 自动触发)

8.4启动时加载

---

1. 关系型数据库（SQL）

• 特点：

• 表格模型（行 + 列）
  • 使用 SQL 语言
  • 数据必须符合表结构
  • 强事务 ACID
  • 纵向扩展（升级硬件）
• **常见产品：**MySQL、Oracle、PostgreSQL
• 举例：
  • 银行转账：A 转账给 B，必须保证 A 扣钱成功的同时 B 收钱成功（事务保证一致性）。

2. 非关系型数据库（NoSQL）

• 特点：
  • 键值对 / 文档 / 图结构存储
  • 无需固定表结构
  • 高并发、高可扩展
  • 横向扩展（增加服务器节点）
• **常见产品：**Redis、MongoDB、HBase、Memcached
• 举例：

微信聊天：一条消息可能是文字、图片、语音，不适合用表格存储，更适合用文档型数据库。

3.Redis 简介

• **定义：**开源、C 语言编写、基于内存、支持持久化的键值数据库。
• 特性：
  • 高性能：读取可达 110000 次/s，写入 81000 次/s
  • 数据结构丰富：string、list、hash、sets、sorted sets
  • 支持持久化：数据可保存到磁盘
  • 原子性：单线程避免并发锁问题
  • 主从复制：数据备份
• 为什么快？
  • 1. 纯内存操作 → 避免磁盘 IO
  • 2. 单线程 → 避免锁开销
  • 3. I/O 多路复用 → 高并发
• 举例：
  • 秒杀活动：库存扣减、订单写入，放到 Redis 避免数据库压力。
  • 抖音热搜榜：用 sorted set 存储关键词 + 热度，实时排序。

注：在 Redis 6.0 中新增加的多线程也只是针对处理网络请求过程采用了多线性，而数据的读写命令，仍然是单线程处理的。

4.Redis 安装与部署

redis 下载地址：http://download.redis.io/releases/

4.1安装流程

4.2 配置文件参数

• bind 127.0.0.1 → 指定监听 IP
• port 6379 → 默认端口
• daemonize yes → 守护进程模式
• logfile /var/log/redis.log → 日志路径
• requirepass 123456 → 密码

举例：

Redis 就像一个仓库 → bind 是仓库大门只允许谁进，port 是大门编号，daemonize 表示仓库是否一直有人值守，requirepass 是仓库的锁。

5.Redis 命令工具

登录：

redis-cli -h host -p port -a password

• -h ：指定远程主机
• -p ：指定 Redis 服务的端口号
• -a ：指定密码，未设置数据库密码可以省略-a 选项
• 若不添加任何选项表示，则使用 127.0.0.1:6379 连接本机上的 Redis 数据库

6.Redis 常用命令

7.Redis 高可用

1. 持久化

• 持久化是最简单的高可用方法(有时甚至不被归为高可用的手段)，主要作用是数据备份，即将数据存储在硬盘，保证数据不会因进程退出而丢失。
• 保证断电后数据不丢失。

2. 主从复制

• 一主多从，主写从读。
• 案例：微博数据 → 主库负责写入热搜，从库负责提供用户查询，分担压力。

主从复制是高可用Redis的基础，哨兵和集群都是在主从复制基础上实现高可用的。主从复制主要实现了

数据的多机备份，以及对于读操作的负载均衡和简单的故障恢复。

缺陷：故障恢复无法自动化；写操作无法负载均衡；存储能力受到单机的限制。

3. 哨兵（Sentinel）

• 主机宕机，自动切换到从机。
• 案例：快递站点 A 停电，哨兵会自动切换到站点 B，业务不中断。

在主从复制的基础上，哨兵实现了自动化的故障恢复。缺陷：写操作无法负载均衡；存储能力受到单机的限制。

4. Cluster 集群

• 多节点分片存储，解决单机内存限制。
• 案例：淘宝商品太多，单机放不下，按分类拆分到不同 Redis 节点。

通过集群，Redis解决了写操作无法负载均衡，以及存储能力受到单机限制的问题，实现了较为完善的高可用方案。

8.持久化机制

8.1RDB 持久化

8.1.1RDB（快照）

• 定期把数据快照保存到磁盘。
• 优点：文件小，恢复快。
• 缺点：可能丢几分钟数据。
• 案例：手机云备份，每天定时备份一次照片。

8.2 触发条件

RDB持久化的触发分为手动触发和自动触发两种

8.2.1 手动触发

save命令和bgsave命令都可以生成RDB文件。

save命令会阻塞Redis服务器进程，直到RDB文件创建完毕为止，在Redis服务器阻塞期间，服务器不

能处理任何命令请求。

而bgsave命令会创建一个子进程，由子进程来负责创建RDB文件，父进程(即Redis主进程)则继续处理请求。

bgsave命令执行过程中，只有fork子进程时会阻塞服务器，而对于save命令，整个过程都会阻塞服务

器，因此save已基本被废弃，线上环境要杜绝save的使用。

8.2.2 自动触发

在自动触发RDB持久化时，Redis也会选择bgsave而不是save来进行持久化。

save m n

自动触发最常见的情况是在配置文件中通过save m n，指定当m秒内发生n次变化时，会触发bgsave。

1. Redis父进程首先判断：当前是否在执行save，或bgsave/bgrewriteaof的子进程，如果在执行则

bgsave命令直接返回。 bgsave/bgrewriteaof的子进程不能同时执行，主要是基于性能方面的考

虑：两个并发的子进程同时执行大量的磁盘写操作，可能引起严重的性能问题。

2. 父进程执行fork操作创建子进程，这个过程中父进程是阻塞的，Redis不能执行来自客户端的任何命令

3. 父进程fork后，bgsave命令返回"Background saving started"信息并不再阻塞父进程，并可以响应其他命令

4. 子进程创建RDB文件，根据父进程内存快照生成临时快照文件，完成后对原有文件进行原子替换

5. 子进程发送信号给父进程表示完成，父进程更新统计信息

8.4启动时加载

RDB文件的载入工作是在服务器启动时自动执行的，并没有专门的命令。但是由于AOF的优先级更

高，因此当AOF开启时，Redis会优先载入 AOF文件来恢复数据；只有当AOF关闭时，才会在Redis服务器启动时检测RDB文件，并自动载入。服务器载入RDB文件期间处于阻塞状态，直到载入完成为止。

Redis载入RDB文件时，会对RDB文件进行校验，如果文件损坏，则日志中会打印错误，Redis启动失败