目录
一,了解什么是Redis
1,核心特点
2,关系性与非关系型数据库
3,非关系型数据库的产生背景
4,非关系型数据库的应用场景都有哪些
5,Reids简介
二,安装并使用Redis
1,redis的配置参数
2,redis命令工具
3,Redis的基本操作
三,redis多数据库操作
1,多数据库间切换
2,多数据库间移动数据
3,数据库中清空数据
四, Redis持久化
1,RDB持久化
2,AOF持久化
3,AOF重写
4,配置持久化
一,了解什么是Redis
Redis(Remote Dictionary Server) 是一个基于内存的数据存储系统,常被用作数据库、缓存和消息中间件。它支持多种数据结构(如字符串、哈希、列表、集合、有序集合等),并提供高读写性能、持久化、主从复制、集群等功能,广泛应用于互联网应用中。
1,核心特点
-
基于内存,性能高效
- 数据存储在内存中,读写速度极快(官方称读操作可达 11 万次 / 秒,写操作可达 8 万次 / 秒),适合高并发场景。
- 支持数据持久化(RDB 和 AOF 两种方式),可将内存数据定期写入磁盘,避免数据丢失。
-
丰富的数据结构
- 字符串(String):存储简单的键值对,如缓存用户信息。
- 哈希(Hash):存储对象数据(如用户详情),类似 JSON 结构。
- 列表(List):有序可重复的列表,可用于消息队列(如任务排队)。
- 集合(Set):无序唯一的集合,可用于去重(如统计用户在线状态)。
- 有序集合(Sorted Set):带分数的有序集合,可用于排行榜(如点赞排名)。
- 其他:位图(BitMap)、HyperLogLog(用于基数统计)等。
-
原子性操作与丰富命令
- 所有操作都是原子性的,保证数据一致性。
- 提供丰富的命令(如
SET
、GET
、HSET
、LPUSH
、ZADD
等),方便处理不同数据结构。
-
高可用与分布式支持
- 主从复制(Master-Slave):主节点数据自动同步到从节点,实现读写分离和容灾备份。
- 集群(Cluster):通过分片(Sharding)将数据分布到多个节点,支持水平扩展,提升存储容量和吞吐量。
-
多语言支持
- 提供 Python、Java、Go、PHP 等多种编程语言的客户端库,集成简单便捷。
2,关系性与非关系型数据库
数据库按照数据库的结构可以分为关系型数据库与其他数据库,而这些其他数据库我们将其统称为非关系型数据库。
- 关系型数据库
关系型数据库是一个结构化的数据库,创建在关系模型基础上,一般面向于记录。它借助于集合代数等数学概念和方法来处理数据库中的数据。关系模型就是指二维表格模型,因而一个关系型数据库就是由二维表及其之间的联系组成的一个数据组织。现实世界中,各种实体与实体之间的各种联系都可以用关系模型来表示。SQL语句(标准数据查询语言)就是一种基于关系型数据库的语言,用于执行对关系型数据库中数据的检索和操作。
主流的关系型数据库包括 0racle、MySQL、SQL Server、Microsoft Access、DB2 等
- 非关系型数据库
NoSQL(NoSQL = Not 0nly SQL),意思是“不仅仅是 SQL”,是非关系型数据库的总称。主流的 NoSQL 数据库有 Redis、MongBD、Hbase、CouhDB 等等。以上这些非关系型数据库,他们的存储方式、存储结构以及使用的场景都是完全不同的。所以我们认为它是一个非关系型数据库的集合,而不是像关系型数据库一样,是一个统称。换言之,除了主流的关系型数据库以外的数据库,都可以认为是非关系型的。NoSQL 数据库凭借着其非关系型、分布式、开源及横向扩展等优势,被认为是下一代数据库产品。
3,非关系型数据库的产生背景
- High performance——对数据库高并发读写需求:Web2.0 网站会根据用户的个性化信息来实时生成动态页面和提供动态信息,因此无法使用动态页面静态化技术。所以数据库的并发负载非常高,一般会达到10000 次/s以上的读写请求。关系型数据库对于上万次的查询请求还是可以勉强支撑的,但出现上万次的写数据请求,硬盘 I0 就已经无法承受了。对于普通的 BBS 网站,往往也会存在高并发的写数据请求。
- Huge Storage——对海量数据高效存储与访问需求:类似于 Facebook、Friendfeed 这样的 SNS 网站,每天会产生大量的用户动态信息。如 Friendfeed,一个月就会产生不少于 2.5 亿条用户动态信息,对于关系型数据库来说,在一个包含 2.5 亿条记录的表中执行 SQL 查询,查询效率是非常低的。
- High Scalability && High Availability——对数据库高可扩展性与高可用性:需求在 Web 架构中,数据库是最难进行横向扩展的。当应用系统的用户量与访问量与日俱增时,数据库是没办法像 Web 服务一样,简单地通过添加硬件和服务器节点来扩展其性能和负载能力的。尤其对于一些需要 24 小时对外提供服务的网站来说,数据库的升级与扩展往往伴随着停机维护与数据迁移,其工作量是非常庞大的。
4,非关系型数据库的应用场景都有哪些
-
高并发读写与缓存场景:需要处理海量并发请求,数据读取频率远高于写入,且对响应延迟敏感。
-
海量非结构化 / 半结构化数据存储:数据格式灵活(如 JSON、XML),字段不固定,需频繁变更结构。
-
复杂关系网络与关联查询:数据间关系复杂(如社交网络、供应链),需高效处理多跳关联查询。
-
实时数据处理与流计算:数据实时产生(如日志、消息队列),需低延迟写入和实时分析。
-
分布式与高可用系统:数据需跨节点分布,支持水平扩展和多数据中心容灾。
-
离线大数据与批处理:处理 TB/PB 级历史数据,需与 Hadoop、Spark 等大数据框架集成。
5,Reids简介
Redis(RemoteDictionaryServer,远程字典型)是一个开源的、使用C语言编写的 NoSQL 数据库。Redis 基于内存运行并支持持久化,采用 key-value(键值对)的存储形式,是目前分布式架构中不可或缺的一环。
Redis 服务器程序是单进程模型,也就是在一台服务器上可以同时启动多个Redis进程,而 Redis 的实际处理速度则是完全依靠于主进程的执行效率。若在服务器上只运行一个 Redis 进程,当多个客户端同时访问时,服务器的处理能力是会有一定程度的下降;若在同一台服务器上开启多个 Redis 进程,Redis在提高并发处理能力的同时会给服务器的CPU造成很大压力。即:在实际生产环境中,需要根据实际的需求来决定开启多少个Redis 进程。若对高并发要求更高一些,可能会考虑在同一台服务器上开启多个进程。若CPU 资源比较紧张,采用单进程即可。
- Redis具有以下几个优点
- 具有极高的数据读写速度,数据读取的速度最高可达到 110000 次/s,数据写入速度最高可达到 81000 次/s。
- 支持丰富的数据类型,不仅仅支持简单的 key-value 类型的数据,还支持Strings,Lists,Hashes,Sets 及 0rdered Sets 等数据类型操作。
- 支持数据的持久化,可以将内存中的数据保存在磁盘中,重启的时候可以再次加载进行使用。
- 原子性,一个具有原子性的操作,要么完整执行成功,要么完全不执行,不存在中间状态,也不会被其他操作干扰。
- 支持数据备份,即 master-salve 模式的数据备份。
二,安装并使用Redis
[root@localhost src]# ls
debug kernels redis-4.0.9.tar.gz
[root@localhost src]# tar zxvf redis-4.0.9.tar.gz [root@localhost redis-4.0.9]# cd redis-4.0.9/[root@localhost redis-4.0.9]# make PREFIX=/usr/local/redis install
PREFIX ##指定redis安装目录[root@localhost redis-4.0.9]# ln -s /usr/local/redis/bin/* /usr/local/bin[root@localhost redis-4.0.9]# ls
00-RELEASENOTES COPYING Makefile redis.conf runtest-sentinel tests
BUGS deps MANIFESTO runtest sentinel.conf utils
CONTRIBUTING INSTALL README.md runtest-cluster src
通常情况下,在 Linux 系统中进行源码编译安装,需要先执行./configure进行环境检查与配置,从而生成 Makefile 文件,再执行 make && make instal1命令进行编译安装。而 Redis 源码包中直接提供了 Makefile 文件,所以在解压完软件包后,可直接进入解压后的软件包目录,执行make与 make install命令进行安装。
##切换到utils目录下,设置redis服所需要的相关配置文件
[root@localhost ~]# cd redis-4.0.9/utils/
[root@localhost utils]# ./install_server.sh
##配置文件路径,保持默认即可
Please select the redis config file name [/etc/redis/6379.conf] ##日志路径,保持默认即可
Please select the redis log file name [/var/log/redis_6379.log] ##数据文件路径
Please select the data directory for this instance [/var/lib/redis/6379] ##可执行文件路径
Please select the redis executable path [/usr/local/bin/redis-server] ##确定配置
Selected config:
Port : 6379
Config file : /etc/redis/6379.conf
Log file : /var/log/redis_6379.log
Data dir : /var/lib/redis/6379
Executable : /usr/local/bin/redis-server
Cli Executable : /usr/local/bin/redis-cli ##客户端命令行工具
Is this ok? Then press ENTER to go on or Ctrl-C to abort. ##按回车配置完成[root@localhost utils]# /etc/init.d/redis_6379 stop ##redis关机命令
Stopping ...
Redis stopped
[root@localhost utils]# /etc/init.d/redis_6379 start ##redis启动命令
Starting Redis server... ##查看监听的端口
[root@localhost utils]# netstat -anpt |grep redis
tcp 0 0 127.0.0.1:6379 0.0.0.0:* LISTEN 8439/redis-server 1
1,redis的配置参数
[root@localhost utils]# vin /etc/redis/6379.conf ##redian配置文件位置
bind 127.0.0.1 ##监听的主机地址
port 6379 ##端口
daemonize yes ##启动守护进程
pdifile /var/run/redis_6379.pid ##指定pid文件
loglevel notice ##日志级别
logfile /var/log/redis_6379.log ##指定日志文件
2,redis命令工具
redis-server:用于启动 Redis 的工具
redis-benchmark:用于检测 Redis 在本机的运行效率
redis-check-aof:修复 AOF 持久化文件
redis-check-rdb:修复 RDB 持久化文件
redis-cli:Redis 命令行工具。
[root@localhost ~]# redis-cli ##进入到redis数据库127.0.0.1:6379> ping ##检查redis服务是否启动
PONG
3,Redis的基本操作
- keys
127.0.0.1:6379[1]> set k1 1
OK
127.0.0.1:6379[1]> set k2 2
OK
127.0.0.1:6379[1]> set k3 3
OK127.0.0.1:6379[1]> keys * ##可以查看当前数据库中所有的数据
1) "k3"
2) "k2"
3) "k1"127.0.0.1:6379[1]> keys v* ##查询以v开头的所有内容
(empty list or set)127.0.0.1:6379[1]> keys v? ##查询v开头后面包含任意一位的数据
(empty list or set)127.0.0.1:6379[1]> keys v?? ##查询v开头后面包含任意两位的数据
- exists
127.0.0.1:6379[1]> exists k1 ##查看键值是否存在,为1吧表示存在,为0表示不存在
(integer) 1127.0.0.1:6379[1]> exists v1
(integer) 0
- rename
rename 命令是对已有 key 进行重命名,其命令格式为:rename 源 key 目标key。使 用 rename 命令进行重命名时,无论目标 key 是否存在都进行重命名,且源 key 的值会覆盖目标 key 的值。在实际使用过程中,建议先用 exists 命令查看目标 key 是否存在,然后再决定是否执行rename命令,以避免覆盖重要数据。
##使用rename,如果新名字存在的话则直接覆盖
127.0.0.1:6379[1]> keys *
1) "k2"
2) "k1"
127.0.0.1:6379[1]> rename k1 k2
OK
127.0.0.1:6379[1]> keys *
1) "k2"
- renamenx
renamenx 命令的作用是对已有 key 进行重命名,并检测新名是否存在。其命令格式与 rename 的命令格式除命令关键字不同外基本相同:renamenx 源 key 目标 key。使用 renamenx 命令进行重命名时,如果目标 key 存在则不进行重命名。
127.0.0.1:6379[1]> set k1 1
OK
127.0.0.1:6379[1]> set k2 2
OK
127.0.0.1:6379[1]> get k1
"1"
127.0.0.1:6379[1]> get k2
"2"
127.0.0.1:6379[1]> renamenx k1 k2 ##如果新名字存在的话,则不进行重命名
(integer) 0
- dbsize
##可以查看当前数据库的key数目
127.0.0.1:6379[1]> dbsize
(integer) 1
- del
##del可以删除已存在的键值
127.0.0.1:6379[1]> del k2
(integer) 1
127.0.0.1:6379[1]> keys *
(empty list or set)
三,redis多数据库操作
1,多数据库间切换
Redis支持多数据库,Redis在没有任何改动的情况下默认包合16个数据库,数据库名称是用数字 0-15来依次命名的。使用 select 命令可以进行Redis 的多数据库之间的切换,命令格式为 selectindex,其中 index 表示数据库的序号。而使用 redis-cli 连接 Redis 数据库后,默认使用的是序号为0的数据库。
127.0.0.1:6379> select 10 ##select切换库,后面指定序号0—16
OK
2,多数据库间移动数据
Redis 的多数据库在一定程度上是相对独立的,例如在数据库0上面存放k1 的数据,在其它 1-15 的数据库上是无法查看到的。
127.0.0.1:6379[1]> set k1 1
OK
127.0.0.1:6379[1]> keys *
1) "k1"127.0.0.1:6379[1]> move k1 2 ##将数据库1的k1移动到数据库2中
(integer) 1
127.0.0.1:6379[1]> select 2
OK127.0.0.1:6379[2]> keys *
1) "k1"
3,数据库中清空数据
Redis数据库的整库数据删除主要分为两个部分:清空当前数据库数据,使用FLUSHDB 命令实现:清空所有数据库的数据,使用FLUSHALL 命令实现。但是,数据清空操作比较危险,生产环境下一般不建议使用。
127.0.0.1:6379[2]> keys *
1) "k1"
127.0.0.1:6379[2]> flushdb ##清空当前数据库的内容
OK
127.0.0.1:6379[2]> keys *
(empty list or set)##清空所有数据的内容
127.0.0.1:6379[2]> flushall -
四, Redis持久化
Redis的所有数据都是保存在内存中,然后不定期的通过异步方式保存到磁盘上(这称为“半持久化模式”);也可以把每一次数据变化都写入到一个 appendonly file(aof)里面(这称为“全持久化模式”)。
1,RDB持久化
- RDB优点
- 一旦采用该方式,那么整个 Redis 数据库将只包含一个文件,这对于文件备份而言是非常完美的。比如,计划每个小时归档一次最近24 小时的数据,同时还要每天归档一次最近 30 天的数据。通过这样的备份策略,一旦系统出现灾难性故障,可以非常容易地进行恢复。
- 对于灾难恢复而言,RDB 是非常不错的选择。可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。
- 性能最大化,对于 Redis 的服务进程而言,在开始持久化时,它唯一需要做的只是 fork 出子进程,之后再由子进程完成这些持久化的工作,这样就可以极大的避免服务进程执行 I0 操作了。
- 相比于 AOF 机制,如果数据集很大,RDB的启动效率会更高。
- RDB缺点
- 如果想保证数据的高可用性,即最大限度的避免数据丢失,那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象,此前没有来得及写入磁盘的数据都将丢失。
- 由于 RDB 是通过 fork 子进程来协助完成数据持久化工作的,因此当数据集较大时,可能会导致整个服务器停止服务几百毫秒,甚至是1秒钟。
2,AOF持久化
- AOF的优点
- AOF 机制可以带来更高的数据安全性,即数据持久性。Redis 中提供了 3 种同步策略,即每秒同步、每次修改同步和不同步。事实上,每秒同步也是异步完成的,其效率也是非常高的,弊端是一旦系统出现宕机现象,那么这一秒钟之内修改的数据将会丢失。而每次修改同步,可以将其视为同步持久化,即每次发生的数据变化都会被立即记录到磁盘中,这种方式在效率上是最低的。
- 由于该机制对日志文件的写入操作采用的是 append 模式,因此在写入过程中即使出现 宕机现象,也不会破坏日志文件中已经存在的内容。然而如果本次操作只是写入了一半 数据就出现了系统崩溃问题,那么在 Redis 下一次启动之前,可以通过 redis-check-aof 工具来解决数据一致性的问题。
- 如果日志过大,Redis 可以自动启用 rewrite 机制。即 Redis 以 append 模》式不断地将修改数据写入到老的磁盘文件中,同时 Redis 还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性。
- AOF 包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上,也可以通过该文件完成数据的重建。
- AOF的缺点
- 对于相同数量的数据集而言,AOF 文件通常要大于 RDB 文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
- 根据同步策略的不同,AOF在运行效率上往往会慢于RDB。每秒同步策略的效率是比较高的,同步禁用策略的效率和RDB一样高效。
3,AOF重写
Redis 会不断地将被执行的命令记录到 AOF 文件里面,所以随着 Redis 不断运行,AOF 文件的体积也会不断增长。在极端情况下,体积不断增大的 AOF 文件甚至可能会用完硬盘的所有可用空间。Redis在重启之后需要通过重新执行AOF 文件记录的所有写命令来还原数据集,所以如果 AOF文件的体积非常大,那么还原操作执行的时间就可能会非常长。
为了解决 AOF 文件体积不断增大的问题,用户可以向Redis 发送BGREWRITEAOF命令。BGREWRITEAOF 命令会通过移除 AOF 文件中的几余命令来重写(rewrite)A0F 文件,使 AOF 文件的体积尽可能地变小。
##在redis中输出该命令,移除AOF文件中的冗余命令,避免AOF重写
127.0.0.1:6379> bgrewriteaof
Background append only file rewriting started
4,配置持久化
- RDB持久化
RDB持久化配置Redis 会将数据集的快照 dump 到 dump.rdb 文件中。此外,也可以通过配置文件来修改 Redis 服务器 dump 快照的频率。在打开 6379.conf 文件之后,搜索 save,可以看到如下所示配置信息。
- save 9001:在 900 秒(15 分钟)内,如果至少有1个 key 发生变化则 dump 内存快照。
- save 300 10:在 300 秒(5 分钟)内,如果至少有 10个 key 发生变化,则 dump 内存快照。
- save 60 10000:在 60 秒(1 分钟)内,如果至少有 10000个 key 发生变化,则 dump 内存快照。
##redis中默认开启RDB持久化
[root@localhost ~]# vim /etc/redis/6379.conf
save 900 1 ##配置文件219行
save 300 10
save 60 10000rdbcompression yes ##是否压缩 242行
adbfilename dump.rdb ##备份文件名字 254行
- AOF持久化
在 Redis 的配置文件中存在三种同步方式,它们分别是
- appendfsync always:每次有数据修改发生时都会写入 AOF 文件
- appendfsynceverysec:每秒钟同步一次,该策略为 A0F的缺省策略
- appendfsync no:从不同步,高效但是数据不会被持久化
[root@localhost ~]# vim /etc/redis/6379.conf
appendonly yes ##673行no改为yes表示开启AOF持久化
appendfilename "appendonly.aof" ##677行备份文件名字# appendfsync always
appendfsync everysec ##703行选择同步方式
# appendfsync no