目录
一、数据类型
redis 有以下几种数据类型:
- string
- hash
- list
- set
- sorted set
String
这是最简单的类型,就是普通的 set 和 get,做简单的 key value 缓存。
set [key] [value]
get [key]
del [kay]
Hash
这个是类似 map 的一种结构,这个一般就是可以将结构化的数据,比如一个对象(里面有比如:name、age、id等字段)给缓存在 redis 里,然后每次读写缓存的时候,可以就操作 hash 里的某个字段。
hset [person] [name] [zhangsan]
hset [person] [age] [23]
hset [person] [id] [1996]
hget [person] [name]
hdel [person] [name]
person = {
“name”: “zhangsan”,
“age”: 23,
“id”: 1996
}
List
list 是有序列表,这个可以玩儿出很多花样。
比如可以通过 list 存储一些列表型的数据结构,类似粉丝列表、文章的评论列表之类的东西。
比如可以通过 lrange 命令,读取某个闭区间内的元素,可以基于 list 实现分页查询,这个是很棒的一个功能,基于 redis 实现简单的高性能分页,可以做类似微博那种下拉不断分页的东西,性能高,就一页一页走。
0开始位置,-1结束位置,结束位置为-1时,表示列表的最后一个位置,即查看所有。
lrange mylist 0 -1
比如可以搞个简单的消息队列,从 list 头怼进去,从 list 尾巴那里弄出来。
lpush mylist 1
lpush mylist 2
lpush mylist 3 4 5
rpop mylist
Set
set 是无序集合,自动去重。
直接基于 set 将系统里需要去重的数据扔进去,自动就给去重了,如果你需要对一些数据进行快速的全局去重,你当然也可以基于 jvm 内存里的 HashSet 进行去重,但是如果你的某个系统部署在多台机器上呢?得基于 redis 进行全局的 set 去重。
可以基于 set 玩儿交集、并集、差集的操作,比如交集吧,可以把两个人的粉丝列表整一个交集,看看俩人的共同好友是谁?对吧。
把两个大 V 的粉丝都放在两个 set 中,对两个 set 做交集。
#-------操作一个set-------
#添加元素
sadd mySet 1
#查看全部元素
smembers mySet
#判断是否包含某个值
sismember mySet 3
#删除某个/些元素
srem mySet 1
srem mySet 2 4
#查看元素个数
scard mySet
#随机删除一个元素
spop mySet
#-------操作多个set-------
#将一个set的元素移动到另外一个set
smove yourSet mySet 2
#求两set的交集
sinter yourSet mySet
#求两set的并集
sunion yourSet mySet
#求在yourSet中而不在mySet中的元素
sdiff yourSet mySet
Sorted set
sorted set 是排序的 set,去重但可以排序,写进去的时候给一个分数,自动根据分数排序。
zadd board 85 zhangsan
zadd board 72 lisi
zadd board 96 wangwu
zadd board 63 zhaoliu
#获取排名前三的用户(默认是升序,所以需要 rev 改为降序)
zrevrange board 0 3
#获取某用户的排名
zrank board zhaoliu
二、持久化机制
RDB
快照模式(RDB)可以将某一时刻的所有数据都写入硬盘中,当然这也是redis的默认持久化方式,保存的文件是以.rdb形式结尾的文件因此这种方式也称之为RDB方式
快照模式是默认的Redis持久化方案,根据redis.conf中的配置,快照将被写入dbfilename指定的文件里面(默认是dump.rdb文件中)
创建快照的几种方式:
-
客户端可以使用BGSAVE命令来创建一个快照,当接收到客户端的BGSAVE命令时,redis会调用fork¹来创建一个子进程,然后子进程负责将快照写入磁盘中,而父进程则继续处理命令请求
-
客户端还可以使用SAVE命令来创建一个快照,接收到SAVE命令的redis服务器在快照创建完毕之前将不再响应任何其他的命令
【注意】 SAVE命令并不常用,使用SAVE命令在快照创建完毕之前,redis处于阻塞状态,无法对外服务
优点
对性能影响小
RDB文件进行数据恢复比AOF快
缺点
持久化数据有时间间隔,可能有丢失数据风险
AOF
这种方式可以将所有客户端执行的写命令记录到日志文件中
AOF持久化会将被执行的写命令写到AOF的文件末尾,以此来记录数据发生的变化,因此只要redis从头到尾执行一次AOF文件所包含的所有写命令,就可以恢复AOF文件的记录的数据集
配置AOF
- 通过修改redis.conf配置中appendonly yes来开启AOF持久化
- 通过appendfilename指定日志文件名字(默认为:appendonly.aof)
- 通过appendfsync指定日志记录频率
AOF记录日志频率
选项 | 同步频率 |
---|---|
always | 每个redis写命令都要同步写入硬盘,严重降低redis速度 |
everysec | 每秒执行一次同步显式的将多个写命令同步到磁盘 |
no | 由操作系统决定何时同步 |
三、事务
概述
相信学过Mysql等其他数据库的同学对事务这个词都不陌生,事务表示的是一组动作,这组动作要么全部执行,要么全部不执行。为什么会有这样的需求呢?看看下面的场景:
微博是一个弱关系型社交网络,用户之间有关注和被关注两种关系,比如两个用户A和B,如果 A关注B,则B的粉丝中就应该有A。关注这个动作需要两个步骤完成:在A的关注者中添加B;在B的粉丝中添加A。 这两个动作要么都执行成功,要么都不执行。否则就可能会出现A关注了B,但是B的粉丝中没有A的不可容忍的情况。
转账汇款,假设现在有两个账户A和B,现在需要将A中的一万块大洋转到B的账户中,这个动作也需要两个步骤完成:从A的账户中划走一万块;在B的账户中增加一万块。这两个动作要么全部执行成功,要么全部不执行,否则自会有人问候你的!!!
事务
Redis中的事务(transaction)是一组命令的集合。事务同命令一样都是Redis最小的执行单位,一个事务中的命令要么都执行,要么都不执行。Redis事务的实现需要用到 MULTI 和 EXEC 两个命令,事务开始的时候先向Redis服务器发送 MULTI 命令,然后依次发送需要在本次事务中处理的命令,最后再发送 EXEC 命令表示事务命令结束。
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set url http://qifuguang.me
QUEUED
127.0.0.1:6379> set title winwill2012
QUEUED
127.0.0.1:6379> set desc java
QUEUED
127.0.0.1:6379> EXEC
1) OK
2) OK
3) OK
127.0.0.1:6379>
127.0.0.1:6379> get url
"http://qifuguang.me"
127.0.0.1:6379> get title
"winwill2012"
127.0.0.1:6379> get desc
"java"
127.0.0.1:6379>
从输出中可以看到,当输入MULTI命令后,服务器返回OK表示事务开始成功,然后依次输入需要在本次事务中执行的所有命令,每次输入一个命令服务器并不 会马上执行,而是返回”QUEUED”,这表示命令已经被服务器接受并且暂时保存起来,最后输入EXEC命令后,本次事务中的所有命令才会被依次执行,可 以看到最后服务器一次性返回了三个OK,这里返回的结果与发送的命令是按顺序一一对应的,这说明这次事务中的命令全都执行成功了。
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set a a
QUEUED
127.0.0.1:6379> sett b b
(error) ERR unknown command 'sett'
127.0.0.1:6379> set c c
QUEUED
127.0.0.1:6379> EXEC
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379> get a
(nil)
127.0.0.1:6379> get b
(nil)
127.0.0.1:6379> get c
(nil)
127.0.0.1:6379>
和前面的例子一样,先输入MULTI最后输入EXEC表示中间的命令属于一个事务,不同的是中间输入的命令有一个错误(set写成了sett),这样因为 有一个错误的命令导致事务中的其他命令都不执行了(通过后续的get命令可以验证),可见事务中的所有命令式同呼吸共命运的。
如果客户端在发送EXEC命令之前断线了,则服务器会清空事务队列,事务中的所有命令都不会被执行。而一旦客户端发送了EXEC命令之后,事务中的所有命令都会被执行,即使此后客户端断线也没关系,因为服务器已经保存了事务中的所有命令。
除了保证事务中的所有命令要么全执行要么全不执行外,Redis的事务还能保证一个事务中的命令依次执行而不会被其他命令插入。试想一个客户端A需要执行 几条命令,同时客户端B发送了几条命令,如果不使用事务,则客户端B的命令有可能会插入到客户端A的几条命令中,如果想避免这种情况发生,也可以使用事 务。
四、Redis内存满了这么办?
redis是基于内存存储的,系统内存也是有限的,在使用redis的时候也可以配置内存大小。默认在64位操作系统下不限制内存大小,在32位操作系统下最多使用3GB内存
1、通过配置文件配置
设置Redis最大占用内存大小为100M
maxmemory 100mb
2、通过命令修改
设置Redis最大占用内存大小为100M
127.0.0.1:6379> config set maxmemory 100mb
获取设置的Redis能使用的最大内存大小
127.0.0.1:6379> config get maxmemory
五、Redis内存淘汰机制
-
noeviction(默认策略):对于写请求不再提供服务,直接返回错误(DEL请求和部分特殊请求除外)
-
volatile-lru:根据LRU算法生成的过期时间来删除。
-
allkeys-lru:根据LRU算法删除任何key。
-
volatile-random:根据过期设置来随机删除key。
-
allkeys-random:无差别随机删。
-
volatile-ttl:根据最近过期时间来删除(辅以TTL)
六、Redis主从复制
准备三台机器分别修改redis配置文件中
Master:
Slaveof1:
Slaveof2:
七、Redis哨兵模式
1.哨兵:能够后台监控Master库是否故障,如果故障了根据投票数自动将slave库转换为主库。一组sentinel能监听多个master
2.Sentinel搭建
- 在Master对应redis.conf同目录下新建sentinel.conf文件,名字绝对不能错;
- 配置哨兵,在sentinel.conf文件中填入内容:
sentinel monitor 被监控数据库名字(自己起名字) ip port 1 - 启动哨兵模式:
命令键入:redis-sentinel /myredis/sentinel.conf
说明:这个后面的数字2,是指当有两个及以上的sentinel服务检测到master宕机,才会去执行主从切换的功能。
八、Redis集群搭建
注意 :
1.判断一个是集群中的节点是否可用,是集群中的所用主节点选举过程,如果半数以上的节点认为当前节点挂掉,那么当前节点就是挂掉了,所以搭建redis集群时建议节点数最好为奇数.
2.搭建集群至少需要三个主节点,三个从节点,至少需要6个节点
安装redis集群需要版本号在3.0以上redis-cluster安装前需要安装ruby环境搭建集群需要使用到官方提供的ruby脚本。需要安装ruby的环境。
yum install -y ruby rubygems
gem install redis
创建7个文件夹
向每个目录中复制一个redis的配置文件
修改配置文件以下内容:
port 7000,7001,7002…7007 //每个配置文件的端口号
cluster-enabled yes //开启集群模式
cluster-config-file nodes-.conf //集群节点配置文件
cluster-node-timeout 5000 //集群节点超时时间
appendonly yes //开启AOF持久化
启动所有节点
使用redis安装目录中src目录下的redis-trib.rb如下命令
./redis-trib.rb create --replicas 1 192.168.68.128:7000 192.168.68.128:7001 192.168.68.128:7002 192.168.68.128:7003 192.168.68.128:7004 192.168.68.128:7005
执行如下命令会出现如下状态
输入yes后集群确定搭建,输入其它命令不创建集群
客户端操作集群
查看集群节点的状态
使用./redis-trib.rb check 主机:集群中任意节点
集群节点的操作
使用./redis-trib.rb add-node 192.168.1.158:7006 192.168.1.158:7005
注意 :
1.该节点必须以集群模式启动
2.默认情况下该节点就是以master节点形式添加,但是该节点没有hashslots
九、SpringBoot操作Redis
https://blog.csdn.net/qq_37504376/article/details/103863586