大厂程序员是怎么用Redis的 | 青训营笔记

plutoyty
108 阅读7分钟

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

什么是Redis

为什么需要Redis？

数据从单表，演进出了分库分表 MySQL从单机演进出了集群 数据量增长 读写数据压力的不断增加

image.png

数据分为冷数据和热数据， 将热数据放到内存当中

image.png

Redis基本原理

数据从内存读写，数据保存到硬盘防止重启数据丢失

image.png 增量数据保存到AOF文件

image.png 全量数据保存到RDB文件中

image.png 单线程处理所有命令

image.png 重启时根据AOF和RDB文件恢复数据，先从RDB文件中去读取，然后去AOF中看看是不是有漏的，如果有漏的就补到RDB文件中去。

为什么 Redis 是单线程的，却能有很好的性能(根据 Amdahl’s Law，优化耗时占比大的过程，才更有意义)，两句话概括是：Redis 利用了多路 I/O 复用机制，处理客户端请求时，不会阻塞主线程；Redis 单纯执行（大多数指令）一个指令不到 1 微秒，如此，单核 CPU 一秒就能处理 1 百万个指令（大概对应着几十万个请求吧），用不着实现多线程

Redis应用案例

1.连续签到

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

image.png image.png

String数据结构 数据结构-sds

  • 可以存储字符串、数字、二进制数据
  • 通常和expire配合使用

场景:存储计数、Session

image.png len 代表字符串长度

alloc 表示buf的长度

flags 表示sds的类型，因为存储空间不同，SDS类型也不同，有很多不同类型的SDS，例如16位、32位，和len用于获取value

2.消息通知

用list作为消息队列

使用场景: 消息通知。 例如当文章更新时，将更新 后的文章推送到ES,用户就 能搜索到最新的文章数据

image.png

List数据结构Quicklist

Quucklist由双向链表和listpack实现

因为Redis尽可能的去节省空间，所有一个entry里面包含了很多节点 image.png

listpack image.png

3.计数

一个用户有多项计数需求， 可通过hash结构存储

image.png

image.png

Hash数据结构Dict

image.png

image.png

4.排行榜

积分变化时，排名要实时变更 结合dict后，可实现通过key操作跳表的功能 ZINCRBY myzset 2 "Alex ZSCORE myzset "Alex"

image.png

zsikplist数据结构 跳表和dict实现

image.png

5.限流

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

Key: comment_freq_ limit_1671356046

对这个Key调用incr,超过限制N则禁止访问 1671356046是当前时间戳

image.png

6.分布式锁

并发场景，要求一次只能有一个协程执行。 执行完成后，其它等待中的协程才能执行。

image.png 可以使用redis的setnx实现， 利用了两个特性

  • Redis是单线程执行命令
  • setnx只有未设置过才能执行成功
不是高可用的分布式锁实现

该实现存在的问题:

(1) 业务超时解锁，导致并发问题。业务执行时间超过锁超时时间

(2) redis主备切换临界点问题。主备切换后，A持有的锁还未同步到新的主节点时，B可在新主节点获取锁，导致并发问题。

(3) redis集群脑裂，导致出现多个主节点

Redis注意事项，常出现的问题

大key，热key问题

大key的定义

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

大key的危害

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

业务侧使用大Key的表现

请求Redis超时报错

image.png

消除大key

拆分

将大key拆分为小key。例如一个String拆分成多个String image.png

压缩

将value压缩后写入redis,读取时解压后再使用。压缩算法可以是gzip、snappy、lz4等。通常情况下， 一个压缩算法压缩率高、则解压耗时就长。需要对实际数据进行测试后，选择一个合适的算法。 如果存储的是JSON字符串，可以考虑使用MessagePack进行序列化。

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

  1. 拆分:可以用hash取余、位掩码的方式决定放在哪个key中
  2. 区分冷热:如榜单列表场景使用zset,只缓存前10页数据，后续数据走db

热key

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

image.png

解决热key的方法

1.设置Localcache

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

image.png

2.拆分

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

image.png

3. 使用Redis代理的热Key承载能力

字节跳动的Redis访问代理就具备热Key承载能力。本质上是结合了“热Key发现"、"LocalCache' 两个功能

image.png

慢查询场景

容易导致redis慢查询的操作

  1. 批量操作一次性传 入过多的key/value,如mset/hmset/sadd/zadd等 O(n)操作建议单批次不要超过100，超过100之 后性能下降明显。
  2. zset大部分命令都是O(log(n))，当大小超过5k以上时，简单的zadd/zrem也可能导致慢查询
  3. 操作的单个value过大，超过10KB。 也即，避免使用大Key

缓存穿透，缓存雪崩

缓存穿透:热点数据查询绕过缓存，直接查询数据库 缓存雪崩:大量缓存同时过期 缓存穿透的危害

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

如何减少缓存穿透

  1. 缓存空值 如一个不存在的userID。这个id在缓存和数据库中都不存在。则可以缓存一个空值，下次再查缓存直接反回空值。
  2. 布隆过滤器 通过bloom filter算法来存储合法Key,得益于该算法超高的压缩率，只需占用极小的空间就能存储大量key值

如何避免缓存雪崩

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