传统DB的缺点
像Mysql、和Oracle 这种关系型数据库,虽然有着数据稳定和服务稳定、数据一致性的特点,但也存在一个致命的缺陷:
高并发下DB不稳定
在高并发的情况下,DB的不稳定性,在大量用户访问时DB出奇的慢,因为对磁盘操作需要使用IO流,一个字节一个字节存取操作。要将所有数据读取到内存中后才可以操作。所以在高并发下DB的高可用便成了问题。这时NoSQL便应运而生。
什么是NOSQl
NoSQL是对不同于传统的关系数据库的数据库管理系统的统称。即非关系型数据库
NOSQL:因为是内存操作数据,非常快,解决了三高问题(高并发、高海量、高可用)
非关系型数据库与非关系型数据库的区别
关系型数据库 | 非关系型数据库 |
---|---|
以文件方式保存 | 存储在内存中,服务器关闭数据可能会丢失 |
数据可以永久保存 | 不能持久化保存,可能导致数据丢失 |
查询速度慢 | 存取速度快 |
常见的NOSQL数据库
Redis
简单翻译下
Redis是一个开源(BSD许可)的内存数据结构存储,用作数据库、缓存和消息代理。它支持诸如字符串、散列、列表、集、带范围查询的排序集、位图、hyperloglogs、带半径查询和流的地理空间索引等数据结构。Redis具有内置的复制、Lua脚本、LRU清除、事务和不同级别的磁盘持久性,并通过Redis Sentinel和带有Redis集群的自动分区提供高可用性
redis的安装可以到官网下载,这里就不演示了。
Redis是一种高级的key:value存储系统,其中value支持五种数据类型
字符串(strings)
字符串无序集合(Set)
有序字符串集合(zset)
字符串列表(List)
-哈希类型(hash)
String类型
字符串类型是 Redis 中最为基础的数据存储类型,它在 Redis 中以二进制保存,没有编码和解码的过程,String字符串类型的Value数据长度512M
操作 | 作用 |
---|---|
set key 值 | 添加字符串类型键和值 |
get key 值 | 取出指定类型的值,没有返回null |
del key | 删除指定的key 返回删除的个数 没有返回0 |
Set类型
我们可以将 Set 类型看作为没有排序的字符集合
操作 | 作用 |
---|---|
sadd key 值1、值2 | 向集合中添加一个或多个元素 |
smembers key | 查询指定集合所有的元素 |
sismember key 值 | 查询某个值是否存在 存在返回1、反则 |
srem key 值1、值2 | 删除指定元素 |
Zset类型
集合一样也是string类型元素的集合,且不允许重复的成员。
不同的是每个元素都会关联一个分数。redis正是通过分数来为集合中的成员进行从小到大的排序。有序集合的成员是唯一的,但分数(score)却可以重复,每个集合可存储40多亿个成员
操作 | 作用 |
---|---|
zadd key 分数 值 | 向集合 添加一个或多个元素 |
zrang key 开始 结束 | 返回集合中指定区间内的元素 |
zrem key 值 | 删除集合的 一个元素或多个元素 |
zcard key | 获取集合中的元素数 |
zrank key 值 | 返回集合中指定成员的索引 |
list类型
List 类型是按照插入顺序排序的字符串链表。和数据结构中的普通链表一样,我们可以在其左部(left)和右部(right)添加新的元素。
操作 | 作用 |
---|---|
lpush key 元素1 元素2 | 往链表左边添加元素 键不存在则 创建新链表 |
rpush key 元素1 元素2 | 往链表右边添加元素 键不存在则 创建新链表 |
lrange key 开始 结束 | 取出指定范围的元素列表 左边数第一个为0 右边数第一个为-1 |
lpop key | 从左边删除一个元素 |
rpop key | 从右边删除一个元素 |
llen key | 得到指定链表的长度 |
Hash类型
Redis 中的 Hash 类型可以看成具 String 的键和 String 的值 Map 容器,每一个 Hash 可以存储 40(42 亿 9千多个)亿个键值对。
操作 | 作用 |
---|---|
hset key MapKey 值 | 向指定的key中添加 hasnMap类型 |
hget key MapKey | 获取指定key中的指定HashMap |
hmset key MapKey1 值 MapKey2 值 | 向一个键中设置多个Map和值 |
hmget key MapKey1 MapKey2 | 获取一个键中的多个Map |
hdel key MapKey1 MapKey1 | 删除一个键中的多个Map |
hgetall key | 得到一个键中的所有Map |
批量插入Map | |
删除Map | |
其他操作命令
操作 | 作用 |
---|---|
keys 匹配字符 | 查询数据库的键 ( * 为匹配全部字符) |
del key1 key2 | 删除任意键 |
exists key | 判断指定键是否存在 |
type key | 判断该key 属于哪种类型 |
select 数据库编号 | 选择指定的数据库 |
move key 数据库编号 | 将某个键移动到另一个数据库 |
Expire key 秒 | 设置过期时间 |
TTL key | 返回剩余生存时间 |
Redis数据库,Redis默认有16个数据库,我们可以通过Redis的一个图形化工具查看
设置过期时间(过期时为-2)
Redis持久化
Redis的最大特色就是持久化机制,当发生服务器宕机等不可预料因素时,Redis会将符合条件的数据进行持久化,在重启时恢复数据。RDB 和 AOF 是 Redis 内部的两种数据持久化策略,这是两种不同的持久化策略,一种是基于内存快照,一种是基于操作日志
RDB持久化策略(基于内存快照)
RDB(Redis DataBase)持久化策略就是在符合一定条件下将内存所有数据持久化到磁盘中dump.rdb文件中。RDB策略是redis默认持久化策略。也叫快照策略。
什么是快照策略,RDB持久化是指在某一段时间内将该内存下所有的数据存储为文件,当服务器丢失时,自动恢复到最新的一份RDB文件,简单点说就是相当于每隔一段时间就将Redis的文件
做一次备份,当然要满足一定的要求 RDB持久化是Redis默认的持久化机制
在安装完Redis的目录下有个config文件
在该文件下我们可以找到这样一段话
简单翻译一下就是
将DB保存到磁盘上:
在下面的例子中行为将保存DB
900秒后(15分钟)如果至少1键改变了
300秒(5分钟)如果至少10键改变
60秒后如果至少10000键改变也就是说:
当数据在15分钟内改变了一个key,就会执行持久化机制
如果数据在5分钟内有10个key改变,就会执行持久化机制
如果数据在1分钟内有10000key改变,就会执行持久化机制
而我们持久化完的数据在哪里显示呢?
在该文件下面也有进行说明
简单翻译下
要将数据库转储到何处的文件名
于是我们就可以在Redis的安装目录下找到这个文件
关于RDB持久化机制
RDB的持久化机制,我们可以在配置文件中修改持久化时间,但一般不建议修改,因为在Redis达到一定数据量时,频繁的进行RDB的持久化机制便是一个非常浪费性能的事。RDB的持久机制
不高,便意味可能RDB持久化会导致丢失一定的数据。以快的持久化时间来说,相当于我们还是有60秒的空档期。而这可以靠另一个持久化机制来解决。
AOF持久化策略(基于操作日志)
AOF(append only file)策略,是基于操作日志实现的
它的特点持久化的频率非常高了,默认每秒持久化1次。每一秒内将最新的写入与删除的命令进行持久化。
AOF的持久化机制和RDB的持久化机制完全不同,AOF是基于日志文件操作的,简单点说就是RDB会将数据进行备份,而AOF备份的是操作 , 就是说,AOF将你所有的写入和删除操作进行备份,当服务器宕机时,可以通过备份的操作还原数据。
在配置文件中有这么一小段
简单翻译下
可以同时启用AOF和RDB持久性,没有问题。如果在启动时启用了AOF,那么Redis将加载AOF,即具有更好持久性保证的文件
开启AOF机制
AOF持久化选择
简单翻译下
默认设置是“每隔一秒”,因为这通常是正确的折衷
速度和数据安全。这取决于你是否能慢下来
“no”将允许操作系统在何时刷新输出缓冲区
为了更好的表现(但是如果你能接受一些数据丢失更多考虑的是快照的默认RDB持久性模式),或者相反,使用“always”,虽然很慢,但是更安全。
这里指的是AOF提供持久化的频率
always:指每次修改都进行持久化操作,效率是最低的,但也是最安全的。
everysec:指每秒持久化一次,默认使用
no:指的是不进行持久化,效率最高
AOF的重写机制
当AOF开启时每秒的操作都会进行持久化,这样会导致日志文件的过大
于是AOF就有了重写机制,同样在配置文件下
简单翻译下
这个基本大小与当前大小进行比较。如果当前大小大于指定的百分比,将触发重写。您需要为要重写的AOF文件指定一个最小的大小
默认当日志文件大小超过内存数据100%时触发重写
当日志文件达到64M时也触发重写
关于AOF持久化机制
AOF策略的优点是显而易见的, 每秒持久化,具有更高的数据安全,如果服务器崩溃只会丢1秒内的数据,但缺点也是一样明显:由于持久化频率高,Redis的性能会变低。
值得注意的是AOF和RDB同时开启,默认使用AOF恢复数据,
因为AOF是秒级以内的容错。
关于两者的选用
官方建议
通常,如果你要想提供很高的数据保障性,那么建议你同时使用两种持久化方式。
如果你可以接受灾难带来的几分钟的数据丢失,那么你可以仅使用RDB。很多用户仅使用了AOF,但是我们建议,既然RDB可以时不时的给数据做个完整的快照,并且提供更快的重启,所以最好还是也使用RDB。
因此,我们希望可以在未来(长远计划)统一AOF和RDB成一种持久化模式。
最后
关于Redis就讲到这里了
有空再更!!!!
个人博客:juhaozero的博客