1.redis的五种基本类型
Redis中使用key:value的形式
登录的时候:redis-cli -h ip -p port
auth password
1.1 string
set 和get 指令:
127.0.0.1:6379> set stringkey1 1
OK
127.0.0.1:6379> incr set
(integer) 1
127.0.0.1:6379> incr stringkey1
(integer) 2
127.0.0.1:6379> incr stringkey1
(integer) 3
127.0.0.1:6379> get stringkey1
"3"
127.0.0.1:6379> decr stringkey1
(integer) 2
127.0.0.1:6379> get stringkey1
"2"
自增和自减,可以适用于计数器的作用
1.2 hash
hash类型下的value只能存储字符串,不允许存储其他类型数据,不存在嵌套现象。如果数据未获取到,对应的值为(nil)
key: field1 value1 field2 value2
127.0.0.1:6379> hset hashkey1 name "cz" age 32
(integer) 2
127.0.0.1:6379> hgetall hashkey1
1) "name"
2) "cz"
3) "age"
4) "32"
127.0.0.1:6379> hget hashkey1 name
"cz"
127.0.0.1:6379> hget hashkey1 age
"32"
hash可以用于购物车,key是用户的id,field是某个商品的id,value是对应的数量
1.3 list
数据存储需求:存储多个数据,并对数据进入存储空间的顺序进行区分
需要的存储数据:一个存储空间保存多个数据,且通过数据可以体现进入顺序
list类型:保存多个数据,底层使用双向链表存储结构实现
127.0.0.1:6379> lpush listkey1 123
(integer) 1
127.0.0.1:6379> lpush listkey1 234
(integer) 2
127.0.0.1:6379> lpop listkey1
"234"
127.0.0.1:6379> rpop listkey1
"123"
先进先出多用于队列的作用,比如朋友圈的按顺序点赞,key是对应的你的帐号,lpush是对应的点赞的人,lpop是取消对应的点赞。
1.4 Set
127.0.0.1:6379> sadd users s1
(integer) 1
127.0.0.1:6379> sadd users s2
(integer) 1
127.0.0.1:6379> sadd users s3
(integer) 1
127.0.0.1:6379> smembers users
1) "s3"
2) "s1"
3) "s2"
127.0.0.1:6379> sadd users s1
(integer) 0.
127.0.0.1:6379> sadd users s2
(integer) 0
返回0表示已经存在该值
可以用于点赞功能
使用sadd,srem实现。
sadd key member,往集合key中添加member元素。如果集合中没有此member,添加成功,返回1,表示点赞成功。如果集合中有此member,添加失败,返回0,表示点赞无效(不能重复点赞)。
srem key member,移除集合key中的member元素,表示取消点赞。
还可以随机获取集合key中的元素:
127.0.0.1:6379> SRANDMEMBER users 1
1) "s1"
127.0.0.1:6379> SRANDMEMBER users 1
1) "s3"
127.0.0.1:6379> SRANDMEMBER users 1
1) "s2"
应用于随机推荐类信息检索,例如热点歌单推荐,热点新闻推荐,热点旅游线路,应用APP推荐,大V推荐等。
1.5 SortedSet
排序的集合
应用于热搜top10等需要按照某种属性进行排序的场景
127.0.0.1:6379> zadd exam 90 cz
(integer) 1
127.0.0.1:6379> zadd exam 85 lt
(integer) 1
127.0.0.1:6379> zadd exam 95 cbh
(integer) 1
127.0.0.1:6379> zadd exam 100 cbh1
(integer) 1
127.0.0.1:6379> zrange exam 0 -1
1) "lt"
2) "cz"
3) "cbh"
4) "cbh1"
127.0.0.1:6379> zrevrange exam 0 -1
1) "cbh1"
2) "cbh"
3) "cz"
4) "lt"
127.0.0.1:6379>
对于应用的更多场景可以参看:
https://blog.csdn.net/qq_39595769/article/details/121810180
2.redis为什么速度快?
1.由于完全是对内存的操作
2.单线程,避免了上下文的切换
3.非阻塞Io,多路Io复用
这里多路指的是多个网络连接,复用指的是复用同一个线程。采用多路 I/O 复用技术可以让单个线程高效的处理多个连接请求(尽量减少网络 IO 的时间消耗)
redis的文件处理器包含:多个套接字,IO多路复用,事件处理器等
3. redis的持久化
1.RDB
在指定的时间间隔内将内存中的数据集快照写入磁盘,也就是行话讲的Snapshot快照,它恢复时是将快 照文件直接读到内存里。
Redis会单独创建(fork)一个子进程来进行持久化,会先将数据写入到一个临时文件中,待持久化过程 都结束了,再用这个临时文件替换上次持久化好的文件。整个过程中,主进程是不进行任何IO操作的。 这就确保了极高的性能。如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那 RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。默认的就是RDB,一般情况下不需要修改这个配置!
触发的机制:
1.save的规则满足的情况下,会自动触发RDB规则,生成我们的RDB文件!
2.执行flushall命令,也会触发我们的RDB规则,生成我们的RDB文件!
3.退出redis,也会产生RDB文件!
4.内存淘汰策略
All-keys-lru :当内存不足时,移除最近最少使用的key
All-keys-random:当内存不足时,随机移除key
volatile-lru:在过期的键空间中,移除最近最少使用的
volatile-random:在过期的键空间中,随机移除key
volatile-ttr:在过期的键空间中,删除设置过期时间最久的
5.集群模式
三种:主从,哨兵,切片集群
1.主从
1.每个redis运行后都会有一个runId,runId可以确定对应哪个redis
2.主和从都会有一个offset的量,用于维护同步消息时的偏移量
从服务器首次加入集群中,会有一个全量同步的过程:
从向主发送同步请求,
主将对应runId和offset发送至从
然后主开始通过bgsave命令生成RDB文件
然后将rdb文件复制到从,从开始恢复数据
主再将生成rdb文件过程中保存至缓存的replication buffer的数据也同步至从整个过程完成。
2.哨兵
主要负责:监控,选主,同步,一般以集群的方式存在
监控主和从的状态,当主节点挂了,当大多数哨兵检测到主节点挂了,此时就要进行选主的操作了。
选主:哨兵状态有follower,condinate,leader,follower。只能接收来自condinate和leader的消息;condinate是follower在接收不到消息以后就会自动变成的,然后发其一次选举,若哨兵集群中大多数都同意,那么他就会变为leader。
故障转移:之后开始由leader开始选主。
消息通知:哨兵和哨兵相互发现是通过主节点的pub/sub方式发现
哨兵与丛库也是通过主节点进行的,通过主库向主节点发送INFO指令,主库会将从库的列表发挥给哨兵。哨兵提升一个从库为新主库后,哨兵会把新主库的地址写入自己实例的 pubsub(switch-master) 中。客户端需要订阅这 个pubsub,当这个 pubsub 有数据时,客户端就能感知到主库发生变更,同时可以拿到最新的主库地址,然后把写请求写到这个新主库即可,这种机制属于哨兵主动通知客户端。
3.Redis Cluster方案
1、Redis Cluster方案采用哈希槽来处理 KEY 在不同实例中的分布,一个切片集群共有16384个哈希槽,这些哈希槽类似于数据分区,每个键值对都会根据它的key,被映射到一个哈希槽中。
2、一个 KEY ,首先会根据CRC16算法计算一个16 bit的值;然后,再用这个 16bit 值对 16384 取模,得到0~16383范围内的模数,每个模数代表一个相应编号的哈希槽。
3、然后把哈希槽分配到所有的实例中,例如,如果集群中有N个实例,那么,每个实例上的槽个数为16384/N个。