Redis的原理和应用 ｜ 青训营笔记

VanNiekerk
90 阅读7分钟

这是我参与「第五届青训营 」伴学笔记创作活动的第 17 天

为什么需要Redis

随着数据量增加和业务场景的扩充，读写数据的压力不断增加，数据从单表,演进出了分库分表MySQL从单机演进出了集群

Redis的基本工作原理

在读写命令前会产生一条AOF日志，如果命令还未执行redis宕机，那么在重启后会加载RDB(全量数据)文件和AOF文件，对比后执行AOF中未执行的命令，恢复数据

image.png

image.png

数据结构——string

在redis中,string这一数据结构使用sds(simple dynamic string),即简单的动态字符串来表示的

struct sdshdr { 
    // buf 中已占用空间的长度 
    int len; 
    // 一共分配的空间的大小
    int alloc; 
    //使用sdshdr5，sdshdr8，sdshdr16，sdshdr32和sdshdr64中的哪一种类型
    unsigned char flags;
    // 数据空间 
    char buf[]; 
};

image.png

应用——连续签到

用户每日有一次签到的机会，如果断签，连续签到计数将归0。连续签到的定义:每天必须在23:59:59前签到

  • Key : cc_uid_1165894833417101
  • value: 11
  • expireAt:后天的0点

应用——限流

要求1秒内放行的请求为N，超过N则禁止访问

  • key——commit_limit_当前时间戳（单位秒）
  • 对这个key调用incr，超过限制N则禁止访问

应用——分布式锁

并发场景，要求一次只能有一个协程执行。执行完成后,其它等待中的协程才能执行。
可以使用redis的setnx实现，利用了两个特性

  • redis是单线程执行命令
  • setnx只有未设置过才能执行成功

数据结构——list

Quicklist由一个双向链表和listpack实现
image.png listpack中可压缩存储多个元素

struct listpack<T> { 
    int32 total_bytes; // 占用的总字节数 
    int16 size; // 元素个数 
    T[] entries; // 紧凑排列的元素列表 
    int8 end; // 同 zlend 一样，恒为 0xFF 
}

image.png

应用——消息通知

用list作为消息队列，例如当文章更新时，将更新后的文章推送到ES，用户就能搜索到最新的文章数据

数据结构——hash

hash这一数据结构使用dict image.png
当拉链很长时，查找效率变低，此时需要对槽位进行扩容，这就会涉及到数据迁移的过程——rehash
rehash
rehash操作是将ht[0]中的数据,全部迁移到ht[1]中。数据量小的场景下,直接将数据从ht[0]拷贝到ht[1]速度是较快的。数据量大的场景，例如存有上百万的KV时，迁移过程将会明显阻塞用户神请求。

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

应用——计数

一个用户有多项计数需求,可通过hash结构存储
image.png

数据结构——zset

zset数据结构zskiplist

image.png

redis结合dict后，可实现通过key操作跳表的功能

  • ZINCRBY myzset 2 "Alex"
  • ZSCORE myzset "Alex"

image.png

应用——排行

排名要实时变更

image.png

使用注意事项

大key，热key

什么是大key？

  • String类型
    • value的字节数大于10KB即为大kev
  • Hash/Set/Zset/list等复杂数据结构类型
    • 元素个数大于5000个或总value字节数大于10MB即为大key

大key的危害

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

redis处理命令的步骤为read command（读取命令）, parse（解析）, execute read data（执行，读取数据）, write data（写）
value很大时，execute read data和write data会非常耗时

拆分
（1） image.png （2）拆分:可以用hash取余、位掩码的方式决定放在哪个key中 压缩
将value压缩后写入redis，读取时解压后再使用。压缩算法可以是gzip、snappy、lz4等。通常情况下，一个压缩算法压缩率高、则解压耗时就长。需要对实际数据进行测试后，选择一个合适的算法。如果存储的是JSON字符串，可以考虑使用MessagePack进行序列化。

区分冷热 如榜单列表场景使用zset，只缓存前10页数据，后续数据走db

热key

用户访问一个Key的QPS(每秒查询率)特别高，导致Server实例出现CPU负载突增或者不均的情况。热key没有明确的标准，QPS超过50O就有可能被识别为热Key
设置Localcache
在访问Redis前，在业务服务侧设置Localcache，降低访问Redis的QPS。LocalCache中缓存过期或未命中,则从Redis中将数据更新到LocalCache。Java的Guava、Golang的Bigcache就是这类LocalCache

image.png

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

慢查询

容易导致慢查询的操作

  • 批量操作一次性传入过多的key/value，如mset/hmset/sadd/zadd等o(n)操作。建议单批次不要超过100，超过100之后性能下降明显。
  • zset大部分命令都是o(log(n))，当大小超过5k以上时，简单的zadd/zrem也可能导致慢查询
  • 操作的单个value过大，超过10KB。也即，避免使用大Key
  • 对大key的delete/expire操作也可能导致慢查询，Redis4.0之前不支持异步删除unlink，大key删除会阻塞Redis

缓存穿透，缓存雪崩

  • 缓存穿透:查询一个不存在的数据，mysql查询不到数据也不会直接写入缓存，就会导致每次请求都查数据库
  • 缓存击穿:redis宕机后，或热key过期，查询绕过缓存,直接查询数据库
  • 缓存雪崩:大量缓存同时过期

缓存穿透|击穿的危害

  • 查询一个一定不存在的数据
    • 通常不会缓存不存在的数据，这类查询请求都会直接打到db，如果有系统bug或人为攻击，那么容易导致db响应慢甚至宕机
  • 缓存过期时
    • 在高并发场景下，一个热key如果过期，会有大量请求同时击穿至db，容易影响db性能和稳定。同一时间有大量key集中过期时，也会导致大量请求落到db上，导致查询变慢，甚至出现db无法响应新的查询

减少缓存穿透|击穿

  • 缓存空值
    • 如一个不存在的userID。这个id在缓存和数据库中都不存在。则可以缓存一个空值,下次再查缓存直接反空值。
  • 布隆过滤器
    • 通过bloom filter算法来存储合法Key，得益于该算法超高的压缩率，只需占用极小的空间就能存储大量key值
  • 互斥锁
    • 缓存未命中后，获取互斥锁，禁止其他线程访问，查询数据库后重新写入缓存

避免缓存雪崩

  • 将缓存失效时间分散开，比如在原有的失效时间基础上增加一个随机值，例如不同Key过期时间. 可以设置为10分1秒过期, 10分23秒过期，10分8秒过期。单位秒部分就是随机时间，这样过期时间就分散了。对于热点数据，过期时间尽量设置得长一些，冷门的数据可以相对设置过期时间短一些。
  • 使用缓存集群,避免单机宕机造成的缓存雪崩
avatar
文章
阅读
粉丝