这是我参与「第五届青训营 」伴学笔记创作活动的第16天
为什么需要Redis
数据从单表，演进出了分库分表
MySQL从单机演进出了集群 数据量增长 读写数据压力的不断增加
数据分冷热 热数据:经常被访问到的数据
将热数据存储到内存中
Redis基本工作原理
数据从内存中读写
数据保存到硬盘上防止重启数据丢失
增量数据保存到AOF文件
String数据结构
数据结构-sds 可以存储字符串、数字、二进制数据 通常和expire配合使用 场景:存储计数、Session
Hash数据结构dict
rehash : rehash操作是将ht[0]中的数据，全部迁移到ht[1]中。数据量小的场景下,直接将数据从ht[0]拷贝到ht[1]速度是较快的。数据量大的场景，例如存有上百雷万的KV时，迁移过程将会明显阻塞用户请求。
渐进式rehash:为避免出现这种情况，使用了rehash方案。基本原理就是,每次yon用户访问时都会迁移少量数据。将整个迁 移过程，平摊到所有的访问用请求过程中。
排行榜
积分变化时，排名要实时变更
结合dict后，可实现通过key操作跳表的功能 ZINCRBY myzset 2 "Alex" zSCORE myzset "Alex"
zset数据结构zskiplist
查找数字7的路径，head ,3,3,7 结合dict后，可实现通过key操作跳表的功能 ZINCRBY myzset 2 "Alex" .zSCORE myzset "Alex"
限流
要求1秒内放行的请求为N，超过N则禁止访问
Key: comment_freq_limit_1671356046
对这个Key调用incr，超过限制N则禁止访问 1671356046是当前时间戳
分布式锁
并发场景,要求一次只能有一个协程执行。执行完成后.其它等待中的协程才能执行。
可以使用redis的setnx实现，利用了两个特性Redis是单线程执行命令 setnx只有未设置过才能执行成功
大Key、热Key
大Key的危害
读取成本高 容易导致慢查询(过期、删除)主从复制异常,服务阻塞 无法正常响应请求
业务侧使用大Key的表现
请求Redis超时报错
