关系型数据库
一个结构化的数据库,创建在关系模型基础上
一般面向与记录
包括
Oracle、MySQL、SQL server、DB2
非关系型数据库
处理主流的关系型数据库外的数据库,都认为是非关系型
包括
redis、mongdb、Hbase、CouhDb等
Redis
redis基于内存运行并支持持久化
采用key-value(键值对)的存储形式
优点
具有极高的数据读写速度
支持丰富的数据类型
支持数据的持久化
原子性
支持数据备份
redis 和 memcached 比较
Redis和Memcached都是常见的键值对存储系统,用于缓存数据。下面是Redis和Memcached之间的一些对比:
- 数据结构支持:
- Redis:支持多种数据结构,如字符串、哈希、列表、集合和有序集合等。这使得Redis在处理复杂数据和实现更多功能方面更加灵活。
- Memcached:仅支持简单的键值对结构,只能存储字符串类型的数据。
- 持久化:
- Redis:提供持久化机制,支持快照(snapshotting)和AOF(Append-only file)两种方式。这样可以在服务器重启后恢复数据,防止数据丢失。
- Memcached:不提供持久化支持,数据只存在于内存中。服务器重启后,所有数据将被清空。
- 内存管理:
- Redis:采用灵活的内存管理策略,可以将数据持久化到磁盘上,并在需要时从磁盘中加载数据。可以设置最大内存限制,并支持内存淘汰策略,如LRU(最近最少使用)。
- Memcached:将所有数据存储在内存中,并且没有内存淘汰机制。当内存满时,新的数据无法存储,需要通过删除旧的数据来释放内存。
- 多线程支持:
- Redis:采用单线程模型,通过异步I/O来实现高性能。它可以处理并发请求,并且没有锁竞争,因此具有较低的线程开销。
- Memcached:采用多线程模型,使用线程池来处理并发请求。在高并发情况下,可以通过多线程处理请求提高吞吐量。
- 数据一致性:
- Redis:支持主从复制和Sentinel哨兵机制,可以实现数据的自动备份和故障转移,提供更高的可用性和数据一致性。
- Memcached:不支持自动备份和故障转移,不具备数据一致性保障。
- 生态系统和社区支持:
- Redis:拥有庞大的开源社区和丰富的生态系统,提供了许多工具、扩展和解决方案。有大量的文档和教程可用于参考。
- Memcached:社区相对较小,生态系统相对简单。文档和教程相对较少。
redis的安装与部署
1.基础环境
2. 安装依赖支持
yum -y install gcc gcc-*
3.上传软件包(redis-4.0.9.tar.gz)
4.编译安装
tar zxf redis-4.0.9.tar.gz
cd redis-4.0.9
make
#指定安装路径
make PREFIX=/usr/local/redis install
#软链接管理
ln -s /usr/local/redis/bin/* /usr/local/bin/
cd utils/
#执行脚本,回车选择默认的文件路径,最后的执行文件存放位置,一定要与链接文件路径一致
./install_server.sh
安装成功
redis的基本操作
#启动服务
/etc/init.d/redis_6379 start
#关闭服务
/etc/init.d/redis_6379 stop
#重启服务
/etc/init.d/redis_6379 restart
#查看服务状态
/etc/init.d/redis_6379 status
5.压力测试
cd
#一千个请求,一万个并发
redis-benchmark -h localhost -p 6379 -c 1000 -n 10000
# 是测试存取大 小为 100 字节的数据包的性能
redis-benchmark -h 127.0.0.1 -p 6379 -q -d 100
操作redis
#连接本地redis
redis-cli
#连接指定redis
redis-cli -h 127.0.0.1
#查看详细信息
info
命令行操作
清空所有内容 :FLUSHALL
添加数据 :set
查询数据:get
查看所有数据 keys *
模糊匹配查
keys 字母* | 查看以某个字母开头的数据 |
keys name? | 查看以name这个数据开头的数据后匹配一个字符 |
keys name?? | 查看以name这个数据开头的数据后匹配两个字符 |
EXISTS name | 判断是否存在这个数据 ,存在返回1,不存在返回0 |
RENAME name newname | 重命名,修改数据名字 |
del name | 删除name这个数据 |
DBSIZE | 返回的数字为有多少条数据 |
EXPIRE name 时间(以秒为单位) | 设置这个数据过期时间 |
set kgc 2222 EX 7 | 设置时设置过期时间 |
select 数字 | 切换到指定数字的库(每个数据库之间的数据不通) |
move name 数字 | 移动name这个数据移动到指定数字号库 |
FLUSHDB | 清空当前库的所有内容 |
save | 手动触发备份(要达到要求) |
redis持久化
持久化
redis是运行在内存中,内存中的数据断电丢失
为了能够重用redis数据,或者防止系统故障,需要讲redis中的数据写入到磁盘空间中,即持久化
持久化分类
RDB方式:创建快照的方式获取某一刻redis中的所有数据的副本
AOF方式:将执行的写命令写到文件的末尾,以日志的方式来记录数据的变化
对比
- RDB 优缺点
- RDB 优点
- 一旦采用该方式,那么整个 Redis 数据库将只包含一个文件,这对于文件备份而言是非常完美的。比如,计划每个小时归档一次最近 24 小时的数据,同时还要每天归档一次最近 30 天的数据。通过这样的备份策略,一旦系统出现灾难性故障,可以非常容易地进行恢复。
- 对于灾难恢复而言,RDB 是非常不错的选择。可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。
- 性能最大化,对于 Redis 的服务进程而言,在开始持久化时,它唯一需要做的只是 fork 出子进程,之后再由子进程完成这些持久化的工作,这样就可以极大的避免服务进程执 行 IO 操作了。
- 相比于 AOF 机制,如果数据集很大,RDB 的启动效率会更高。
2.RDB 缺点
- 如果想保证数据的高可用性,即最大限度的避免数据丢失,那么 RDB 将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象,此前没有来得及写入磁盘的数 据都将丢失。
- 由于 RDB 是通过 fork 子进程来协助完成数据持久化工作的,因此当数据集较大时,可能会导致整个服务器停止服务几百毫秒,甚至是 1 秒钟。
- 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 一样高效。
RDB持久化
redis的默认持久化方式
默认文件名dump.rdb
触发条件
在指定的时间间隔内,执行指定次数的写操作(配置文件控制)
执行save或者是bgsave(异步)命令
执行flushall命令,清空数据库所有数据
执行shutdown命令,保证服务器正常关闭且不丢失任何数据
优缺点
适合大规模的数据恢复
如果业务对数据完整性和一致性要求不高,RDB是很好的选择
数据的完整性和一致性不高
备份时占用内存
RDB备份与恢复
1.打开配置文件
vi /etc/redis/6379.conf
自动备份的条件
模拟数据丢失备份恢复
AOF的备份与恢复
1.打开配置文件,启用AOF备份
vi /etc/redis/6379.conf
2.AOF备份条件
3.退出重启服务
/etc/init.d/redis_6379 restart
4.开启AOF,模拟写入数据,用来验证备份的效果
5. 备份数据,模拟数据丢失
验证数据丢失
6.复制备份文件到原地方,恢复数据