为什么需要Redis
背景：
- 数据从单表，演化到分库分表
- MySQL 从单机演化出集群
- 数据量增长
- 读写压力增大
方案：
- 数据分冷热。热数据是经常被访问的数据。
- 将数据存储到内存中
安装Redis
Windows操作系统环境，安装指引链接
使用 WSL2，执行以下命令
curl -fsSL https://packages.redis.io/gpg | sudo gpg --dearmor -o /usr/share/keyrings/redis-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/redis-archive-keyring.gpg] https://packages.redis.io/deb $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/redis.list
sudo apt-get update
sudo apt-get install redis
然后启动服务
sudo service redis-server start
测试连接
$ redis-cli
127.0.0.1:6379> ping
PONG
Redis基本工作原理
- 数据从内存中读
- 数据保存到磁盘上，防止断电数据丢失
- 增量数据保存到 AOF（Append Of File） 文件，写操作之前会产生日志 AOF 文件。
- 全量数据 RDB 文件，持久化所有数据。
- 单线程处理操作命令，顺序执行。
Redis应用案例
掘金连续签到
// addContinuesDays 为用户签到续期
func addContinuesDays(ctx context.Context, userID int64) {
key := fmt.Sprintf(continuesCheckKey, userID)
// 1. 连续签到数+1
err := RedisClient.Incr(ctx, key).Err()
if err != nil {
fmt.Errorf("用户[%d]连续签到失败", userID)
} else {
expAt := beginningOfDay().Add(48 * time.Hour)
// 2. 设置签到记录在后天的0点到期
if err := RedisClient.ExpireAt(ctx, key, expAt).Err(); err != nil {
panic(err)
} else {
// 3. 打印用户续签后的连续签到天数
day, err := getUserCheckInDays(ctx, userID)
if err != nil {
panic(err)
}
fmt.Printf("用户[%d]连续签到：%d(天), 过期时间:%s", userID, day, expAt.Format("2006-01-02 15:04:05"))
}
}
}
// getUserCheckInDays 获取用户连续签到天数
func getUserCheckInDays(ctx context.Context, userID int64) (int64, error) {
key := fmt.Sprintf(continuesCheckKey, userID)
days, err := RedisClient.Get(ctx, key).Result()
if err != nil {
return 0, err
}
if daysInt, err := strconv.ParseInt(days, 10, 64); err != nil {
panic(err)
} else {
return daysInt, nil
}
}
String 数据结构
len：buf长度，类似Go的len(...)alloc：buf容量，类似Go的cap(...)flags：指示类型buf：用于存储字符串本身
多用于存储计数、Session。
消息队列
使用list作为消息队列。
例如当文章更新时，将更新后的文章推送到ES，用户就能搜索到最新的文章数据。
// ex04ConsumerPop 使用rpop逐条消费队列中的信息，数据从队列中移除
// 生成端使用：lpush ex04_list_0 AA BB
func ex04ConsumerPop(ctx context.Context, cInstParam common.CInstParams) {
routine := cInstParam.Routine
for {
items, err := RedisClient.BRPop(ctx, 0, ex04ListenList).Result()
if err != nil {
panic(err)
}
fmt.Println(common.LogFormat(routine, "读取文章[%s]标题、正文，发送到ES更新索引", items[1]))
// 将文章内容推送到ES
time.Sleep(1 * time.Second)
}
}
// ex04ConsumerRange 使用lrange批量消费队列中的数据，数据保留在队列中
// 生成端使用：rpush ex04_list_0 AA BB
// 消费端：
// 方法1 lrange ex04_list_0 -3 -1 // 从FIFO队尾中一次消费3条信息
// 方法2 rpop ex04_list_0 3
func ex04ConsumerRange(ctx context.Context, cInstParam common.CInstParams) {
routine := cInstParam.Routine
consumeBatchSize := int64(3) // 一次取N个消息
for {
// 从index(-consumeBatchSize)开始取，直到最后一个元素index(-1)
items, err := RedisClient.LRange(ctx, ex04ListenList, -consumeBatchSize, -1).Result()
if err != nil {
panic(err)
}
if len(items) > 0 {
fmt.Println(common.LogFormat(routine, "收到信息:%s", strings.Join(items, "->")))
// 清除已消费的队列
// 方法1 使用LTrim
// 保留从index(0)开始到index(-(consumeBatchSize + 1))的部分，即为未消费的部分
// RedisClient.LTrim(ctx, ex04ListenList, 0, -(consumeBatchSize + 1))
// 方法2 使用RPop
RedisClient.RPopCount(ctx, ex04ListenList, int(consumeBatchSize))
}
time.Sleep(3 * time.Second)
}
}
List数据结构
Quicklist 由一个双向链表和 listpack 实现。
总体是一个双向链表，但每个节点（listpack）可能会存储多个数据。
掘金用户计数
当一个用户有多项计数的需求，可以通过 HASH 结构存储。
// 写入
func Ex06InitUserCounter(ctx context.Context) {
pipe := RedisClient.Pipeline()
userCounters := []map[string]interface{}{
{"user_id": "1556564194374926", "got_digg_count": 10693, "got_view_count": 2238438, "followee_count": 176, "follower_count": 9895, "follow_collect_set_count": 0, "subscribe_tag_count": 95},
{"user_id": "1111", "got_digg_count": 19, "got_view_count": 4},
{"user_id": "2222", "got_digg_count": 1238, "follower_count": 379},
}
for _, counter := range userCounters {
uid, err := strconv.ParseInt(counter["user_id"].(string), 10, 64)
key := GetUserCounterKey(uid)
rw, err := pipe.Del(ctx, key).Result()
if err != nil {
fmt.Printf("del %s, rw=%d\n", key, rw)
}
_, err = pipe.HMSet(ctx, key, counter).Result()
if err != nil {
panic(err)
}
fmt.Printf("设置 uid=%d, key=%s\n", uid, key)
}
// 批量执行上面for循环设置好的hmset命令
_, err := pipe.Exec(ctx)
if err != nil { // 报错后进行一次额外尝试
_, err = pipe.Exec(ctx)
if err != nil {
panic(err)
}
}
}
// 读取
// pipe.HGetAll(ctx, key)
// client.HGet(ctx, key, field)
// 更改
// client.HIncrBy(ctx, key, field, incr)
Hash 数据结构
Hash数据结构底层实现称为 dict。
一个 dict 中会有两个哈希表 dictht，这是为了哈希表的扩容。读写某个 key（dict中的 key 应该是命令行中的 field） 的数据时，找到hash(key) & sizemask对应的槽位，然后读取 dictEntry 中的 val。
当槽位所对应的链表太长，需要扩容，就会进行 rehash。
rehash操作是将ht[0]中的数据，全部迁移到ht[1]中。
数据量小的场景下，直接将数据从ht[0]拷贝到ht[1]速度是较快的。
数据量大的场景，例如存有上百万的KV时，迁移过程将会明显阻塞用户请求。 为避免出现这种情况，使用了 rehash 方案。 基本原理就是，每次用户访问时都会迁移少量数据。 将整个迁移过程，平摊到所有的用户请求过程中。
排行榜
积分变化时，排名要实时变化。
此时可以使用 ZSET。ZSET 结合 dict 可以实现通过 key 操作跳表的功能。
type Ex06ItemScore struct {
ItemNam string
Score float64
}
// Ex06 排行榜
// go run main.go init // 初始化积分
// go run main.go Ex06 rev_order // 输出完整榜单
// go run main.go Ex06 order_page 0 // 逆序分页输出，offset=1
// go run main.go Ex06 get_rank user2 // 获取user2的排名
// go run main.go Ex06 get_score user2 // 获取user2的分数
// go run main.go Ex06 add_user_score user2 10 // 为user2设置为10分
// zadd ex06_rank_zset 15 andy
// zincrby ex06_rank_zset -9 andy // andy 扣9分，排名掉到最后一名
func Ex06(ctx context.Context, args []string) {
// ...
}
func Ex06InitUserScore(ctx context.Context) {
initList := []redis.Z{
{Member: "user1", Score: 10}, {Member: "user2", Score: 232}, {Member: "user3", Score: 129},
{Member: "user4", Score: 232},
}
// 清空榜单
if err := RedisClient.Del(ctx, Ex06RankKey).Err(); err != nil {
panic(err)
}
nums, err := RedisClient.ZAdd(ctx, Ex06RankKey, initList...).Result()
if err != nil {
panic(err)
}
fmt.Printf("初始化榜单Item数量:%d\n", nums)
}
// 榜单逆序输出
// ZRANGE ex06_rank_zset +inf -inf BYSCORE rev WITHSCORES
// 正序输出
// ZRANGE ex06_rank_zset 0 -1 WITHSCORES
func GetRevOrderAllList(ctx context.Context, limit, offset int64) {
resList, err := RedisClient.ZRevRangeWithScores(ctx, Ex06RankKey, 0, -1).Result()
if err != nil {
panic(err)
}
fmt.Printf("\n榜单:\n")
for i, z := range resList {
fmt.Printf("第%d名 %s\t%f\n", i+1, z.Member, z.Score)
}
}
func GetOrderListByPage(ctx context.Context, offset, pageSize int64) {
// zrange ex06_rank_zset 300 0 byscore rev limit 1 2 withscores // 取300分到0分之间的排名
// zrange ex06_rank_zset -inf +inf byscore withscores 正序输出
// ZRANGE ex06_rank_zset +inf -inf BYSCORE REV WITHSCORES 逆序输出所有排名
// zrange ex06_rank_zset +inf -inf byscore rev limit 0 2 withscores 逆序分页输出排名
zRangeArgs := redis.ZRangeArgs{
Key: Ex06RankKey,
ByScore: true,
Rev: true,
Start: "-inf",
Stop: "+inf",
Offset: offset,
Count: pageSize,
}
resList, err := RedisClient.ZRangeArgsWithScores(ctx, zRangeArgs).Result()
if err != nil {
panic(err)
}
fmt.Printf("\n榜单(offest=%d, pageSize=%d):\n", offset, pageSize)
offNum := int(pageSize * offset)
for i, z := range resList {
rank := i + 1 + offNum
fmt.Printf("第%d名 %s\t%f\n", rank, z.Member, z.Score)
}
fmt.Println()
}
// GetUserRankByName 获取用户排名
func GetUserRankByName(ctx context.Context, name string) {
rank, err := RedisClient.ZRevRank(ctx, Ex06RankKey, name).Result()
if err != nil {
fmt.Errorf("error getting name=%s, err=%v", name, err)
return
}
fmt.Printf("name=%s, 排名=%d\n", name, rank+1)
}
// GetUserScoreByName 获取用户分值
func GetUserScoreByName(ctx context.Context, name string) {
score, err := RedisClient.ZScore(ctx, Ex06RankKey, name).Result()
if err != nil {
fmt.Errorf("error getting name=%s, err=%v", name, err)
return
}
fmt.Println(time.Now().UnixMilli())
fmt.Printf("name=%s, 分数=%f\n", name, score)
}
// AddUserScore 排名用户
func AddUserScore(ctx context.Context, name string, score float64) {
num, err := RedisClient.ZIncrBy(ctx, Ex06RankKey, score, name).Result()
if err != nil {
panic(err)
}
fmt.Printf("name=%s, add_score=%f, score=%f\n", name, score, num)
}
ZSET 数据结构
其中一个实现是使用称为 zskiplist 的数据结构，也就是跳表。
跳表是一种基于链表的数据结构，用于实现有序集合的高效查找、插入和删除操作。跳表的设计灵感来自于平衡树，但相对于平衡树来说，跳表的实现更加简单，而且在实际应用中也能达到较好的性能。
- 查找操作：从最顶层的链表开始，在同一层中，遍历元素，直到下一个元素是大于关键字（或遇到尾节点）的，跳到当前元素的下一层。若当前是大于关键字的元素，通过
backward指针回退。 - 插入操作：当要插入一个新元素时，首先查找到合适的插入位置，然后通过一定的概率决定该元素最多跨越的层数。
- 删除操作：删除操作也类似，首先查找到要删除的元素，然后在索引层中的各个链表中同时删除该元素。若只剩下头、尾节点，则删除这一层。
限流
要求规定时间内只有固定数量的请求，超过数量的请求将拒绝响应。
使用一个 key 中自带时间戳的字符串，对该 key 调用 Incr 方法，当数字超过规定数量则限制请求。
var ex03LimitKeyPrefix = "comment_freq_limit"
var accessQueryNum = int32(0)
const ex03MaxQPS = 10 // 限流次数
// ex03LimitKey 返回key格式为：comment_freq_limit-1669524458 // 用来记录这1秒内的请求数量
func ex03LimitKey(currentTimeStamp time.Time) string {
return fmt.Sprintf("%s-%d", ex03LimitKeyPrefix, currentTimeStamp.Unix())
}
// Ex03 简单限流
func Ex03(ctx context.Context) {
eventLogger := &common.ConcurrentEventLogger{}
// new一个并发执行器
cInst := common.NewConcurrentRoutine(500, eventLogger)
// 并发执行用户自定义函数work
cInst.Run(ctx, Ex03Params{}, ex03Work)
// 按日志时间正序打印日志
eventLogger.PrintLogs()
fmt.Printf("放行总数：%d\n", accessQueryNum)
fmt.Printf("\n------\n下一秒请求\n------\n")
accessQueryNum = 0
time.Sleep(1 * time.Second)
// new一个并发执行器
cInst = common.NewConcurrentRoutine(10, eventLogger)
// 并发执行用户自定义函数work
cInst.Run(ctx, Ex03Params{}, ex03Work)
// 按日志时间正序打印日志
eventLogger.PrintLogs()
fmt.Printf("放行总数：%d\n", accessQueryNum)
}
func ex03Work(ctx context.Context, cInstParam common.CInstParams) {
routine := cInstParam.Routine
eventLogger := cInstParam.ConcurrentEventLogger
key := ex03LimitKey(time.Now())
currentQPS, err := RedisClient.Incr(ctx, key).Result()
if err != nil || err == redis.Nil {
err = RedisClient.Incr(ctx, ex03LimitKey(time.Now())).Err()
if err != nil {
panic(err)
}
}
if currentQPS > ex03MaxQPS {
// 超过流量限制，请求被限制
eventLogger.Append(common.EventLog{
EventTime: time.Now(),
Log: common.LogFormat(routine, "被限流[%d]", currentQPS),
})
// sleep 模拟业务逻辑耗时
time.Sleep(50 * time.Millisecond)
err = RedisClient.Decr(ctx, key).Err()
if err != nil {
panic(err)
}
} else {
// 流量放行
eventLogger.Append(common.EventLog{
EventTime: time.Now(),
Log: common.LogFormat(routine, "流量放行[%d]", currentQPS),
})
atomic.AddInt32(&accessQueryNum, 1)
time.Sleep(20 * time.Millisecond)
}
}
分布式锁
并发场景，要求一次只能有一个协程执行。执行完成后，其它等待中的协程才能执行。
可以使用 redis 的 setnx 实现，利用了两个特性：
- Redis 是单线程执行命令
- setnx 只有未设置过才能执行成功
const resourceKey = "syncKey" // 分布式锁的key
const exp = 800 * time.Millisecond // 锁的过期时间，避免死锁
// EventLog 搜集日志的结构
type EventLog struct {
eventTime time.Time
log string
}
// Ex02 只是体验SetNX的特性，不是高可用的分布式锁实现
// 该实现存在的问题:
// (1) 业务超时解锁，导致并发问题。业务执行时间超过锁超时时间
// (2) redis主备切换临界点问题。主备切换后，A持有的锁还未同步到新的主节点时，B可在新主节点获取锁，导致并发问题。
// (3) redis集群脑裂，导致出现多个主节点
func Ex02(ctx context.Context) {
eventLogger := &common.ConcurrentEventLogger{}
// new一个并发执行器
cInst := common.NewConcurrentRoutine(10, eventLogger)
// 并发执行用户自定义函数work
cInst.Run(ctx, Ex02Params{}, ex02Work)
// 按日志时间正序打印日志
eventLogger.PrintLogs()
}
func ex02Work(ctx context.Context, cInstParam common.CInstParams) {
routine := cInstParam.Routine
eventLogger := cInstParam.ConcurrentEventLogger
defer ex02ReleaseLock(ctx, routine, eventLogger)
for {
// 1. 尝试获取锁
// exp - 锁过期设置,避免异常死锁
acquired, err := RedisClient.SetNX(ctx, resourceKey, routine, exp).Result() // 尝试获取锁
if err != nil {
eventLogger.Append(common.EventLog{
EventTime: time.Now(), Log: fmt.Sprintf("[%s] error routine[%d], %v", time.Now().Format(time.RFC3339Nano), routine, err),
})
panic(err)
}
if acquired {
// 2. 成功获取锁
eventLogger.Append(common.EventLog{
EventTime: time.Now(), Log: fmt.Sprintf("[%s] routine[%d] 获取锁", time.Now().Format(time.RFC3339Nano), routine),
})
// 3. sleep 模拟业务逻辑耗时
time.Sleep(10 * time.Millisecond)
eventLogger.Append(common.EventLog{
EventTime: time.Now(), Log: fmt.Sprintf("[%s] routine[%d] 完成业务逻辑", time.Now().Format(time.RFC3339Nano), routine),
})
return
} else {
// 没有获得锁，等待后重试
time.Sleep(100 * time.Millisecond)
}
}
}
func ex02ReleaseLock(ctx context.Context, routine int, eventLogger *common.ConcurrentEventLogger) {
routineMark, _ := RedisClient.Get(ctx, resourceKey).Result()
if strconv.FormatInt(int64(routine), 10) != routineMark {
// 其它协程误删lock
panic(fmt.Sprintf("del err lock[%s] can not del by [%d]", routineMark, routine))
}
set, err := RedisClient.Del(ctx, resourceKey).Result()
if set == 1 {
eventLogger.Append(common.EventLog{
EventTime: time.Now(), Log: fmt.Sprintf("[%s] routine[%d] 释放锁", time.Now().Format(time.RFC3339Nano), routine),
})
} else {
eventLogger.Append(common.EventLog{
EventTime: time.Now(), Log: fmt.Sprintf("[%s] routine[%d] no lock to del", time.Now().Format(time.RFC3339Nano), routine),
})
}
if err != nil {
fmt.Errorf("[%s] error routine=%d, %v", time.Now().Format(time.RFC3339Nano), routine, err)
panic(err)
}
}
在字节跳动，使用Redis有哪些注意事项
大 Key
- String 类型：value的字节数大于10KB即为大key
- Hash / Set / Zset / list 等复杂数据结构类型：元素个数大于 5000 个或总 value 字节数大于 10MB 即为大 Key。
使用大 Key 将导致 Redis 系统不稳定。大 Key 的危害有：
- 读取成本高
- 容易导致慢查询（过期、删除）
- 主从复制异常，服务阻塞。无法正常响应请求
业务侧使用大 Key 可能导致请求 Redis 超时报错。
消除大 Key
-
拆分
将大 key 拆分为小 key。例如一个 String 拆分成多个 String
-
压缩
将 value 压缩后写入 redis，读取时解压后再使用。 压缩算法可以是 gzip、snappy、lz4等。通常情况下，一个压缩算法压缩率高、则解压耗时就长。 需要对实际数据进行测试后，选择一个合适的算法。如果存储的是 JSON 字符串，可以考虑使用 MessagePack 进行序列化。
-
集合类结构 hash、list、set、set
- 拆分：可以用 hash 取余、位掩码的方式决定放在哪个 key 中
- 区分冷热：如榜单列表场景使用 zset，只缓存前 10 页数据，后续数据走 db
热Key
用户访问一个Key的QPS特别高，导致 Server 实例出现 CPU 负载突增或者不均的情况，导致单实例故障。 热 Key 没有明确的标准，QPS 超过 500 就有可能被识别为热 Key。
解决方案
-
设置Localcache
在访问Redis前，在业务服务侧设置 Localcache，降低访问 Redis 的 QPS。LocalCache中缓存过期或未命中，则从 Redis 中将数据更新到 LocalCache。 Java 的 Guava、Golang 的 Bigcache 就是这类 LocalCache。
-
拆分
将 key:value 这一个热 Key 复制写入多份，例如 key1:value，key2:value，访问的时候访问多个 key，但 value 是同一个，以此将qps分散到不同实例上，降低负载。代价是，更新时需要更新多个 key，存在数据短暂不一致的风险。
-
使用 Redis 代理的热 Key 承载能力
字节跳动的 Redis 访问代理就具备热 Key 承载能力。本质上是结合了“热 Key 发现”、“LocalCache”两个功能。
慢查询
容易导致redis慢查询的操作：
- 批量操作一次性传入过多的 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
导致缓存穿透、缓存雪崩的场景及避免方案
缓存穿透：热点数据查询绕过缓存，直接查询数据库
缓存雪崩：大量缓存同时过期
缓存穿透的危害：
-
查询一个一定不存在的数据
通常不会缓存不存在的数据，这类查询请求都会直接打到 db，如果有系统 bug 或人为攻击，那么容易导致 db 响应慢甚至宕机
-
缓存过期时
在高并发场景下，一个热 key 如果过期，会有大量请求同时击穿至 db，容易影响 db 性能和稳定。
同一时间有大量 key 集中过期时，也会导致大量请求落到 db 上，导致查询变慢，甚至出现 db 无法响应新的查询。
如何减少缓存穿透
-
缓存空值
如一个不存在的 userID。这个 id 在缓存和数据库中都不存在。则可以缓存一个空值，下次再查缓存直接反空值。
-
布隆过滤器
通过 bloom filter 算法来存储合法 Key，得益于该算法超高的压缩率，只需占用极小的空间就能存储大量 key 值。
如何避免缓存雪崩
-
缓存空值
将缓存失效时间分散开，比如在原有的失效时间基础上增加一个随机值，例如不同 Key 过期时间，可以设置为 10 分 1 秒过期，10 分 23 秒过期，10 分 8 秒过期。单位秒部分就是随机时间，这样过期时间就分散了。
对于热点数据，过期时间尽量设置得长一些，冷门的数据可以相对设置过期时间短一些。
-
使用缓存集群，避免单机宕机造成的缓存雪崩。
