Redis高级用法以及golang代码示例_Golang

前言

redis作为内存数据库在服务器使用非常广泛，除了基本的key-value缓存作为db的内存缓存用，还有一些高级feature，比如

分布式缓存

不同服务器节点节点间同步数据，redis可以是一个集群，缓存数据在多个服务器节点之间同步，比如同步session信息等。

redis中的队列等机制可以实现订阅和发布机制，来实现事件通知的作用。

分布式锁

redis可以实现分布式锁，用于分布式架构中共享资源的互斥访问。

角色定位	核心要解决的问题	redis如何应对（核心机制）	典型使用场景
数据库缓存	缓解后端数据库（如mysql）的读取压力，提升应用响应速度。	通过内存存储实现极速读写；设置合理的过期时间（ttl）和淘汰策略。	缓存热点数据（如用户信息、商品详情）。
分布式缓存	在分布式系统中，为多个应用实例提供统一的缓存服务，实现数据共享。	通过redis集群实现数据分片（sharding）和高可用（high availability）。	分布式session存储、全局计数器。
消息中间件	实现应用组件间的异步通信和解耦。	使用发布订阅（pub/sub）模式或list结构模拟消息队列。	实时消息通知、事件广播、简单的任务队列。
分布式锁	在分布式环境中，保证对共享资源的互斥访问。	利用 `set`命令的 `nx`（不存在才设置）和 `px`（过期时间）参数实现原子性加锁。	防止超卖、保证计划任务的单机执行。

一、redis高性能基础

要深入理解上述表格中的各种能力，我们需要探究redis背后的设计哲学，这主要归结于两点：内存存储和单线程模型。

内存存储

redis将所有数据直接存放在内存中，这使得它的数据读写操作避免了传统磁盘数据库的i/o瓶颈，速度极快，通常能达到微秒级别的延迟。为了应对内存有限和进程重启导致数据丢失的问题，redis提供了两种持久化机制：
- rdb：在特定时间点创建整个数据集的快照。它是一个紧凑的二进制文件，非常适合备份和灾难恢复，但可能会丢失最后一次快照之后的数据。
- aof：记录每一个写操作命令，以追加的方式写入日志文件。数据完整性更高，故障恢复时通过重放命令来重建状态，但文件体积通常更大，恢复速度较慢。在实际生产中，通常会结合使用两者。
单线程模型

单线程如何应对高并发？这里的“单线程”指的是处理网络i/o和执行命令的核心模块是单线程的。这样做带来了巨大优势：
- 避免了多线程的锁竞争：所有命令串行执行，天然保证了原子性，无需担心并发安全问题。
- 高效的i/o多路复用：redis使用epoll这样的机制，用一个线程监控大量的客户端连接，只有在连接真正可读或可写时才会进行处理，极大地提升了cpu利用率。
需要注意的是，redis 6.0之后引入了多线程来处理网络i/o（例如数据的读取和发送），但命令的执行本身仍然是单线程的，从而保持了简单可靠的优势。

二、redis使用场景

2.1 数据库缓存

这是redis最经典的用法，其工作流程如下图所示：

在实践中，需要注意两个经典问题：

缓存穿透：大量请求查询一个数据库中也不存在的数据，导致请求直接打到数据库。解决方案是使用布隆过滤器进行初步校验，或者将空值也缓存一小段时间。
缓存雪崩：大量缓存数据在同一时间点过期，导致所有请求涌向数据库。解决方案是给缓存过期时间加上随机值，避免同时失效。

2.2 分布式缓存

当数据量巨大或并发极高时，单机redis会成为瓶颈，或者多个分布式节点之间同步数据时，这时就需要redis集群（redis cluster）。

数据分片：redis集群将整个数据集划分为16384个哈希槽。每个键通过crc16算法计算后，再对16384取模，确定其所属的槽。集群中的每个主节点负责一部分槽区，这样数据就被自动分布到了多个节点上。
高可用：每个主节点都可以配置一个或多个从节点。当主节点故障时，集群会通过共识机制，自动将其下的某个从节点提升为新的主节点，继续提供服务，从而实现故障自动转移。

2.3 mq消息中间件

redis可通过两种方式实现消息传递：

发布订阅：发布者将消息发送到特定频道，所有订阅了该频道的订阅者都会即时收到消息。这是一种广播模式，但消息是非持久化的，即如果没有订阅者在线，消息就丢失了。
list结构：使用lpush生产消息，brpop阻塞地消费消息。这种方式消息可以持久化，但一个消息只能被一个消费者消费，更适合于简单的点对点或任务队列场景。

2.4 分布式锁

在分布式系统中，协调多个进程对共享资源的访问，需要分布式锁。redis因其原子操作和高性能成为常见选择。

核心命令是：

set lock_key unique_value nx px 30000

nx：仅当键不存在时才设置，保证只有一个客户端能设置成功，即抢到锁。
px 30000：设置键的过期时间为30秒，防止客户端崩溃后锁无法释放，导致死锁。

锁的释放需要先检查值是否为当前客户端设置的unique_value，再执行删除，推荐使用lua脚本保证这两个操作的原子性。对于更高要求的场景，可以考虑redlock算法。

实践中的注意事项

警惕大key和热key：避免单个key的value过大（如超过10kb），这会阻塞主线程。同时，要避免某个key被极高频率地访问，成为瓶颈。需要做好监控和拆分。
确保数据一致性：当缓存中的数据需要更新时，通常采用先更新数据库，再删除缓存的策略。这种方式相对简单且发生不一致的概率较低，但并非绝对，需要根据业务场景权衡。

三、代码示例

了解完 redis 的核心作用和工作原理后，下面用 go 语言详细说明 redis 在几种常见场景下的应用代码，

下表概括了这几种场景的核心实现方式和要点。

应用场景	核心 go 代码示例 (github.com/go-redis/redis/v8)	关键实现要点
数据库缓存	`client.set(ctx, key, value, expiration)` `client.get(ctx, key)`	1. 缓存模式：先查缓存，未命中再查数据库。 2. 缓存过期：务必设置 ttl。 3. 序列化：复杂数据需 json 序列化。
分布式锁	`client.setnx(ctx, lockkey, value, expire)` + lua 脚本解锁	1. 原子加锁：使用 `setnx`（或 `set key value nx px timeout`）。 2. 安全释放：验证锁持有者（lua 脚本保证原子性）。 3. 自动续期：考虑"看门狗"机制避免业务超时。
消息队列 (pub/sub)	`client.publish(ctx, channel, message)` `client.subscribe(ctx, channel...)`	1. 发布/订阅模式：轻量级广播消息，但无持久化。 2. 消息丢失：注意网络断开可能导致消息丢失。
消息队列 (list-based)	`client.lpush(ctx, queue, message)` `client.brpop(ctx, timeout, queue)`	1. 点对点队列：基于 list 的 `lpush`/`brpop`。 2. 阻塞消费：`brpop`避免轮询，节省资源。 3. 消息持久化：消息在 redis 中可持久化。

下面我们来看具体的代码实现细节和需要注意的事项。

3.1 数据库缓存

作为缓存是 redis 最经典的用法。其核心流程是：收到请求时，先尝试从 redis 中获取数据，如果命中则直接返回；如果未命中，则从底层数据库（如 mysql）查询，并将结果写入 redis 并设置过期时间，以便后续请求能直接从缓存中读取。

以下是一个完整的 go 示例，包含了连接 redis 和缓存查询的逻辑。

package main

import (
    "context"
    "encoding/json"
    "fmt"
    "log"
    "time"

    "github.com/go-redis/redis/v8"
)

// 初始化redis客户端
func initredisclient() *redis.client {
    rdb := redis.newclient(&redis.options{
        addr:     "localhost:6379", // redis服务器地址
        password: "",               // 密码，没有则为空
        db:       0,                // 使用默认db
    })
    
    // 通过ping命令测试连接
    ctx := context.background()
    _, err := rdb.ping(ctx).result()
    if err != nil {
        log.fatalf("无法连接到redis: %v", err)
    }
    fmt.println("redis连接成功")
    return rdb
}

// 获取数据（缓存优先）
func getdata(rdb *redis.client, key string) (string, error) {
    ctx := context.background()
    
    // 1. 首先尝试从缓存获取
    val, err := rdb.get(ctx, key).result()
    if err == nil {
        fmt.println("缓存命中")
        return val, nil // 成功命中，直接返回
    }
    if err != redis.nil {
        return "", err // 出现其他错误
    }
    
    // 2. 缓存未命中，从数据源（如数据库）获取
    fmt.println("缓存未命中，从数据源获取")
    data, err := getdatafromsource(key)
    if err != nil {
        return "", err
    }
    
    // 3. 将数据存入缓存，并设置过期时间（例如5分钟）
    err = rdb.set(ctx, key, data, 5*time.minute).err()
    if err != nil {
        // 此处通常记录日志，而不是直接返回错误，因为数据库查询已经成功
        log.printf("警告：数据写入缓存失败: %v", err)
    }
    return data, nil
}

// 模拟从数据库等数据源获取数据
func getdatafromsource(key string) (string, error) {
    // 这里模拟一个耗时的数据库查询
    time.sleep(100 * time.millisecond)
    result := map[string]string{"id": key, "name": "示例数据"}
    jsondata, _ := json.marshal(result)
    return string(jsondata), nil
}

func main() {
    rdb := initredisclient()
    defer rdb.close() // 确保程序退出前关闭连接

    data, err := getdata(rdb, "user:1001")
    if err != nil {
        log.fatal(err)
    }
    fmt.printf("获取到的数据: %s\n", data)
}

3.2 分布式锁

在分布式系统中，当多个服务实例需要竞争同一个资源时，就需要分布式锁来保证互斥访问。redis 因其单线程特性和原子操作，是实现分布式锁的常用方案。

一个健壮的分布式锁至少需要满足：

互斥性：在任意时刻，只有一个客户端能持有锁。
避免死锁：即使客户端在持有锁期间崩溃，锁也能被自动释放。
安全性：只能由锁的持有者来释放锁。

以下是基于 go 和 redis 的实现示例，包含了安全的加锁和解锁逻辑。

package main

import (
    "context"
    "crypto/rand"
    "encoding/base64"
    "fmt"
    "log"
    "time"

    "github.com/go-redis/redis/v8"
)

// 用于原子释放锁的lua脚本
// 先比较锁的值是否与当前客户端匹配，匹配才删除
var unlockscript = redis.newscript(`
if redis.call("get", keys[1]) == argv[1] then
    return redis.call("del", keys[1])
else
    return 0
end
`)

type redislock struct {
    client *redis.client
    ctx    context.context
}

func newredislock(client *redis.client) *redislock {
    return &redislock{
        client: client,
        ctx:    context.background(),
    }
}

// lock 尝试获取分布式锁
func (rl *redislock) lock(lockkey string, expiretime time.duration) (bool, string, error) {
    // 生成一个唯一的随机值作为锁的value，用于标识当前客户端
    token, err := generaterandomtoken()
    if err != nil {
        return false, "", err
    }

    // 使用setnx命令，只有key不存在时才能设置成功，并设置过期时间
    isset, err := rl.client.setnx(rl.ctx, lockkey, token, expiretime).result()
    if err != nil {
        return false, "", err
    }
    return isset, token, nil
}

// unlock 安全地释放分布式锁
func (rl *redislock) unlock(lockkey string, token string) error {
    // 执行lua脚本，确保判断锁归属和删除锁是原子操作
    result, err := unlockscript.run(rl.ctx, rl.client, []string{lockkey}, token).int()
    if err != nil {
        return err
    }
    if result == 1 {
        fmt.println("锁释放成功")
    } else {
        fmt.println("锁释放失败：可能不是锁的持有者或锁已过期")
    }
    return nil
}

// 生成随机token
func generaterandomtoken() (string, error) {
    b := make([]byte, 16)
    _, err := rand.read(b)
    if err != nil {
        return "", err
    }
    return base64.stdencoding.encodetostring(b), nil
}

func main() {
    rdb := redis.newclient(&redis.options{
        addr: "localhost:6379",
    })
    defer rdb.close()

    lock := newredislock(rdb)
    lockkey := "my_distributed_lock"
    expiretime := 10 * time.second

    // 尝试加锁
    acquired, token, err := lock.lock(lockkey, expiretime)
    if err != nil {
        log.fatal(err)
    }
    if acquired {
        fmt.println("成功获取分布式锁")
        
        // 模拟在锁保护下执行关键业务逻辑
        fmt.println("正在执行关键业务逻辑...")
        time.sleep(5 * time.second)
        fmt.println("关键业务逻辑执行完毕")

        // 业务完成，释放锁
        err = lock.unlock(lockkey, token)
        if err != nil {
            log.fatal(err)
        }
    } else {
        fmt.println("获取分布式锁失败，可能有其他客户端正持有锁")
    }
}

关键要点与陷阱规避：

原子性加锁：使用 set lock_name unique_value nx px milliseconds命令（或如示例中的 setnx结合过期时间），确保设置值和过期时间是原子操作。
安全释放锁：释放锁时，必须验证当前客户端是否是该锁的持有者。使用 lua 脚本将判断和删除操作原子化，防止误删其他客户端持有的锁。
自动续期（看门狗）：如果业务执行时间可能超过锁的过期时间，需要考虑实现一个自动续期机制（看门狗），在锁过期前自动延长持有时间。对于更复杂的场景，可以考虑使用现成的库，如 go-redis-lock。

3.3 消息队列 (pub/sub 和基于 list)

redis 可以用于实现轻量级的消息队列，支持发布/订阅（pub/sub）模式和基于 list 的点对点模式。

3.3.1 发布/订阅模式 (pub/sub)

pub/sub 是一种广播模式，一个发布者向某个频道（channel）发送消息，所有订阅了该频道的订阅者都会收到消息。消息是即时的，没有持久化，如果订阅者离线，将收不到消息。

发布者 (publisher) 示例：

package main

import (
    "context"
    "fmt"
    "time"

    "github.com/go-redis/redis/v8"
)

func main() {
    rdb := redis.newclient(&redis.options{
        addr: "localhost:6379",
    })
    ctx := context.background()

    for i := 1; i <= 5; i++ {
        message := fmt.sprintf("这是第 %d 条消息", i)
        // 向 "news" 频道发布消息
        err := rdb.publish(ctx, "news", message).err()
        if err != nil {
            panic(err)
        }
        fmt.printf("发布消息: %s\n", message)
        time.sleep(1 * time.second)
    }
}

订阅者 (subscriber) 示例：

package main

import (
    "context"
    "fmt"
    "log"

    "github.com/go-redis/redis/v8"
)

func main() {
    rdb := redis.newclient(&redis.options{
        addr: "localhost:6379",
    })
    ctx := context.background()

    // 订阅 "news" 频道
    pubsub := rdb.subscribe(ctx, "news")
    defer pubsub.close()

    // 从频道接收消息
    ch := pubsub.channel()
    for msg := range ch {
        fmt.printf("收到来自频道 %s 的消息: %s\n", msg.channel, msg.payload)
    }
}

3.3.2 基于 list 的队列

使用 redis 的 list 结构和 lpush/brpop命令可以实现一个更经典的点对点消息队列。消息可以被持久化，并且只能被一个消费者消费。

生产者 (producer) 示例：

package main

import (
    "context"
    "encoding/json"
    "fmt"

    "github.com/go-redis/redis/v8"
)

type message struct {
    id      string `json:"id"`
    content string `json:"content"`
}

func main() {
    rdb := redis.newclient(&redis.options{
        addr: "localhost:6379",
    })
    ctx := context.background()
    queuename := "my_task_queue"

    message := message{id: "1", content: "需要处理的任务内容"}
    jsonmsg, _ := json.marshal(message)

    // 将消息放入队列右侧 (尾部)
    err := rdb.lpush(ctx, queuename, jsonmsg).err()
    if err != nil {
        panic(err)
    }
    fmt.println("消息已生产:", string(jsonmsg))
}

消费者 (consumer) 示例：

package main

import (
    "context"
    "encoding/json"
    "fmt"
    "log"

    "github.com/go-redis/redis/v8"
)

func main() {
    rdb := redis.newclient(&redis.options{
        addr: "localhost:6379",
    })
    ctx := context.background()
    queuename := "my_task_queue"

    for {
        // 从队列左侧 (头部) 阻塞地获取消息，超时时间设为0（无限等待）
        result, err := rdb.brpop(ctx, 0, queuename).result() // result[0]是队列名，result[1]是消息体
        if err != nil {
            log.fatal(err)
        }

        var msg message
        err = json.unmarshal([]byte(result[1]), &msg)
        if err != nil {
            log.printf("消息解析失败: %v", err)
            continue
        }
        fmt.printf("开始处理消息: id=%s, content=%s\n", msg.id, msg.content)
        // ... 这里处理业务逻辑 ...
        fmt.printf("消息 %s 处理完毕\n", msg.id)
    }
}

关键要点与陷阱规避：

模式选择：需要广播通知用 pub/sub；需要任务队列、保证消息至少被处理一次用基于 list 的队列。
消息持久化：pub/sub 消息不持久化，list 消息会保存在 redis 中。
消费可靠性：list 队列中，消费者使用 brpop阻塞获取消息，但消息被取出后就在 redis 中删除了。如果消费者处理失败，消息会丢失。对于要求可靠队列的场景，redis 可能不是最佳选择，可以考虑更专业的消息中间件（如 rabbitmq, kafka）。

3.4 实践总结与建议

以上代码示例展示了 redis 在 go 语言中的典型应用。在实际项目中，还有一些通用建议：

连接管理：使用连接池，避免频繁创建和关闭连接。go-redis库默认使用了连接池。
配置化：将 redis 的地址、密码、db 等配置信息放在配置文件（如 app.ini）中，提高灵活性。
错误处理：对 redis 操作进行完善的错误处理，区分是键不存在的正常情况还是网络错误等异常。
框架选择：对于复杂的缓存需求，可以考虑使用封装好的框架，如 goframe 的 gcache模块，它提供了统一的缓存接口和更丰富的功能（如分布式锁、缓存适配器等）。