Redis详解

1. Redis 概述

Redis:远程字典服务器(REmote DIctionary Server);
Redis 是一个高性能(key/value)分布式内存数据库,基于内存运行并支持持久化的NoSQL数据库;
Redis 三个特点:
- Redis 支持数据的持久化,可以将内存中的数据保存在磁盘中,重启的时候,可以再次加载进行使用;
- Redis 不仅仅支持简单的key-value类型的数据,同时还提供list,set,zset,hash等数据结构的存储;
- Redis 支持数据的备份,即master-slave模式的数据备份;

2. Redis 数据类型

2.1 Redis 的五大数据类型

String(字符串)
Hash(哈希,类似java里的Map)
List
Set
Zset(sorted set: 有序集合)

2.2 Redis 键(key)

set 键名键值: 向数据库中存储键值对;
keys *: 查看当前数据库所有键;
exits 键名: 判断某个key是否存在,存在,返回"1";不存在,返回"0";
move 键名数据库(例如2): 将某个键剪切至2号数据库;
expire key 秒: 为指定的key设置过期时间;
ttl key: 查看该key,还有多少秒过期,-1表示永不过期, -2表示已过期;
type key: 查看key的类型;

2.3 Redis 字符串(String)

set/get/del 键名: 设置/获取/删除;
append 键名(key) 值: 向key所对应的value后面添加值;
strlen 键名(key): 获取某个key所对应的value的字符串长度;
incr/decr/incrby/decrby: 一定要是数字才能进行加减;
getrange k2 0 3: 表示获取k2所对应的value的前四个字符;
setrange: 设置指定区间范围内的值;
setex(set with expire) 秒: 设置过期时间;
setnx(set if not exist)
mset/mget/msetnx: 设置(获取)多个, 例,mset k2 v2 k3 v3 k4 v4;
getset: 先get再set;

2.4 Redis 列表(List)

LPUSH list01 1 2 3 4 5: 存储list; "LPUSH(Left push)"
LRANGE list01: 获取,"5,4,3,2,1";
RPUSH list02 1 2 3 4 5
LRANGE list02: 获取, "1 2 3 4 5"
LPOP/RPOP
LINDEX: 按照索引下标获得元素(从上到下);
LLEN: 获取list集合的长度;
RUPUSH list03 1 1 1 2 2 2 3 3 3 4 4 4 5 6 7
LREM list03 2 3: 删除list03集合中两个3(LREM, left remove);
LTRIM list03 0 4: 截取指定范围(0~4)的值,然后赋值给list03;
RPOPLPUSH 源列表目的列表
LSET list03 1 x: 将list03中的下标为1的键的值设置为"x";
LINSERT list03 before(after) x java: 在"x"的前面(或后面)插入"java";

2.5 Redis 集合(Set)

SADD set01 1 1 2 2 3 3: 向set01中插入值,只会插入"1 2 3",即不允许重复;
SMEMBERS set01: 获取set01集合中的值
SISMEMBER set01 1: 判断"1"是否为集合set01成员; 如果是,返回1;不是,返回0;
SCARD: 获取集合里面元素个数;
SREM key member[memeber...]:移除集合key中的一个或多个memeber元素;
SRANDMEMEBER set01 3: 从set01集合中随机取三个值;
SPOP set01:从set01集合中,随机移除一个元素,并返回该元素;
SMOVE source destination memeber: 将 memeber 元素从source集合移动到destination集合;
SDIFF: 差集;
SINTER: 交集;
SUNION: 并集;

2.6 Redis 哈希(Hash)

类似于 Map<String,Object>;
KV模式不变,但V是一个键值对;
hset user gender male: 将 user 哈希表中的gender值设为male;
hget user gender: 获取;
hmset customer id 11 name zhangsan age 22:同时将多个field-value(域-值)对设置到哈希表customer中
hmget customer id name age: 获取多个值;
hgetall customer: 获取所有的域和值;
hdel customer id name: 删除哈希表中的id和name域;
hlen customer:获取哈希表的长度;
hexists customer id: 查看哈希表customer中是否存在id域;
hkeys customer: 获取哈希表customer中的所有域;
hvalues customer: 获取哈希表customer中的所有域的值;
hincryby key field increment: 为哈希表key中的域field的值加上增量increment;
hincrbyfloat
hsetnx key field value: 当域field不存在时,将该域field的值设置为value;

2.7 Redis 有序集合(Zset,sorted set)

Zset 在set基础上,加上一个score值;之前set集合是:k1 v1 v2 v3,现在,Zset是k1 score1 v1 score2 v2
zadd key score1 mem1 score2 mem2:将一个或多个memeber元素及其score的值加入到有序集key当中;
zrangebyscore key 开始min 结束max: 返回有序集key中,所有score介于min和max之间;
zrangebysroce zset (1 5: 返回所有符合条件 1<score<=5 的成员;
zrem key memeber: 移除有序集key中的一个或多个成员;
zcard key: 返回有序集合key的基数;
zcount key min max: 返回有序集key中,score值在min和max之间的成员数量;
zrank key member: 返回有序集key中成员memeber的下标;
zscore key member: 返回有序集key中,成员memeber对应的score值;
zrevrank key member: 逆序获得成员member下标值;
zrevrange key 0 -1: 逆序获得有序集key的所有的member成员;
zrevrangebyscore

3. Redis 的持久化

RDB(Redis DataBase)
AOF(Append Only File)

3.1 RDB(Redis DataBase)

3.1.1 RDB 概述

RDB: 在指定的时间间隔内,将内存中的数据集快照(snapshot)写入磁盘,它恢复时,是将快照文件直接读到内存里;
Redis 会单独创建(fork)一个子进程来进行持久化,会先将数据写入到一个临时文件中,待持久化过程都结束了,
在用这个临时文件替换上次持久化好的文件;
整个过程中,主进程是不进行任何IO操作的,这就确保了极高的性能;
如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加高效;
RDB 的缺点: 最后一次持久化后的数据可能丢失;
RDB 保存的是 dump.rdb;
RDB 是整个内存压缩过的Snapshot, RDB持久化策略,与快照触发条件一样,默认值
- 1分钟内修改了1万次;
- 5分钟内修改了10次;
- 15分钟内修改了1次;

3.1.2 Fork

Fork的作用: 是复制一个与当前进程一样的进程;新进程的所有数据(变量,环境变量,程序计数器等)数值都和原进程
一致,但是是一个全新的进程,并作为原进程的子进程;

3.1.3 触发RDB快照的方式(三种)

配置文件中默认的快照配置,冷拷贝以后重新使用(即备份文件和要恢复备份的机器不是同一台);
save或bgsave命令,立刻生成dump.rbd文件;
- save时,只管保存,其他不管,全部阻塞;
- bgsave:Redis 会在后台异步执行快照操作,快照的同时还可以响应客户端请求;可以通过lastsave命令
  获取最后一次成功执行快照的时间;
执行flushall命令,也会产生dump.rdb文件,但里面是空的,无意义;

3.1.4 恢复备份文件

将备份文件(dump.rdb)移动到redis安装目录并启动服务即可;

3.1.5 RDB优缺点

优势:
- 适合大规模的数据恢复;
- 对数据完整型和一致性要求不高;
劣势
- 在一定间隔时间做一次备份,所以如果redis意外down掉的话,就会丢失最后一次快照后的所有修改;
- Fork 的适合,内存中的数据被克隆了一份,大致2倍的膨胀性需要考虑;

3.2 AOF(Append Only File)

3.2.1 AOF 概述

以日志的形式来记录每个写操作,将Redis执行过的所有写指令记录下来(读操作不记录),只需追加文件但不可以改写文
件, redis启动之初会读取该文件,重新构建数据,换言之,redis重启的话,就根据日志文件的内容将写指令从前到后执行一
次以完成数据的恢复工作;
redis.conf中的配置appendonly no,即该种持久化方式默认为关闭;
redis.conf中的配置appendfsync=everysec,出厂默认值,异步操作,每秒记录,若一秒内宕机,有数据丢失;
- appendfsync=always: 同步持久化,每次发生数据变更会被立即记录到磁盘,性能较差但数据完整性比较好;

3.2.2 Rewrite

AOF 采用文件追加方式,文件会越来越大,为避免出现此种情况,新增了重写机制,当AOF文件的大小超过所设定的阈值时,
Redis就会启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集,可以使用命令bgrewriteaof;
重写原理:AOF文件持续增长而过大时,会fork出一条新进程来将文件重写(也是先写临时文件最后再rename),遍历新进
程的内存中数据;重写aof文件的操作,并没有读取旧的aof文件,而是将整个内存中的数据库内容用命令的方式重写了一
个新的aof文件,这点和快照有点类似;
触发机制:Redis会记录上次重写时的AOF大小,默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发;

3.2.3 AOF 优势和劣势

优势:
- 同步持久化,appendfsync=always;
- 每修改同步,appendfsync=everysec;
劣势:
- 相同数据集的数据而言,aof文件要远大于rdb文件,恢复速度慢于rdb;
- AOF运行效率要慢于rdb,每秒同步策略效率较好,不同步效率和rdb相同;

3.3 RDB 和 AOF

RDB 持久化方式能够在指定的时间间隔,对数据进行快照存储;
AOF 持久化方式记录每次对服务器写的操作,当服务器重启的时候,会重新执行这些命令来恢复原始的数据,AOF 命令
以redis协议追加保存每次写的操作到文件末尾,Redis 还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大;
同时开启两种持久化方式:
- 在这种情况下,当redis重启的时候,会优先加载AOF文件来恢复原始的数据,因为在通常情况下,AOF文件保存的数
  据集要比RDB文件保存的数据集完整;

4. Redis 的事务

4.1 事务
- 事务本质上是一组命令的集合;一个事务中的所有命令都会序列化,按顺序地串行化执行而不会被其他命令插入,不许加塞;
4.2 常用命令
- MULTI: 标记一个事务块的开始;
- EXEC: 执行所有事务块内的命令;
- DISCARD: 取消事务,放弃执行事务块内的所有命令;
- WATCH: 监控一个(或多个)key,如果在事务执行之前,这个(或这些)key被其他命令所改动,那么事务将被打断;
- UNWATCH: 取消WATCH命令对所有key的监视;

4.3 事务的执行情况:
- 正常执行
- 放弃事务
- 全体连坐:不管命令正确错误,都不执行;
- 冤头债主:错误的命令不执行,正确的命令执行;
- watch监控

4.4 Redis 事务的三阶段
- 开启: 以MULTI开始一个事务;
- 入队: 将多个命令入队到事务中,接到这些命令并不会立即执行,而是放到等待执行的事务队列里面;
- 执行: 以EXEC命令触发事务;

4.5 Redis 事务的三个特性
- 单独的隔离操作:事务中的所有命令都会序列化,按顺序地执行;事务在执行的过程中,不会被其他客户端发送来的命令请求所打断;
- 没有隔离级别的概念:队列中的命令,在没有提交之前不会实际的被执行,因为事务提交前任何指令都不会被实际执行,
也就不存在"事务内的查询要看到事务里的更新,在事务外查询不能看到"这个让人万分头痛的问题;
- 不保证原子性:redis同一个事务中,如果有一条命令执行失败,其他的命令仍然会被执行,没有回滚;

5. Redis 的发布/订阅

Redis 的发布/订阅:进程间的一种信息通信模式,发送者(pub)发送消息,订阅者(sub)接收消息;

6. Redis 主从复制(Master/Slave)

6.1 概述

主从复制: 主机数据更新后,根据配置和策略,自动同步到备机的master/slave机制,Master以写为主,Slave以读为主;

6.2 应用

读写分离
容灾备份

6.3 使用方法

配从(库)不配主(库);
从库配置: slaveof 主库IP 主库端口
- 每次与master断开之后,都需要重新连接,除非配置进redis.conf文件;
- info replication: 查看当前库的状态;
修改配置文件
- 拷贝多个 redis.conf 文件;
- 设置 daemonize yes, Pid 文件名字, 指定端口, Log文件的名字, Dump.rbd名字;
常用3招
- 一主二从(一个Master,两个Slave)
- 薪火相传
  - 上一个Slave可以是下一个Slave的Master,Slave同样可以接收其他Slaves的连接和同步请求,那么,该
    Slave就是下一个Slave的Master,这样,可以有效减轻master的写压力;
  - 中途变更转向:会清除之前的数据,重新建立拷贝最新的; slaveof 新主库IP 新主库端口;
- 反客为主
  - slaveof no one
  - 使当前数据库停止与其他数据库的同步,转成主数据库;
复制原理
- slave 成功连接到master后,会发送一个sync命令;
- Master 接到命令,启动后台的存盘进程,同时,收集所有接收到的用于修改数据集命令,在后台进程执行完毕之后,
  master 将传送整个数据文件到slave,以完成一次完全同步;
- 全量复制:slave 服务在接收到数据库文件数据后,将其存盘并加载到内存中;
- 增量复制:Master继续将新的所有收集到的修改命令依次传给slave,完成同步;
- 但是,只要是重新连接master,一次完全同步(全量复制)将被自动执行;
- 复制的缺点:复制的延时;由于所有的写操作都是先在Master上操作,然后同步更新到Slave上,所以从Master同步
  到slave机器有一定的延迟,当系统很繁忙的时候,延迟问题会更加严重,Slave机器数量的增加也会使这个问题更加严重;
哨兵模式(Sentinel)
- "反客为主"的自动版,能够后台监控主机是否故障,如果发生故障,根据投票数自动将从库转换为主库;
- 使用步骤
  - 配置 sentinel.conf, 具体参考地址
- 一个sentinel能同时监控多个Master;

7. Jedis 使用

7.1 导 jar 包

Commons-pool-1.6.jar
Jedis-2.1.0.jar

7.2 编写测试类

transaction.decrBy() === 余额减去amtToSubtract的钱数.

transaction.incrBy() === 信用卡欠款增加amtToSubtract的钱数.

参考资料

posted @ 2019-07-03 14:22 双间阅读(454) 评论(0) 编辑收藏举报

刷新页面返回顶部

双间