一、关系数据库和非关系数据库
1. 关系数据库
一个结构化的数据库,创建在关系模型基础上
一般面向与记录
包括:Oracle、MySQL、SQL Server、Microsoft Access、DB2等
优点:
① 安全性高(持久化)
② 事务处理能力强
③ 任务控制能力强
④ 可以做日志备份、恢复、融资的能力更强一点
数据流向:
实例 ---> 数据库 ---> 表(table)---> 记录行(row)、数据字段(column)---> 存储数据
2. 非关系数据库
除了主流的关系型数据库外的数据库,都认为是非关系型数据库
包括:Redis、 MongBD、Hbase、CouhDB等
非关系型数据库产生背景
可用于应对web2.0纯动态网站类型的三高问题。
(1)High performance—对数据库高并发读写需求
(2)Huge storage——对海量数据高效存储与访问需求
(3)High Scalability && High Availability—对数据库高可扩展性与高可用性需求
优点:
关系型数据库和非关系型数据库都有各自的特点与应用场景,两者的紧密结合将会给web2.0的数据库发展带来新的思路。让关系数据库关注在关系上,非关系型数据库关注在存储上。例如,在读写分离的MysQL数据库环境中,可以把经常访问的数据存储在非关系型数据库中,提升访问速度。
① 数据库保存在缓存中,利于读取速度/查询数据
② 架构位置灵活
③ 分部署、扩展性高
数据流向:
实例 ---> 数据库 ---> 集合 ---> 键值对
注:非关系型数据库不需要手动建数据库和集合
3. 关系数据库与非关系数据库区别
(1)数据存储方式不同
关系型和非关系型数据库的主要差异是数据存储的方式。关系型数据天然就是表格式的,因此存储在数据表的行和列中。数据表可以彼此关联协作存储,也很容易提取数据。
与其相反,非关系型数据不适合存储在数据表的行和列中,而是大块组合在一起。非关系型数据通常存储在数据集中,就像文档、键值对或者图结构。你的数据及其特性是选择数据存储和提取方式的首要影响因素。
(2)扩展方式不同
SQL和NoSQL数据库最大的差别可能是在扩展方式上,要支持日益增长的需求当然要扩展。要支持更多并发量,SQL数据库是纵向扩展,也就是说提高处理能力,使用速度更快速的计算机,这样处理相同的数据集就更快了。因为数据存储在关系表中,操作的性能瓶颈可能涉及很多克服。虽然SQL数据库有很大扩展空间,但最终肯定会达到纵向扩展的上限个表,这都需要通过提高计算机性能来。
而NoSQL数据库是横向扩展的。因为非关系型数据存储天然就是分布式的,NoSgL数据库的扩展可以通过给资源池添加更多普通的数据库服务器(节点)来分担负载。
关系:纵向比如说硬件中添加内存
非关:横向天然分布式
(3)对事务性的支持不同
如果计数据操作需要高事务性或者复杂数据查询需要控制执行划,那么传统的SQL数据库从性能和稳定性方面考虑是你的最佳选择。SQL数据库支持对事务原子性细粒度控制,并且易于回滚事务。
虽然NoSQL数据库也可以使用事务操作,但稳定性方面没法和关系型数据库比较,所以它们真正闪亮的价值是在操作的扩展性和大数据量处理方面。
区别 | 关系型数据库(MySQL)-SQL数据库 | 非关系型数据库(redis、 MongoDB)-NoSQL数据库 |
---|---|---|
存储方式不同(主要差异) | 二维表格式 | 存储在数据集中,就像文档、键值对或者图结构 |
扩展方式不同(最大的差别) | 纵向扩展,扩展CPU等性能磁盘空间 | 横向扩展,非关系型数据存储天然就是分布式的 |
对事物的支持不同 | 支持对事务原子性细粒度控制,并且易于回滚事务 | 稳定性方面没法和关系型数据库比较 |
应用场景 | 特别适合高事务性要求和需要控制执行计划的任务 | 此处会稍显弱势,其价值点在于高扩展性和大数据量处理方面 |
4. 了解 redis
Redis基于内存运行并支持持久化
采用key-value(键值对)的存储形式
Redis服务器程序是单进程模型,也就是在一台服务器上可以同时启动多个Redis进程,Redis的实际处理速度则是完全依靠于主进程的执行效率。若在服务器上只运行一个Redis进程,当多个客户端同时访问时,服务器的处理能力是会有一定程度的下降;若在同一台服务器上开启多个Redis进程,Redis在提高并发处理能力的同时会给服务器的CPU造成很大压力。即:在实际生产环境中,需要根据实际的需求来决定开启多少个Redis进程。若对高并发要求更高一些,可能会考虑在同一台服务器上开启多个进程。若CPU资源比较紧张,采用单进程即可。
5. redis 优点
(1)具有极高的数据读写速度
数据读取的速度最高可达到 110000次/s,数据写入速度最高可达到 81000次/s。
(2)支持丰富的数据类型
支持 key-value、strings、Lists、Hashes、Sets 及 Sorted Sets等数据类型操作。
(3)支持数据的持久化
可以将内存中的数据保存在磁盘中,重启的时候可以再次加载进行使用。
(4)原子性
Redis 所有操作都是原子性的。
(5)支持数据备份
即master-salve模式的数据备份。
Redis作为基于内存运行的数据库,缓存是其最常应用的场景之一。除此之外,Redis常见应用场景还包括获取最新N个数据的操作、排行榜类应用、计数器应用、存储关系、实时分析系统、日志记录。
6. redis 为什么这么快
(1)Redis是一款纯内存结构,避免了磁盘I/O等耗时操作。
(2)Redis命令处理的核心模块为单线程,减少了锁竞争,以及频繁创建线程和销毁线程的代价,减少了线程上下文切换的消耗。
(3)采用了I/O多路复用机制,大大提升了并发效率。
注:在 Redis 6.0 中新增加的多线程也只是针对处理网络请求过程采用了多线性,而数据的读写命令,仍然是单线程处理的。
二、Redis安装部署
1. 下载Redis安装包
cd /opt
ls
2. 安装Redis编译安装环境
yum -y install gcc gcc-c++ make
3. 解压 Redis 安装包
tar zxf /opt/redis-5.0.7.tar.gz -C /opt
4. 编译及安装
cd /opt/redis-5.0.7
make -j 4 && make prefix=/usr/local/redis install
5. 设置Redis服务所需要的相关配置文件
cd /opt/redis-5.0.7/utils
./install_server.sh
# 一直回车,在Please select the redis executable path时设置选择的 Redis 可执行文件路径是
/usr/local/redis/bin/redis-server
6. 配置Redis的可执行命令的环境变量
ln -s /usr/local/redis/bin/* /usr/local/bin
7. Redis 服务控制
# 当install_server.sh 脚本运行完毕,Redis 服务就已经启动,默认侦听端口为6379
netstat -natp | grep redis
# Redis服务控制
# 停止
/etc/init.d/redis_6379 stop
# 启动
/etc/init.d/redis_6379 start
# 重启
/etc/init.d/redis_6379 restart
# 状态
/etc/init.d/redis_6379 status
8. 修改配置 /etc/redis/6379.conf 参数
vim /etc/redis/6379.conf
# 70行,添加监听的主机地址
bind 127.0.0.1 192.168.23.50
# 93行,Redis默认的监听端口
port 6379
# 137行,启用守护进程
daemonize yes
# 159行,指定PID文件
pidfile /var/run/redis_6379.pid
# 167行,日志级别
loglevel notice
# 172行,指定日志文件
logfile /var/log/redis_6379.log
:wq!
# 修改配置文件之后要重启服务
/etc/init.d/redis_6379 restart
三、Redis数据库常用命令
工具 | 作用 |
---|---|
redis-server | 用于启动Redis 的工具 |
redis-benchmark | 用于检测Redis在本机的运行效率 |
redis-cli | Redis 命令行工具(远程登录) |
redis-check-aof | 修复AOF持久化文件 |
redis-check-rdb | 修复RDB持久化文件 |
1. 启动redis服务
redis-server
2. 检测Redis本机在本机的运行效率
redis-benchmark是官方自带的 Redis性能测试工具,可以有效的测试Redis服务的性能。基本的测试语法: redis-benchmark [选项] [选项值]
-h:指定服务器主机名。
-p:指定服务器端口。
-s:指定服务器socket
-c:指定并发连接数。
-n:指定请求数。
-d:以宁节的形式指定SET/GET值的数据大小。
-k:1=keep alive 0=reconnect 。
-r:SET/GET/INCR使用随机key,SADD使用随机值。
-P:通过管道传输<numreq>请求。
-q:强制退出redise_仅显示query/sec值。
--csv:以csv 格式输出。
-l:生成循环,永久执行测试。
-t:仅运行以逗号分隔的测试命令列表。
-I:Idle 模式。仅打开N个idle 连接并等待。
实例:
向IP地址为 192.168.10.23、端口为 6379的 Redis服务器发送100个并发连接与 10000个请求测试性能
redis-benchmark -h 192.168.23.50 -p 6379 -c 100 -n 100000
执行了 MSET 命令设置了 10 个键值对的情况:
- 完成了 100,000 个请求,共耗时 0.61 秒。
- 使用了 100 个并发客户端进行操作。
- 每个键值对的值大小为 3 字节。
- 设置保持活跃状态(keep alive)的时间为 1 秒。
具体的性能指标如下:
- 97.36% 的请求的响应时间在 1 毫秒以内。
- 99.99% 的请求的响应时间在 2 毫秒以内。
- 100.00% 的请求的响应时间在 2 毫秒以内。
- 平均每秒处理了约 162,866.44 个请求。
这些结果表明,在给定的条件下,Redis 服务器能够以很高的速度处理 MSET 命令请求。大部分请求的响应时间非常低,小于等于 2 毫秒。平均每秒处理了约 162,866.44 个请求,说明 Redis 具有快速的处理能力。
3. redis-cli 命令行工具
语法: redis-cli -h host -p port -a password
-h:指定远程主机
-p:指定Redis 服务的端口号
-a:指定密码,未设置数据库密码可以省略-a选项
若不添加任何选项表示,则使用127.0.0.1:6379连接本机上的 Redis 数据库
redis-cli -h 192.168.23.50 -p 6379
Redis数据库常用命令
命令 | 作用 |
---|---|
set 键 值 | 存放数据 |
get 键 | 获取数据 |
renamenx 旧键名 新键名 | 对已有 旧key 进行重命名,并检测新名是否存在,如果目标 新key 存在则不进行重命名。(不覆盖) |
exists 键 | 查看键、键值是否存在 |
dbsize | 查看键的个数 |
config set requirepass 密码 | 设置密码 |
config get requirepass | 查看密码 |
select 序号 | 多数据库间切换 |
* | 表示所有 |
? | 表示任意单个字符 |
move 键 序号 | 多数据库间移动数据,将当前的库的键移到序号库 |
flushdb | 清空当前数据库数据 |
flushall | 清空所有数据库的数据,慎用! |
四、Redis持久化
持久化是最简单的高可用方法(有时甚至不被归为高可用的手段),主要作用是数据备份,即将数据存储在硬盘保证数据不会因进程退出而丢失。
Redis提供两种方式进行持久化
1. RDB持久化
原理是将 Reids在内存中的数据库记录定时保存到磁盘上。
RDB持久化是指在指定的时间间隔内将内存中当前进程中的数据生成快照保存到硬盘(因此也称作快照持久化) ,[用二进制压缩存储,保存的文件后缀是rdb;当Redis重新启动时,可以读取快照文件恢复数据
(1)触发条件
RDB持久化的触发分为手动触发和自动触发两种。
① 手动触发
save命令和bgsave命令都可以生成RDB文件。
save命令会阻塞Redis服务器进程,直到RDB文件创建完毕为止,在Redis服务器阻塞期间,服务器不能处理任何命令请求。而bgsave命令会创建一个子进程,由子进程来负责创建RDB文件,父进程(即Redis主进程)则继续处理请求。
bgsave命令执行过程中,只有fork子进程时会阻塞服务器,而对于save命令,整个过程都会阻塞服务器,因此save已基本被废弃,线上环境要杜绝save的使用。
② 自动触发
在自动触发RDB持久化时,Redis也会选择bgsave而不是save,来进行持久化。
save m n
自动触发最常见的情况是在配置文件中通过save m n,指定当m秒内发生n次变化时,会触发bgsave。
③ 其他自动触发机制
除了save m n 以外,还有一些其他情况会触发bgsave
在主从复制场景下,如果从节点执行全量复制操作,则主节点会执行bgsave命令,并将rdb文件发送给从节点。
执行shutdown命令时,自动执行rdb持久化。
(2)执行流程
Fedis父进程首先判断当前是否在执行save,或bgsave/bgrewriteaof 的子进程,如果在执行则bgsave命令直接返回。
bgsave/bgrewriteaof 的子进程不能同时执行,主要是基于性能方面的考虑,两个并发的子进程同时执行大量的磁盘写操作,可能引起严重的性能问题。
父进程执行fork操作创建子进程,这个过程中父进程是阻塞的,Redis不能执行来自客户端的任何命令
父进程fork后,bgsave命令返回"Background saving started”信息并不再阻塞父进程,并可以响应其他命令
子进程创建RDB文件,根据父进程内存快照生成临时快照文件,完成后对原有文件进行原子替换
子进程发送信号给父进程表示完成,父进程更新统计信息
(3)启动时加载
RDB文件的载入工作是在服务器启动时自动执行的,并没有专门的命令。但是由于AOF的优先级更高,因此当ROF开启时,Redis会优先载入,AOF文件来恢复数据;只有当AOF关闭时,才会在Redis服务器启动时检测RDB文件,并自动载入。服务器载入RDB文件期间处于阻塞状态,直到载入完成为止。
Redis载入RDB文件时,会对RDB文件进行校验,如果文件损坏,则日志中会打印错误,Redis启动失败。
AOF持久化 ( append only file):原理是将Reids 的操作日志以追加的方式写入文件,类似于MySQL的binlog
由于AOF持久化的实时性更好,即当进程意外退出时丢失的数据更少,因此AOF是目前主流的持久化方式,不过RDB持久化仍然有其用武之地。
优缺点:
缺点:
1、数据完整性不如aof
2、rdb类似快照(充备)
3、在进行备份时,会阻塞进程
优势
1、持久化速度快(因为保存的数据结果),在写入到* .rdb持久化文件会进行压缩,来减小自身的体积
2、集群中,redis主从复制,从主服务器进行同步,默认先使用RDB文件进行恢复操作,所有,同步性能较高
主从复制
主从复制是高可用Redis的基础,哨兵和集群都是在主从复制基础上实现高可用的。主从复制主要实现了数据的多机备份,以及对于读操作的负载均衡和简单的故障恢复。
缺陷:故障恢复无法自动化;写操作无法负载均衡;存储f万受到单机的限制。
哨兵
在主从复制的基础上,哨兵实现了自动化的故障恢复。
缺陷:写操作无法负载均衡;存储能力受到单机的限制。
Cluster集群
通过集群,Redis解决了写操作无法负载均衡,以及存储能力受到单机限制的问题,实现了较为完善的高可用方案。
redis 优化
雪崩
穿透