关系型数据库
关系型数据库是一个结构化的数据库，创建在关系模型（二维表模型）基础上，一般面向于记录
SQL语句（标准数据查询语言）就是一种基于关系型数据库的语言，用于执行对关系型数据库中数据的检索和操作
主流的关系数据库包括Oracle、Mysql、SQL Server、Microsoft Access、DB2等
非关系型数据库
NoSQL(nOSQL=Not Only SQL)，意思是“不仅仅是SQL”，是非关系型数据库的总称。
除了主流的关系型数据库外的数据库，都认为是非关系型
主流的NoSQL数据库有Redis、MongBD、Hbase、CouhDB等
关系数据库与非关系型数据库区别
数据存储方式不同
关系型和非关系型数据库的主要差异是数据存储的方式
关系型数据天然就是表格式的，因此存储在数据表的行和列中
数据表可以彼此关联协作存储，也很容易提取数据
与其相反，非关系型数据不合适存储在数据表的行和列中，而是大块组合在一起。
非关系型数据通常存储在数据集中，就像文档、键值对或者图结构
Redis概述
Redis是一个开源的、使用c语言编写的NosQL数据库。
Redis基于内存运行并支持持久化(支持存储在磁盘)，采用key-value(键值对)的存储形式，是目前分布式架构中不可或缺的一环
Redis服务器程序默认是单进程模型
Redis服务在一台服务器上可以同时启动多个Redis进程，Redis的实际处理速度则是完全依靠于主进程的执行效率
开双进程的好处
备份
抗高并发的同时尽量不给CPU造成太大的压力
Redis的优点
具有极高的数据读写速度
数据读取的速度最高可达到110000 次/s，数据写入速度最高可达到81000 次/s
支持丰富的数据类型
支持key-value、 Strings、 Lists、Hashes ( 散列值)、Sets 及Ordered Sets等数据类型操作
支持数据的持久化
可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用
原子性
Redis所有操作都是原子性的：一起成功，一起失败
支持数据备份
即master-salve 模式的数据备份
常见应用场景
获取最新N个数据的操作
排行榜类应用
计数器应用
存储关系
实时分析系统
日志记录
redis
安装
修改配置文件
[root@localhost utils]# vim /etc/redis/6379.conf
bind 127.0.0.1 192.168.30.7 //添加监听IP
port 6379 //默认监听端口
daemonize yes //开启守护进程
pidfile /var/run/redis_6379.pid //指定PID文件
loglevel notice //指定日志级别
logfile /var/log/redis_6379.log //指定日志文件
重启服务器
测试性能
rename 重命名
使用rename命令进行重命名时，无论目标key是否存在都进行重命名，且源key的值会覆盖目标key的值。
在实际使用过程中，建议先用exists命令查看目标key是否存在，然后再决定是否执行rename命令，以避免覆盖重要数据
- renamenx 命令的作用是对已有key进行重命名，并检测新名是否存在，如果目标key存在则不进行重命名。（不覆盖）
命令格式：renamenx 源key 目标key - dbsize 命令的作用是查看当前数据库中key的数目
Redis 高可用
在web服务器中，高可用是指服务器可以正常访问的时间，衡量的标准是在多长时间内可以提供正常服务（99.9%、99.99%、99.999%等等）
但是在Redis语境中，高可用的含义似乎要宽泛一些，除了保证提供正常服务（如主从分离、快速容灾技术），还需要考虑数据容量的扩展、数据安全不会丢失等
在Redis中，实现高可用的技术主要包括持久化、主从复制、哨兵和集群，下面分别说明它们的作用，以及解决了什么样的问题
持久化
是最简单的高可用方法（有时甚至不被归为高可用的手段），只要作用是数据备份，即将数据存储在硬盘，保证数据不会因进程退出而丢失
主从复制：主从复制是高可用redis基础，哨兵和集群都是在主从复制基础上实现高可用的。主从复制主要实现了数据的多机备份，以及对于读操作的负载均衡和简单的故障恢复。缺陷：故障恢复无法自动化；写操作无法负载均衡；存储能力受到单机的限制
哨兵
在主从复制的基础上，哨兵实现了自动化的故障恢复。缺陷：写操作无法负载均衡；存储能力受到单机的限制
集群
通过集群，redis解决了写操作无法负载均衡，以及存储能力受到单机限制的问题，实现了较为完善的高可用方案
Redis 持久化
持久化的功能：redis是内存数据库，数据都是存储在内存中，为了避免服务器断电等原因导致redis进程异常退出后数据的永久丢失，需要定期将redis中的数据以某种形式（数据或命令）从内存保存到硬盘；当下次redis重启时，利用持久化文件实现数据恢复，除此之外，为了进行灾难备份，可以将持久化文件拷贝到一个远程位置
redis 提供两种方式进行持久化
ROB持久化：原理是将redis在内存中的数据库记录定时保存到硬盘上
AOF持久化（append only file）：原理是将redis的操作日志以追加的方式写入文件，类似于MySQL的binlog
八、ROB 持久化和AOF持久化
1、ROB持久化
ROB持久化是指在指定的时间间隔内将内存中当前进程中的数据生成快照保存到硬盘（因此也称作快照持久化），用二进制压缩存储，保存的文件后缀是rdb；当redis重新启动时，可以读取快照文件复数据
1.1 触发条件
RDB持久化的触发分为手动触发和自动触发两种
AOF 持久化
ROB持久化是将进程数据写入文件，而AOF持久化，则是将redis执行的每次写，删除命令记录到单独的日志文件中，查询操作不会记录；当redis重启时再次执行AOF文件中的命令来恢复数据。与RDB相比，AOF的实时性更好，因此已成为主流的持久化方案
[root@redis ~]# vim /etc/redis/6379.conf
700 appendonly yes
04 appendfilename "appendonly.aof"
796 aof-load-truncated yes /是否忽略最后一条可能存在问题的指令
[root@redis ~]# /etc/init.d/redis_6379 restart /重新启动AOF持久化
Stopping ...
Waiting for Redis to shutdown ...
Redis stopped
Starting Redis server...
自动触发
在自动触发ROB持久化时，redis也会选择bgsave而不是save来进行持久化
自动触发最常见的情况是在配置文件中通过save m n，指定当m秒内发生n次变化时，会触发bgsave
[root@redis ~]# vim /etc/redis/6379.conf /进入配置文件查看信息
219 save 900 1 /当900秒，如果redis数据发生了至少1次变化，执行bgsave
220 save 300 10 /当300秒时，如果redis数据发生了至少10次变化，执行bgsave
221 save 60 10000 /当60秒时，如果redis数据发生了至少10000次变化 执行bgsave
242 rdbcompression yes
254 dbfilename dump.rdb
264 dir /var/lib/redis/6379
手动触发
save命令和bgsave命令都可以生产RDB文件
save命令会阻塞redis服务器进程，直到RDB文件创建完毕为止，在Redis服务器阻塞期间，服务器不能处理任何命令请求
而bgsave命令会创建一个子进程，由子进程来负责创建RDB文件，父进程（即redis主进程）则继续处理请求
bgsave命令执行过程中，只有fork子进程时会阻塞服务器，而对于save命令，整个过程都会阻塞服务器，因此save已基本被废弃，线上环境要杜绝save的使用
RDB持久化
优点：RDB文件紧凑，体积小，网络传输快，适合全量复制；恢复速度比AOF快很多，当然，与AOF相比，RDB最重要的优点之一是对性能的影响相对较小
缺点：数据快照的持久化方式决定了必然做不到实时持久化，而数据越来越重要的今天，数据的流失是无法接受的，因此AOF持久化成为主流。此外，RDB文件需要特定格式，兼容性差。对于RDB持久化，一方面是bgsave在进行fork操作时redis主进程会阻塞，另一方面，子进程向硬盘写数据也会带来IO压力
AOF持久化
优点：支持秒级持久化、兼容性好，
缺点：文件大、恢复速度慢、对性能影响大
原文地址：https://blog.csdn.net/weixin_62453238/article/details/123137017
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。