1. Redis其他数据类型
1.1 hash数据类型
它的value就是一个hash类型,而hash类型的结构key value形式。一般用于存放对象数据。
hset key field value [field value]: 将哈希表 key 中的字段 field 的值设为 value hget key field: 获取存储在哈希表中指定字段的值。
hgetall key: 获取在哈希表中指定 key 的所有字段和值
hkeys key: 获取所有哈希表中的字段
hvals key: 获取哈希表中所有值
hdel key field: 删除一个或多个哈希表字段
1.2 List<列表>数据类型
它的value是一个List数据类型,value可以是多个,而且有序,可以重复。
lpush key element [element...]: 在列表中添加一个或多个值
Lindex key index: 获取列表中指定下标的元素。
lrange key start end: 获取一定范围的元素。第一个为0 最后-1
lpop key: 移除左边第一个元素
lset key index element: 替换指定位置的元素内容
1.3 Set 数据类型
它和list类型差不多,只是它的值不允许重复,而且是无序。
sadd key element[element....]: 在集合中添加一个或多个值
smembers key: 获取集合中所有的元素。
sinter key1 key2: 返回给定所有集合的交集
sdiff key1 key2: 返回给定所有集合
1.4 sort set 数据类型
它和set比较相似,它在添加元素时,指定了分数值,按照分数排序。排行榜。
zadd key score element [score element ...]:添加有序集合元素
zrange key start end [withscopes]: 从小到大的形式获取集合中的元素
zrevrange key start end [withscopes]: 从大到小的形式获取集合中的元素
zrem k1 element [element]: 移除集合中一个或多个元素
2. redis实际开发的应用场景
1、热点数据的缓存: 减少对数据库的访问频率和减轻数据库的压力。
2. 限时业务的运用: 秒杀 存储登录者用户信息 存储短信验证码
3. 计数器相关问题: 点赞数 收藏数 播放量。
4. 排行榜相关问题: sort set
5. 分布式锁: ---同步锁:
6. 限量秒杀: ---decr key:
3. redis的持久化
把内存中的数据持久化到磁盘中,防止数据丢失。---当redis服务器开启时,会把磁盘中的数据加载到内存中进行计算。
提高了两种持久化方式:
RDB和AOF.
3.1 RDB持久化
它是每隔一段时间进行快照存储。--它是一个二进制文件,里面的内容打开后无法看懂。
触发机制:
[1]save---手动触发
[2]bgsave--手动触发
[3]通过配置文件--自动触发
(1)save触发
该命令会阻塞当前Redis服务器,执行save命令期间,Redis不能处理其他命令,直到RDB过程完成为止。具体流程如下:
bgsave:
执行该命令时,Redis会在后台异步进行快照操作,快照同时还可以响应客户端请求。具体流程如下:
bgsave在执行该命令时会fork出一个新的线程,单独执行rdb持久化操作,而不影响其他客户对redis服务的操作。
bgsave在执行该命令时会fork出一个新的线程,单独执行rdb持久化操作,而不影响其他客户对redis服务的操作。
RDB快照持久化优缺点:
优点: ----数据恢复速度快。
缺点: ----数据完整性差--会丢失最后一段时间的数据。
3.2 AOF持久化
日志追加持久化,当我们执行写操作,会触发一个函数write,把会把写操作的命令追加到一个日志文件appendfile中。当服务器启动时会把appendfile中的命令从新执行一遍。默认不开启。
手动开启aof模式。
AOF优缺点:
优点: 数据完整性高---丢失最后一条指令。
缺点: 数据恢复慢。
如果rdb和aof都使用,当服务器重启时会加载哪个文件?
先加载AOF的文件【它以数据完整性为主】。
4. redis集群模式
提供了三种集群模式.
[1]主从模式
[2]哨兵模式
[3]集群模式
为什么要使用集群模式:
[1]解决单机故障问题 [2]解决单机压力问题
4.1 主从模式
配从不配主:非常简单。
准备: 一台linux服务。 开三个redis服务----通过修改port----6380 [主] 6381 6382[从]。
修改: 1.port端口号 2.rdb文件名dump638X.rbd 3.关闭aof
启动上面三个redis服务
redis-server redis6380.conf redis-server redis6381.conf redis-server redis6382.conf
进入相应的客户端
查看每个redis服务的角色:
发现他们都是master角色,如何分配主从关系:
配从不配主: slaveof 主节点ip 主节点port
主节点修改数据时,主节点的数据会同步到所有的从节点。
从节点只能进行读操作,不能执行写操作。
如果主节点宕机,从节点会不会篡位?---不会自动上位。
4.2 哨兵模式
由于上面主从模式,主节点宕机后,从节点不会自动上位,这段时间内无法进行写操作了。
解决上面的问题:----哨兵模式---->【1】监控功能 【2】故障恢复 【3】选举一个master主节点
4.2.1 监控功能
4.2.2 master节点的选举
4.2.3 启动哨兵
修改哨兵的配置:
启动哨兵模式: redis-sentinel sentinel.conf
测试: 使用shutdown让主节点宕机 观察sentinel的控制台
如果原来的master回来,跟着现在的master混。
5. 集群模式
不管是主从模式还是哨兵模式,始终只有一个master主节点。如果写操作并发高. 势必会导致master节点的压力过大。
真正的集群:
存储原理:
redis 集群中内置了 16384 个哈希槽,当需要在 Redis 集群中放置一个 key-value时,redis 先对 key 使用 crc16 算法算出一个整数结果,然后把结果对 16384 求余数,这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽,redis 会根据节点数量大致均等的将哈希槽映射到不同的节点。
当你往Redis Cluster中加入一个Key时,会根据crc16(key) mod 16384计算这个key应该分布到哪个hash slot中,一个hash slot中会有很多key和value。你可以理解成表的分区,使用单节点时的redis时只有一个表,所有的key都放在这个表里;改用Redis Cluster以后会自动为你生成16384个分区表,你insert数据时会根据上面的简单算法来决定你的key应该存在哪个分区,每个分区里有很多key。
搭建三主三从:
7001~7006: 6台redis服务。
创建一个文件夹cluster存放6个redis的配置文件
修改6台redis配置文件--必须redis服务是空的
(1)端口号
(2) bind绑定---任意
(2) dump文件的名称
(3)必须开启aof模式并修改文件名
(4)开启集群模式
开启上面6台redis服务
redis-server redisXXX.conf
分槽,以及设置主从关系。
redis-cli --cluster create --cluster-replicas 1 192.168.223.147:7001 192.168.223.147:7002 192.168.223.147:7003 192.168.223.147:7004 192.168.223.147:7005 192.168.223.147:7006 -----------设置自己的IP
访问:
redis-cli -c -h 192.168.223.155 -p 7001