Redis大厂程序员是怎么用的 ｜ 青训营

夹心没有饼干
142 阅读11分钟

1. Redis基本操作

  • GET/SET/DEL/INCR/SETNX
  • HSET/HGET/HINCRBY
  • LPUSH/RPOP/LRANGE
  • ZADD/ZRANGEBYSCORE/ZREVRANGE/ZINCRBY/ZSCORE

安装redis：

go get -u github.com/redis/go-redis/v9  # 支持所有的 redis 版本

连接redis：

rdb := redis.NewClient(&redis.Options{
    Addr:     "119.23.67.36:6379",
    Password: "chen123456",
    DB:       0,
})

执行 Redis 命令:

val, err := rdb.Get(ctx, "key").Result()
fmt.Println(val)

你也可以分别访问值和错误：

get := rdb.Get(ctx, "key")
fmt.Println(get.Val(), get.Err())

可以使用 Do() 方法执行尚不支持或者任意命令:

val, err := rdb.Do(ctx, "get", "key").Result()
if err != nil {
	if err == redis.Nil {
		fmt.Println("key does not exists")
		return
	}
	panic(err)
}
fmt.Println(val.(string))

2. Redis是什么

Redis（Remote Dictionary Server）是一个开源的内存数据存储系统，也称缓存数据库。

Redis 共有 5 种基本数据结构：String（字符串）、List（列表）、Set（集合）、Hash（散列）、Zset（有序集合）。

这 5 种数据结构是直接提供给用户使用的，是数据的保存形式，其底层实现主要依赖这 8 种数据结构：简单动态字符串（SDS）、QuickList（快速列表）、LinkedList（双向链表）、Hash Table（哈希表）、SkipList（跳跃表）、Intset（整数集合）、ZipList（压缩列表）。

2.1为什么需要Redis？

数据从单表演进出了分库分表。

MySQL从单机演进出了集群：数据量增长、读写数据压力不断增加。

数据分冷热，热数据是经常被访问的数据，我们希望将热数据存储到内存中。

image-20230810220627980.png

2.2 Redis基本工作原理

数据从内存中读取，读写速度非常快，是磁盘的上千倍。

单线程处理所有指令，有些业务可以借助这个逻辑：

image-20230810221455732.png

数据保存到硬盘上防止重启数据丢失（数据持久化）：

  • 快照（snapshotting，RDB），通过创建快照来获得存储在内存里面的数据在某个时间点上的副本。（全量数据）

    • save : 同步保存操作，会阻塞 Redis 主线程；
    • bgsave : fork 出一个子进程，子进程执行，不会阻塞 Redis 主线程，默认选项。

  • 只追加文件（append-only file，AOF），AOF 持久化的实时性更好。（增量数据）

    • 通过 appendonly yes 设置开启

    • 每执行一条会更改 Redis 中的数据的命令，Redis 就会将该命令写入到 AOF 缓冲区 server.aof_buf 中，然后再写入到 AOF 文件中（此时还在系统内核缓存区未同步到磁盘），最后再根据持久化方式（ fsync策略）的配置来决定何时将系统内核缓存区的数据同步到硬盘中的。

      • appendfsync always：主线程调用 write 执行写操作后，后台线程（ aof_fsync 线程）立即会调用 fsync 函数同步 AOF 文件（刷盘），fsync 完成后线程返回，这样会严重降低 Redis 的性能（write + fsync）。
      • appendfsync everysec：主线程调用 write 执行写操作后立即返回，由后台线程（ aof_fsync 线程）每秒钟调用 fsync 函数（系统调用）同步一次 AOF 文件（write+fsync，fsync间隔为 1 秒）
      • appendfsync no：主线程调用 write 执行写操作后立即返回，让操作系统决定何时进行同步，Linux 下一般为 30 秒一次（write但不fsync，fsync 的时机由操作系统决定）。
      • 从 Redis 7.0.0 开始，Redis 使用了 Multi Part AOF 机制，将原来的单个 AOF 文件拆分成多个 AOF 文件。
      • 为了兼顾数据和写入性能，可以考虑 appendfsync everysec 选项 ，让 Redis 每秒同步一次 AOF 文件，Redis 性能受到的影响较小。

    bf9784610e224382ac488f99de0e1f12tplv-k3u1fbpfcp-zoom-in-crop-mark1512000.webp

关系型数据库（如 MySQL）通常都是执行命令之前记录日志（方便故障恢复)，而 Redis AOF 持久化机制是在执行完命令之后再记录日志。

  • 避免额外的检查开销，AOF 记录日志不会对命令进行语法检查；在命令执行完之后再记录，不会阻塞当前的命令执行。
  • 也带来了风险：如果刚执行完命令 Redis 就宕机会导致对应的修改丢失；可能会阻塞后续其他命令的执行（AOF 记录日志是在 Redis 主线程中进行的）。

如何选择 RDB 和 AOF？

  • 恢复大数据集或者主从复制的时候，RDB 速度更快。
  • AOF 支持秒级数据丢失（取决 fsync 策略，如果是 everysec，最多丢失 1 秒的数据），仅仅是追加命令到 AOF 文件，操作轻量。

高可用：

  • 主从复制机制，提高可用性和负载均衡
  • 通过集群方式实现分布式存储

3. Redis应用案例

3.1 掘金连续签到

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

key: cc_uid_1165894833417101
value: 1
expireA: 后天0点

字符串数据结构：sds，Simple Dynamic Strings，Redis自定义的一个字符串类型

typedef char *sds;
  • 可以存储字符串、数字、二进制数据
  • 通常和expire配合使用
  • 场景：存储计数、session

sds有个战友sdshdr，Simple Dynamic Strings Header，它是个五胞胎，分别是sdshdr5，sdshdr8，sdshd16，sdshdr32，sdshd64。

/* 因为生的跟别人不一样（内部结构不一样），老五（sdshdr5）从来不被使用 */
struct __attribute__ ((__packed__)) sdshdr5 {
    unsigned char flags; /* 低三位表示类型, 高五位表示字符串长度 */
    char buf[];
};
struct __attribute__ ((__packed__)) sdshdr8 {
    uint8_t len; /* 字符串长度*/
    uint8_t alloc; /* 分配长度 */
    unsigned char flags; /* 低三位表示类型，高五位未使用 */
    char buf[];
};
struct __attribute__ ((__packed__)) sdshdr16 {
    uint16_t len; /* 字符串长度*/
    uint16_t alloc; /* 分配长度 */
    unsigned char flags; /* 低三位表示类型，高五位未使用 */
    char buf[];
};

sdshdr 源码中会出现(s)-(sizeof(struct sdshdr##T)))、s[-1]、(char*)s-sdsHdrSize(s[-1])这样的风骚走位，都归功于__attribute__ ((__packed__)) ，这个命令的意思是==取消编译阶段的内存优化对齐功能==。

(s)-(sizeof(struct sdshdr##T)))  // s减去sdshdr长度 = 指向sdshdr结构体的指针
s[-1]                            // s前一个位置 = flags
(char*)s-sdsHdrSize(s[-1])       // 与1相同效果

image-20230811170410189.png

3.2 消息通知

用list作为消息队列

使用场景：当文章更新时，将更新后的文章推送到ES，用户就能搜索到最新的文章数据。

image-20230811171523633.png

List数据结构： Quicklist，由一个双向链表和listpack实现：

image-20230811171715940.png

linkedlist 有 prev、next 两个指针，当存储数据很小的情况下，指针占用的空间会超过数据占用的空间，并且linkedlist 在内存中是不连续的，遍历效率低下。

为了解决linkedlist的问题，创造了 ziplist 压缩列表，是一种内存紧凑的数据结构，占用一块连续的内存空间，提升内存使用率。

0801fa0e281a4d59ac1591bd012bcc24tplv-k3u1fbpfcp-zoom-in-crop-mark1512000.webp

因为ziplist中的元素只记录了前一个元素的长度，更新的时候，会导致后续的元素都需要移动或更新，最坏的时间复杂度为 O(N2)O(N^2) 。

listpack是ziplist的优化，在 Redis 7.0 中，压缩列表数据结构已经废弃了，交由 listpack 数据结构来实现了。

listpack的数据结构：

image-20230811171737762.png

3.3 计数

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

Hash数据结构dict：

  • rehash：rehash操作是将ht[0]中的数据，全部迁移到ht[1]中。数据量小的场景下，直接将数据从ht[0]拷贝到ht[1]速度是较快的。数据量大的场景，例如存在有上百万的K-V时，迁移过程会有明显阻塞用户请求。
  • 渐进式rehash：为避免出现这种情况，每次用户访问时都会迁移少量数据，将整个迁移过程，平摊到所有的访问用户请求过程中。

image-20230811193236185.png

Hash 类似于 JDK1.8 前的 HashMap，内部实现也差不多(数组 + 链表)。不过，Redis 的 Hash 做了更多优化。

3.4 排行榜

积分变化时，排名实时变更。

image-20230811193734469.png

zset数据结构是跳跃表zskiplist:

  • 查找数字7的路径，head，3，3，7

image-20230811200731392.png

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

image-20230811200744761.png

3.5 限流

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

key：comment_freq_limit_1671356046

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

image-20230811202352198.png

3.6 分布式锁

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

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

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

image-20230811202522691.png

但是，这只是体验SetNX的特性，不是高可用的分布式锁实现，该实现存在的问题:

  • 业务超时解锁，导致并发问题。业务执行时间超过锁超时时间
  • redis主备切换临界点问题。主备切换后，A持有的锁还未同步到新的主节点时，B可在新主节点获取锁，导致并发问题。
  • redis集群脑裂，导致出现多个主节点

4. Redis注意事项

4.1 大Key

大Key：

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

大key的危害：

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

业务侧使用大Key的表现：请求Redis超时。

image-20230811203656034.png

消除大Key的方法：

  • 拆分，将大key拆分成小Key，比如将一个string拆分成多个string

image-20230811203828803.png

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

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

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

4.2 热Key

用户访问一个key的QPS特别高，导致Server实例出现CPU负载突增或不均的情况。

热key没有明确的标准，QPS超过500就可能被识别为热key。

image-20230811205051391.png

解决热Key的方法：

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

image-20230811204835759.png

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

image-20230811205037237.png

  • 使用redis代理的热key承载能力。字节跳动的Redis访问代理就具备热Key承载能力，本质上是结合了“热Key发现”、“LocalCache”两个功能。

image-20230811205023098.png

4.3 慢查询场景

慢查询：大Key、热Kye的读写；一次操作过多的Key（mset/hmset/sadd/zadd）

容易导致慢查询的操作：

  • 批量操作一次性传入过多的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。

4.4 缓存穿透、缓存雪崩

缓存穿透：热点数据查询绕过缓存，直接查询数据库。

缓存雪崩：大量缓存同时过期。

缓存穿透的危害：

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

如何减少缓存穿透？

  • 缓存空值。如一个不存在的userID，这个id在缓存和数据库中都不存在，则可以缓存一个空值，下次再查缓存直接返回空值。

  • 布隆过滤器。通过bloom filter算法来存储合法Key，得益于该算法超高的压缩率，只需占用极小的空间就能存储大量key值。

如何避免缓存雪崩？

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

  • 使用缓存集群，避免单机宕机造成的缓存雪崩。

avatar
文章
阅读
粉丝