redis的基本工作原理

数据是从内存中读写的

为了防止重启数据丢失所以：

• 把增量数据保存在AOF文件中
• 把全局数据保存在RDB文件中

AOF

rdb

除此之外，redis单线程处理命令

情景案例

1 连续签到

例如用户每天一次的签到机会，如果断签，连续签到天数为0

• key:cc_uid_11658964464
• value:252
• expireAt:0点

可以使用string结构来存储，这个结构可以存储字符串、数字和二进制数据

场景：存储技术、session

结构：

2. 消息通知

可以使用list作为消息队列

例如当有文章进行更新时，将更新的文章推送到es，用户就可以搜索到最新的文章数据

list的数据结构： quicklist

quicklist是由双向链表和listpack实现

3 计数

一个用户有多个计数要求，可以使用hash来实现

hash的底层数据结构

数组+链表 具体如下所示

rehash

rehash操作是将ht[0]中的数据，全部迁移到ht[1]中。数据量小的场景下,直接将数据从ht[o]拷贝到ht[1]速度是较快的。数据量大的场景,例如存有上百万的KV时，迁移过程将会明显阻塞用户请求。

渐进式rehash

为避免出现这种情况，使用了rehash方案。基本原理就是,每次用户访问时都会迁移少量数据。将整个迁移过程,平摊到所有的访问用户请求过程中。

4排行榜

积分变化时，排名要实时更新

zset的数据结构：zskiplist 由 跳表和哈希表共同完成

实现方式：Redis sorted set的内部使用HashMap和跳跃表(skipList)来保证数据的存储和有序，HashMap里放的是成员到score的映射，而跳跃表里存放的是所有的成员，排序依据是HashMap里存的score，使用跳跃表的结构可以获得比较高的查找效率，并且在实现上比较简单。

5 限流

要求1秒内的请求为n，超过n就禁止访问

• key: comment_freq_limit_484136989
• 调用incr，超过限制N就禁止访问
• 484136989：时间戳

大key，热key

大key的危害

• 读取成本高
• 容易导致慢查询
• 主从复制异常，服务阻塞，无法响应正常请求

业务端使用大key的表现

请求redis超时报错

解决办法

1、拆分

2、压缩

3 集合类结构hash、list、set、zzset

（1）拆分：可以用hash取余，位掩码方式巨额并放在哪个key中 （2）区分冷热：如榜单列表场景中使用zset，只缓存前10页数据，后续走db

热key

用户访问一个Key的QPS特别高，导致Server实例出现CPU负载突增或者不均的情况。 热key没有明确的标准，QPS超过500就有可能被识别为热Key

所有的请求都到了第一个上

解决办法

1、localcache

在访问Redis前，在业务服务侧设置Localcache,降低访问Redis的QPS。LocalCache中缓存过期或未命中则从Redis中将数据更新到LocalCache。Java的Guava,Golang的Bigcache就是这类LocalCache

2、拆分

将key : value这一个热Key复制写入多份，例如key1 : value,key2:value，访问的时候访问多个key，但value是同一个以此将qps分散到不同实例上，降低负载。代价是，更新时需要更新多个key，存在数据短暂不一致的风险

缓存穿透

热点数据绕过缓存，直接查询数据库

解决

缓存雪崩

大量缓存同时过期

解决

(1)缓存空值

将缓存失效时间分散开，比如在原有的失效时间基础上增加一个随机值，例如不同Key过期时间. 可以设置为10分1秒过期，10分23秒过期，10分8秒过期。单位秒部分就是随机时间，这样过期时间就分散了.对于热点数据，过期时间尽量设置得长一些，冷门的数据可以相对设置过期时间短一些。

(2)使用**缓存集群,**避免单机宕机造成的缓存雪崩。