Redis

关系数据库与非关系型数据库

●关系型数据库:

关系型数据库是一个结构化的数据库,创建在关系模型(二维表格模型)基础上,一般面向于记录。

SQL 语句(标准数据查询语言)就是一种基于关系型数据库的语言,用于执行对关系型数据库中数据的检索和操作。

主流的关系型数据库包括 Oracle、MySQL、SQL Server、Microsoft Access、DB2、PostgreSQL 等。

以上数据库在使用的时候必须先建库建表设计表结构,然后存储数据的时候按表结构去存,

如果数据与表结构不匹配就会存储失败。

●非关系型数据库

NoSQL(NoSQL = Not Only SQL ),意思是"不仅仅是 SQL",是非关系型数据库的总称。

除了主流的关系型数据库外的数据库,都认为是非关系型。

不需要预先建库建表定义数据存储表结构,每条记录可以有不同的数据类型和字段个数

(比如微信群聊里的文字、图片、视频、音乐等)。

主流的 NoSQL 数据库有 Redis、MongBD、Hbase、Memcached 等。

#关系型数据库和非关系型数据库区别:

(1)数据存储方式不同

关系型和非关系型数据库的主要差异是数据存储的方式。关系型数据天然就是表格式的,

因此存储在数据表的行和列中。数据表可以彼此关联协作存储,也很容易提取数据。

与其相反,非关系型数据不适合存储在数据表的行和列中,而是大块组合在一起。

非关系型数据通常存储在数据集中,就像文档、键值对或者图结构。

你的数据及其特性是选择数据存储和提取方式的首要影响因素。

(2)扩展方式不同

SQL和NoSQL数据库最大的差别可能是在扩展方式上,要支持日益增长的需求当然要扩展。

要支持更多并发量,SQL数据库是纵向扩展,也就是说提高处理能力,使用速度更快速的计算机,

这样处理相同的数据集就更快了。因为数据存储在关系表中,操作的性能瓶颈可能涉及很多个表,

这都需要通过提高计算机性能来克服。虽然SQL数据库有很大扩展空间,但最终肯定会达到纵向扩展的上限。

而NoSQL数据库是横向扩展的。因为非关系型数据存储天然就是分布式的,

NoSQL数据库的扩展可以通过给资源池添加更多普通的数据库服务器(节点)来分担负载。

3、对事务性的支持不同

如果数据操作需要高事务性或者复杂数据查询需要控制执行计划,

那么传统的SQL数据库从性能和稳定性方面考虑是你的最佳选择。

SQL数据库支持对事务原子性细粒度控制,并且易于回滚事务。

虽然NoSQL数据库也可以使用事务操作,但稳定性方面没法和关系型数据库比较,

所以它们真正闪亮的价值是在操作的扩展性和大数据量处理方面。

#非关系型数据库产生背景

可用于应对 Web2.0 纯动态网站类型的三高问题。

(1)High performance------对数据库高并发读写需求

(2)Huge Storage------对海量数据高效存储与访问需求

(3)High Scalability && High Availability------对数据库高可扩展性与高可用性需求

关系型数据库和非关系型数据库都有各自的特点与应用场景,

两者的紧密结合将会给Web2.0的数据库发展带来新的思路。

让关系数据库关注在关系上,非关系型数据库关注在存储上。

例如,在读写分离的MySQL数据库环境中,可以把经常访问的数据存储在非关系型数据库中,提升访问速度。

Mysql 高热数据------》redis

web---》redis---》mysql

CPU------》内存/缓存---》磁盘

总结

非关系数据库

1、数据保存在缓存中,利于读取速度/查询数据

2、架构中位置灵活

3、分布式、扩展性高

关系数据库

1、安全性高(持久化)

2、事务处理能力强

3、任务控制能力强

4、可以做日志备份、恢复、容灾的能力更强一点。

总结:

关系型数据库:

实例-->数据库-->表(table)-->记录行(row)、数据字段(column)------》存储数据

非关系型数据库:

实例-->数据库-->集合(collection)-->键值对(key-value)

非关系型数据库不需要手动建数据库和集合(表)。

缓存的概念:

缓存是一种用于存储临时数据副本的技术,目的是提高数据访问速度和性能。

缓存通常位于数据的访问路径上,可以在不直接访问原始数据源的情况下提供对数据的快速访问。

缓存数据: 缓存存储的是原始数据的副本。这可以是计算结果、数据库查询结果、文件内容等。

缓存命中: 当请求的数据在缓存中找到时,发生了缓存命中。这避免了对原始数据源的访问,提高了访问速度。

缓存未命中: 当请求的数据在缓存中未找到时,发生了缓存未命中。

系统将不得不从原始数据源中检索数据,然后将其存储在缓存中以供将来使用。

缓存淘汰: 当缓存空间不足时,系统需要决定哪些数据应该被淘汰以腾出空间。

这通常是基于一些策略,例如最近最少使用(LRU)或先进先出(FIFO)。

缓存策略: 缓存系统使用不同的策略来确定哪些数据应该被缓存、保留多长时间以及何时淘汰。

这包括淘汰策略(LRU、LFU)、缓存过期策略等。

缓存层次结构: 复杂系统中可能存在多个层次的缓存,从本地内存到分布式缓存,甚至是内容分发网络(CDN)。

缓存透明性: 缓存应该对应用程序透明,应用程序无需了解缓存的存在,缓存应该自动处理。

分布式缓存: 在分布式系统中,缓存通常以分布式方式部署,以支持大规模的应用程序。

缓存的使用可以显著提高系统性能,减轻原始数据源的负载,并降低数据访问延迟。

常见的缓存应用包括 Web 页面缓存、数据库查询缓存、对象缓存等。

介绍

Redis是一个开源、基于内存、使用C语言编写的key-value数据库,并提供了多种语言的API。它的数据结构十分丰富,主要可以用于数据库、缓存、分布式锁、消息队列等...

Redis服务器程序是单进程模型,也就是在一台服务器上可以同时启动多个Redis进程,Redis的实际处理速度则是完全依靠于主进程的执行效率。

若在服务器上只运行一个Redis进程,当多个客户端同时访问时,服务器的处理能力是会有一定程度的下降;

若在同一台服务器上开启多个Redis进程,Redis在提高并发处理能力的同时会给服务器的CPU造成很大压力。

五大数据类型

优缺点

(1)具有极高的数据读写速度: 数据读取的速度最高可达到110000 次/s,数据写入速度最高可达到81000次/s。

(2)支持的数据结构: key-value,支持丰富的数据类型:Strings、 Lists、Hashes、 Sets 及Sorted Sets 等数据类型操作。

(3)支持数据的持久化**:** 可以将内存中的数据保存在磁盘中,重启的时候可以再次加载进行使用。

(4)原子性**:** Redis所有操作都是原子性的。(支持事务,所有操作都作为事务)

(5)支持数据备份**:** 即 master-salve 模式的数据备份。(支持主从复制)

Redis缺点

  • 缓存和数据库双写一致性问题
  • 缓存雪崩问题
  • 缓存击穿问题
  • 缓存的并发竞争问题

Redis的适用场景

  • Redis作为基于内存运行的数据库,是一个高性能的缓存,一般应用在session缓存、 队列、排行榜、计数器、最近最热文章、最近最热评论、发布订阅等。
  • Redis适用于数据实时性要求高、数据存储有过期和淘汰特征的、不需要持久化或者只需要保证弱一致性、逻辑简单的场景。

Redis采用单线程的原因

首先要明确的是Redis单线程指的是网络IO和键值对读写是由一个线程来完成的,但Redis持久化、集群数据等是由额外的线程执行的。了解Redis使用单线程之前可以先了解一下多线程的开销。

通常情况下,使用多线程可以增加系统吞吐率或者可以增加系统扩展性,但多线程通常会存在同时访问某些共享资源,为了保证访问共享资源的正确性,就需要有额外的机制进行保证,这个机制首先会带来一定的开销。其实对于多线程并发访问的控制一直是一个难点问题,如果没有精细的设计,比如说,只是简单地采用一个粗粒度互斥锁,就会出现不理想的结果。即使增加了线程,大部分线程也在等待获取访问共享资源的互斥锁,并行变串行,系统吞吐率并没有随着线程的增加而增加。

redis运行速度快的原因

Redis是基于内存的,绝大部分请求都是内存操作,十分的迅速。

Redis具有高效的底层数据结构,为优化内存,对每种类型基本都有两种底层实现方式。

主要执行过程是单线程,避免了不必要的上下文切换和资源竞争,不存在多线程导致的CPU切换和锁的问题。

IO多路复用机制:使其在网络IO操作中能并发处理大量的客户端请求从而实现高吞吐率。

redis的安装配置

#关闭防火墙

systemctl stop firewalld

setenforce 0

#安装环境依赖包

yum install -y gcc gcc-c++ make

#上传软件包并解压

cd /opt/

tar zxvf redis-5.0.7.tar.gz -C /opt/

cd /opt/redis-5.0.7/

#开2核编译安装,指定安装路径为/usr/local/redis

make -j2 && make PREFIX=/usr/local/redis install

#由于Redis源码包中直接提供了Makefile 文件,所以在解压完软件包后,不用先执行./configure 进行配置,可直接执行make与make install命令进行安装。

#执行软件包提供的install_server.sh 脚本文件,设置Redis服务所需要的相关配置文件

cd /opt/redis-5.0.7/utils

./install_server.sh

.......#一直回车

Please select the redis executable path [] /usr/local/redis/bin/redis-server

#这里默认为/usr/local/bin/redis-server,需要手动修改为/usr/local/redis/bin/redis-server,注意要一次性正确输入

---------------------- 虚线内是注释 ----------------------------------------------------

Selected config:

Port: 6379 #默认侦听端口为6379

Config file: /etc/redis/6379.conf #配置文件路径

Log file: /var/log/redis_6379.log #日志文件路径

Data dir : /var/lib/redis/6379 #数据文件路径

Executable: /usr/local/redis/bin/redis-server #可执行文件路径

Cli Executable : /usr/local/bin/redis-cli #客户端命令工具


#当install_server.sh 脚本运行完毕,Redis 服务就已经启动,默认监听端口为6379

netstat -natp | grep redis

#把redis的可执行程序文件放入路径环境变量的目录中便于系统识别

ln -s /usr/local/redis/bin/* /usr/local/bin/

​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 #查看状态

#编辑配置文件,参数

vim /etc/redis/6379.conf

......

70 bind 127.0.0.1 192.168.73.105 #监听的IP地址,同时是一种指定远程登录的方式

93 port 6379 #监听端口

137 daemonize yes #使用守护进程的方式启动,即后台启动

159 pidfile /var/run/redis_6379.pid #Redis的进程号保存位置

172 logfile /var/log/redis_6379.log #日志保存的位置

187 databases 16 #监听库的数量(编号0-15)

/etc/init.d/redis_6379 restart #重启redis服务

redis的命令工具

redis-cli:Redis 命令行工具

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

-h:指定远程主机机

-p:指定Redis服务的端口号

-a:指定密码,未设置数据库密码可以省略-a选项

#-a选项若不添加任何选项表示使用127.0.0.1:6379连接本机上的Redis数据库

#登录本机

redis-cli

#远程登录

redis-cli -h 192.168.72.60 -p 6379 [-a 密码]

redis-benchmark 测试工具

基本的测试语法:redis-benchmark [选项] [选项值]

-h:指定服务器主机名。

-p:指定服务器端口。

-s:指定服务器 socket

-c:指定并发连接数。

-n:指定请求数。

-d:以字节的形式指定SET/GET值的数据大小。

-k:l=keep alive 0=reconnect

-r:SET/GET/INCR 使用随机key,SADD使用随机值

-P:通过管道传输<numreg>请求

-q:强制退出redis,仅显示query/sec值

--csv:以CSV格式输出

-l:生成循环,永久执行测试

-t:仅运行以逗号分隔的测试命令列表

-I:Idle模式,仅打开N个idle连接并等待

redis的简单操作

redis键值对的存取

set:存放数据,命令格式为 set key value

get:获取数据,命令格式为 get key

redis键值列表的获取

键值的设置:

192.168.73.105:6379> set v1 1

OK

192.168.73.105:6379> set v2 2

OK

192.168.73.105:6379> set v3 4

OK

192.168.73.105:6379> set k1 5

OK

192.168.73.105:6379> set k2 6

OK

192.168.73.105:6379> set k3 7

OK

192.168.73.105:6379> set k4 8

OK

获取全部列表

keys *

获取以某字符为开头任意长度的键

keys v*

keys k*

获取以某字符为开头,后面为指定长度的键

keys v?

keys v??

keys v???

keys v????

判断键是否存在

exists 键

#返回结果 为0 则为不存在,返回为1即为存在

删除键

del 键

查看键存储的数据类型

type 键

hash值创建:

192.168.233.7:6379> HSET ky32 guoqi tall

(integer) 1

192.168.233.7:6379> HGET ky32 guoqi

"tall"

192.168.233.7:6379> hset guoqi tall yes handson no

(integer) 2

192.168.233.7:6379> HGET guoqi tall

"yes"

192.168.233.7:6379> HMGET guoqi tall handson

  1. "yes"

  2. "no"

192.168.233.7:6379> HMSET guoqi cool yes

OK

192.168.233.7:6379> HMSET guoqi cool 23

OK

192.168.233.7:6379> HMGET guoqi tall handson cool

  1. "yes"

  2. "no"

  3. "23"

192.168.233.7:6379> HDEL guoqi handson

(integer) 1

192.168.233.7:6379> HMGET guoqi tall cool

  1. "cool"

  2. "sexy"

rename 重命名

  • 使用rename命令进行重命名时,无论目标key是否存在都会进行重命名,且源key的值会覆盖目标key的值。
  • 在实际使用过程中,建议先用exists命令查看目标key 是否存在,然后再决定是否执行rename 命令,以避免覆盖重要数据。

命令格式: rename 源key 目标key

renamenx 重命名

------会检查目标键名是否已存在

renamenx 命令的作用是对已有key进行重命名,并检测新名是否存在,如果目标key存在则不进行重命名。(不覆盖)

dbsize查看键数目

设置和清空密码

#设置redis的登录密码

config set requirepass password

#查看redis的密码

config get requirepass

#清空密码

config set requirepass ''

Redis多数据库操作

多数据库间切换select

命令格式:select 序号

#使用redis-cli连接Redis数据库后,默认使用的是序号为0的数据库。

127.0.0.1:6379>select 10 #切换至序号为10的数据库

127.0.0.1:6379[10]>select 15 #切换至序号为15的数据库

127.0.0.1:6379[15]>select 0 #切换至序号为0的数据库

127.0.0.1:6379[0]>

多数据库间移动数据

move 键值 序号(库的序号)

清除数据库内数据

FLUSHDB:清空当前数据库数据

FLUSHALL:清空所有数据库的数据,

redis的常见错误与解决方案

8.1 Redis常见运维故障

1 使用 keys* 把库堵死。------建议使用别名把这个命令改名。

2 超过内存使用后,部分数据被删除。------这个有删除策略的,选择适合自己的即可。

3 没开持久化,却重启了实例,数据全掉。------记得非缓存的信息需要打开持久化。

4 RDB的持久化需要 Vm.overcommit_memory=1 ,否则会持久化失败。

5 没有持久化情况下,主从,主重启太快,从还没认为主挂的情况下,从会清空自己的数据,人为重启主节点前,先关闭从节点的同步。

8.2 Redis故障排查

1 结合Redis 监控查看QPS、缓存命中率、内存使用率等信息。

2 确认机器层面的资源是否有异常。

3 故障时及时上机,使用 redis-cli monitor 打印出操作日志,然后分析(事后分析此条失效)。

4 和研发沟通,确认是否有大Key在堵塞(大Key也可以在日常的巡检中获得) 和组内同事沟通,确实是否有误操作。

5 和运维同事、研发一起排查流量是否正常,是否存在被刷的情况。

相关推荐
容器( ु⁎ᴗ_ᴗ⁎)ु.。oO15 分钟前
MySQL事务
数据库·mysql
cyt涛2 小时前
MyBatis 学习总结
数据库·sql·学习·mysql·mybatis·jdbc·lombok
Rookie也要加油2 小时前
01_SQLite
数据库·sqlite
liuxin334455663 小时前
教育技术革新:SpringBoot在线教育系统开发
数据库·spring boot·后端
看山还是山,看水还是。3 小时前
MySQL 管理
数据库·笔记·mysql·adb
fishmemory7sec3 小时前
Koa2项目实战2(路由管理、项目结构优化)
数据库·mongodb·koa
momo小菜pa4 小时前
【MySQL 09】表的内外连接
数据库·mysql
Jasonakeke4 小时前
【重学 MySQL】四十九、阿里 MySQL 命名规范及 MySQL8 DDL 的原子化
数据库·mysql
程序猿小D4 小时前
第二百六十九节 JPA教程 - JPA查询OrderBy两个属性示例
java·开发语言·数据库·windows·jpa
小宇成长录4 小时前
Mysql:数据库和表增删查改基本语句
数据库·mysql·数据库备份