Redis详解
一、Redis介绍
Redis 是用C语言开发的一个开源的高性能键值对(key-value)数据库。它通过提供多种键值数据类型来适应不同场景下的存储需求,目前为止Redis 支持的键值数据类型有如下:
- 字符串类型(String)
- 散列类型(Hash)
- 列表类型(List)
- 集合类型(Set)
- 有序集合类型(SortedSet)
Redis的主要应用场景有:
- 缓存(数据查询、短连接、新闻内容、商品内容等)—使用最多
- 聊天室的在线好友列表
- 任务队列(秒杀、抢购、12306等)
- 应用排行榜
- 网站访问统计
- 数据过期处理(可以精确到秒)
- 分布式集群架构中的session分离
Redis 不仅可以使用命令来操作,并且对大部分主流的语言也有客户端支持,比如Java、C、C#、C++、PHP、Node.js、Go等。
在官方网站里列一些Java的客户端,有Jedis、Redisson、Jredis、JDBC-Redis 等,其中官方推荐使用Jedis和Redisson。在企业中用的最多的就是Jedis。关于Redis在Linux系统上的安装,可以借鉴我的Redis安装博客文章。
二、Redis的数据结构
Redis是一种高级的key-value的存储系统,其中value支持五种数据类型:
- 字符串(String)
- 哈希(hash)
- 字符串列表(list)
- 字符串集合(set)
- 有序字符串集合(sorted set)
而关于key的定义,需要注意以下几点:
- key不要太长,最好不要超过1024个字节,这不仅会消耗内存还会降低查找效率
- key不要太短,如果太短会降低key的可读性
- 在项目中,key最好有一个统一的命名规范(如:
"user-redis-session"
)
String 类型操作命令
字符串类型是Redis中最为基础的数据存储类型,它在Redis中是二进制安全的,这便意味着该类型存入和获取的数据相同,不会存在乱码。在Redis中字符串类型的value最多可以容纳数据长度是512M。
常用命令:
- 赋值:
set key value
(如果该key存在,则覆盖,否则,创建该 key) - 取值:
get key
(注意:该方法只能获取 value 为 String 类型的 key 值) - 删除:
del key
(删除指定 key) - 数值增:
incr key
(相当于 num++;将指定的key的value递增1,如果该key不存在,其初始值为0,在incr 之后其值为1) - 数值减:
decr key
(相当于 num-- ;将指定的key的value递减1,如果该key不存在,其初始值为0,在incr 之后其值为 -1) - 增加值:
incrby key number
(为指定的key的value增加number) - 减少值:
decrby key number
(为指定的key的value减少number) - 拼凑字符串:
append key value
(相当于字符串拼接)
Hash 类型操作命令
Redis中的Hash类型可以看成是 String key, Map<String,String>的value。所以该类型非常适合存储值对象的信息。如果Hash中包含很少的字段,那么该类型的数据也将仅占用很少的磁盘空间。每一个Hash可以存储4294967295个键值对。
常用命令:
- 赋值:
hset key field value
(为指定的key设定 field/value 对) - 赋值多个:
hset key field value field value ...
(设置key中的多个 field/value 对) - 取值:
hget key field
(返回指定的key中的 field 的值) - 获取所有:
hgetall key
(获取key中的所有 field/value 对) - 删除:
hdel key field field ...
(可以删除一个或多个字段) - 删除整个hash:
del key
(删除整个key map) - 增加数字:
hincrby key field number
(设置key中field的值增加number) - 判断field是否存在:
hexists key field
(判断指定的key中的field是否存在) - 获取所有field:
hkeys key
(获得key 下面所有的 field) - 获取所有的value:
hvals key
(获得key下面所有的value值)
keys的通用操作
下面的命令对五种数据类型都起作用:
- 通配符获取所有key:
keys pattern
(获取所有与pattern匹配的key。如果pattern为 * ,表示任意一个或多个字符,?表示任意一个字符) - 删除key:
del key1 key2 ...
(删除一个或多个key) - 判断是否存在:
exists key
(判断该key是否存在,1代表存在,0代表不存在) - 重命名:
rename key newkey
(为当前key重命名) -
设置过期时间:
expire key
(单位:秒) - 获取所剩时间:
ttl key
(获取该key所剩的超时时间,如果没有设置超时,返回-1,。如果返回-2,表示该key已经不存在) - 检测key类型:
type key
(获取指定key的类型)
三、Redis的特性
1 .多数据库
一个Redis实例默认含有16个数据库,编号为0~15,客户端可以指定连接某个Redis实例的哪个数据库,就好比一个MySQL中创建多个数据库,客户端连接时指定 连接哪个数据库。客户端默认连接第一个。关于数据库的操作命令如下:
-
select index
指定连接某个数据库 -
move key index
将当前库的key移植到编号为index的库中 -
flushdb
删除当前数据库中所有的key -
flushall
删除所有数据库中的所有的key
2 .消息订阅与发布
-
subscribe channel
订阅频道,例:subscribe mychat
,订阅mychat这个频道 -
psubscribe channel*
批量订阅频道,例:psubscribe s*
,订阅以 "s"开头的所有频道 -
publish channel content
在指定的频道中发布消息,如:publish mychat 'hello everyOne'
3 .Redis 事务
和从多其他数据库一样,Redis作为NoSQL数据库也同样提供了事务机制。在Redis中,multi/exec/discard 这三个命令是我们实现事务的基石
命令解释:
-
multi
开启事务用于标记事务的开始,其后执行的命令都将被存入命令队列,直到执行exec
命令时,这些命令才会被原子的执行,类似于关系型数据库中的:begin transaction
-
exec
提交事务,类似于关系型数据库中的:commit
-
discard
事务回滚,类似于关系型数据库中的:rollback
注意:如果在编写命令时,加入命令队列中,发生了错误,那么该事务将被移除,最终通过exec
提交事务,所有的值不会改变,如下图:如果,加入命令队列中的所有命令都没有编写错误,但是在执行时发生了编译出错,那么该事务不会回滚,而是忽略错误命令,继续执行正确命令。如下图:
总结:如果Redis事务过程中,发生了错误,Redis事务不会回滚。关于Redis事务的详解,可以参考这篇博客
四、Redis的持久化
Redis的高性能是由于其将所有数据都存储在了内存中,为了使Redis在重启之后仍能保证数据不丢失,需要将数据从内存中同步到硬盘中,这一过程就是持久化。
Redis支持两种方式的持久化,一种是RDB 方式,一种是AOF方式。可以单独使用其中一种或将二者结合使用。
-
RDB持久化(默认支持,无需配置)
该机制是指在指定的时间间隔内将内存中的数据集快照写入磁盘。 -
AOF持久化
该机制将以日志的形式记录服务器所处理的每一个写操作,在Redis服务器启动之初会读取该文件来重新构建数据库,以保证启动后数据库中的数据是完整的。 -
无持久化
我们可以通过配置的方式禁用Redis 服务器的持久化功能,这样我们就可以将Redis 视为一个功能加强版的memcached了。 - Redis可以同时使用RDB和AOF
RDB介绍
优势:
- 一旦采用该方式,那么你的整个Redis数据库将只包含一个文件,这对于文件备份而言是非常完美的。比如,你可能打算每个小时归档一次最近24小时的数据,同时还要每天归档一次最近30天的数据。通过这样的备份策略,一旦系统出现灾难性故障,我们可以非常容易的进行恢复。
- 对于灾难恢复而言,RDB是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上
- 性能最大化。对于Redis的服务进程而言,在开始持久化时,它唯一需 要做的只是fork (分叉)出子进程,之后再由子进程完成这些持久化的工作,这样就可以极大的避免服务进程执行IO操作了。
- 相比于AOF机制,如果数据集很大,RDB的启动效率会更高。
劣势:
- 如果你想保证数据的高可用性,即最大限度的避免数据丢失,那么RDB将不是一个很好的选择。 因为系统一旦在定时持久化之前出现宕机现象,此前没有来得及写入磁盘的数据都将丢失。
- 由于RDB是通过fork子进程来协助完成数据持久化工作的,因此,如果当数据集较大时,可能会导致整个服务器停止服务几百毫秒,甚至是1秒钟
快照参数设置:
- save 900 1 #每900秒(15分钟)至少有1个key发生变化,则dump内存快照。
- save 300 10 #每300秒(5分钟)至少有10个key发生变化,则dump内存快照
- save 60 10000 #每60秒(1分钟)至少有10000个key发生变化,则dump内存快照
AOF介绍
优势:
- 该机制可以带来更高的数据安全性,即数据持久性。Redis中提供了3种同步策略,即每秒同步、每修改同步和不同步。事实上,每秒同步也是异步完成的,其效率也是非常高的,所差的是一旦系统出现宕机现象,那么这一秒钟之内修改的数据将会丢失。而每修改同步,我们可以将其视为同步持久化,即每次发生的数据变化都会被立即记录到磁盘中。可以预见,这种方式在效率上是最低的。至于无同步,无需多言,我想大家都能正确的理解它。
- 由于该机制对日志文件的写入操作采用的是append模式,因此在写入过程中即使出现宕机现象,
也不会破坏日志文件中已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题,不用担心,在Redis下一次启动之前,我们可以通过redis check-aof工具来帮助我们解决数据一致性的问题。 - 如果日志过大,Redis可以自动启用rewrite 机制。即Redis以append模式不断的将修改数据写
入到老的磁盘文件中,同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性。 - AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上,我们也可以通
过该文件完成数据的重建。
劣势:
- 对于相同数量的数据集而言,AOF文件通常要大于RDB文件
- 根据同步策略的不同,AOF 在运行效率上往往会慢于RDB。总之,每秒同步策略的效率是比较高 的,同步禁用策略的效率和RDB一样高效。
配置AOF,配置信息:
- always #次有数据修改发生时都会写入AOF文件
- everysec #每秒钟同步一次,该策略为AOF的缺省策略
- no #从不同步。高效但是数据不会被持久化