Redis常用数据类型+redis三大集群模式搭建详解

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服务器开启时,会把磁盘中的数据加载到内存中进行计算。

提高了两种持久化方式:

扫描二维码关注公众号,回复: 16763618 查看本文章

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优缺点:

  1. 优点: 数据完整性高---丢失最后一条指令。

  2. 缺点: 数据恢复慢。

如果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

猜你喜欢

转载自blog.csdn.net/yhl15736773842/article/details/131502282