redis实战——go-redis的使用与redis基础数据类型的使用场景(一)

本文涉及的产品
云数据库 Tair(兼容Redis),内存型 2GB
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
简介: 本文档介绍了如何使用 Go 语言中的 `go-redis` 库操作 Redis 数据库

一.go-redis的安装与快速开始

这里操作redis数据库,我们选用go-redis这一第三方库来操作,首先是三方库的下载,我们可以执行下面这个命令:

go get github.com/redis/go-redis/v9

最后我们尝试一下连接本机的redis数据库,以及执行一个简单的redis操作:

package main

import (
    "context"
    "github.com/redis/go-redis/v9"
)

func main() {
   
   
    rdb := redis.NewClient(&redis.Options{
   
   
        Addr:     "localhost:6379",
        Password: "",
        DB:       0,
    })

    //go-redis支持Context,我们可以用它来控制超时会传递数据
    ctx := context.Background()
    rdb.Set(ctx, "key", "value", 100)
    val, err := rdb.Get(ctx, "key").Result()
    if err != nil {
   
   
        panic(err)
    }
    println(val)
}

输出结果为:

value

同时,go-redis还支持Context,我们可以用这个机制来实现一些我们想要的功能,比如传递数据和设置超时时间:

package main

import (
    "context"
    "github.com/redis/go-redis/v9"
)

type contextkey string

var userIDKey contextkey = "userID"

func main() {
   
   
    rdb := redis.NewClient(&redis.Options{
   
   
        Addr:     "localhost:6379",
        Password: "",
        DB:       0,
    })

    //go-redis支持Context,我们可以用它来控制超时会传递数据
    ctx := context.WithValue(context.Background(), userIDKey, "123")

    //利用上下文来传递数据
    userID := ctx.Value(userIDKey).(string)

    rdb.Set(ctx, "ID", userID, 0)
    val, err := rdb.Get(ctx, "ID").Result()
    if err != nil {
   
   
        panic(err)
    }
    //// 设置超时时间为 2 秒
    //ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
    //defer cancel() // 确保在函数结束时取消上下文
    println(val)
}

二.go-redis的基本操作

rdb.Del(ctx, "ID") //删除键
rdb.Expire(ctx, "ID", 100) //设置过期时间
rdb.Persist(ctx, "ID") //取消过期时间
rdb.TTL(ctx, "ID") //获取ID的过期时间
rdb.PTTL(ctx, "ID") //获取ID的剩余过期时间
rdb.Type("ID")  //查询类型
rdb.Scan(0,"",4) //扫描

三. go-redis操作字符串

首先对字符串的操作还是很简单的:

package main

import (
    "context"
    "fmt"
    "github.com/redis/go-redis/v9"
)

func main() {
   
   
    rdb := redis.NewClient(&redis.Options{
   
   
        Addr:     "localhost:6379",
        Password: "",
        DB:       0, // use default DB
    })
    ctx := context.Background()
    rdb.Set(ctx, "token1", "abcefghijklmn", 0)                    // 设置token
    rdb.MSet(ctx, "token2", "abcefghijklmn", "cookie1", "123456") // 设置多个key
    a := rdb.MGet(ctx, "token1", "token2", "cookie1").Val()
    fmt.Println(a)

    //数字增减操作
    rdb.Set(ctx, "age", "1", 0)
    fmt.Println(rdb.Get(ctx, "age").Val())
    rdb.Incr(ctx, "age")
    fmt.Println(rdb.Get(ctx, "age").Val())
    rdb.IncrBy(ctx, "age", 5)
    fmt.Println(rdb.Get(ctx, "age").Val())
    rdb.Decr(ctx, "age")
    fmt.Println(rdb.Get(ctx, "age").Val())
    rdb.DecrBy(ctx, "age", 5)
    fmt.Println(rdb.Get(ctx, "age").Val())
}

String可以算是Redis使用最为频繁的基础数据类型了,它的作用非常广泛,简单的它可以实现一个计数器,向这样:

    rdb.Set(ctx, "age", "1", 0)
    fmt.Println(rdb.Get(ctx, "age").Val())
    rdb.Incr(ctx, "age")
    fmt.Println(rdb.Get(ctx, "age").Val())
    rdb.IncrBy(ctx, "age", 5)
    fmt.Println(rdb.Get(ctx, "age").Val())
    rdb.Decr(ctx, "age")
    fmt.Println(rdb.Get(ctx, "age").Val())
    rdb.DecrBy(ctx, "age", 5)
    fmt.Println(rdb.Get(ctx, "age").Val())

它也可以用来实现分布式锁,后面我们会详细的探讨分布式锁的原理,这里我们就简单的介绍一下什么是分布式锁:
我们在微服务中会在一个服务中部署多个进程,需要我们操作多个进程,在多进程中为了避免同时操作一个共享变量产生数据问题,通常会使用一把锁来互斥以保证共享变量的正确性,但是单机锁发挥作用是单进程中使用,我们应该如何给多个进程上锁呢?
我们这里可以选择第三方来做裁判,这里我们一般会使用Zookeeperredis来作为第三方,所有进程都去这个裁判这里申请加锁。而这个外部系统,必须要实现互斥能力,即两个请求同时进来,只会给一个进程加锁成功,另一个失败,接下来我们来看一下这个分布式锁怎么来实现:
set命令中通过NX参数我们可以实现key 不存在才插入,我们可以用它来实现分布式锁:

  • 如果 key 不存在,则显示插入成功,可以用来表示加锁成功;
  • 如果 key 存在,则会显示插入失败,可以用来表示加锁失败。

分布式锁加锁命令如下:

set lock uuid NX PX 10000

lock:key键
uuid:客户端生成的唯一的标识
NX: 只在 lock 不存在时,才对 lock 进行设置操作
PX:设置锁的过期时间

而解锁就是删除lock键,但是这个命令不能随便删,我们要保证执行该操作的客户端是加了锁的,这就导致我们删锁的操作分为以下两步:

  • 判断锁的 uuid 是否为加锁客户
  • 删除锁
    但是由于是俩个操作,这就导致删锁的操作不具有原子性,所以需要我们借助Lua脚本来实现操作的原子性,Lua脚本如下:
    if redis.call("get",KEYS[1]) == ARGV[1] then
      return redis.call("del",KEYS[1])
    else
      return 0
    end
    
    这样一来,就通过使用 SET 命令和 Lua 脚本在 Redis 单节点上完成了分布式锁的加锁和解锁。

最后我们还可以用Redis共享 Session 信息:
在我们写后台管理系统的时候,我们一般需要存储用户的Jwt或者Session来保存用户的登录状态,单服务器下Session 信息会被保存在服务器端,但是分布式系统下,用户一的 Session 信息被存储在服务器一,但第二次访问时用户一被分配到服务器二,这个时候服务器并没有用户一的 Session 信息,就会出现需要重复登录的问题,问题在于分布式系统每次会把请求随机分配到不同的服务器,而为了解决这个问题我们就会选择redis服务器来对这些 Session 信息进行统一的存储和管理,这样无论请求发送到那台服务器,服务器都会去同一个 Redis 获取相关的 Session 信息,进而解决了分布式系统下 Session 存储的问题,结构示例如下:
在这里插入图片描述

go-redis操作list

首先我们来看一下一些常用的命令:

// 左边添加
redisClient.LPush("list", "a", "b", "c", "d", "e")
// 右边添加
redisClient.RPush("list", "g", "i", "a")
// 在参考值前面插入值
redisClient.LInsertBefore("list", "a", "aa")
// 在参考值后面插入值
redisClient.LInsertAfter("list", "a", "gg")
// 设置指定下标的元素的值
redisClient.LSet("list", 0, "head")
//访问列表长度
redisClient.Len("list")
// 左边弹出元素
redisClient.LPop("list")
// 右边弹出元素
redisClient.RPop("list")
// 访问指定下标的元素
redisClient.LIndex("list", 1)
// 访问指定范围内的元素
redisClient.LRange("list", 0, 1)
// 保留指定范围的元素
redisClient.LTrim("list", 0, 1)
// 删除指定元素
redisClient.LRem("list", 0, "a")

关于List的使用场景我也没有找到太多的案例,但是博主找到了一个比较有趣的实践:基于List这一数据结构来实现一个简单的消息队列,接下来博主将尝试写一个简单的消息队列来作为我们List数据结果的实践:

一个合格的消息队列应该满足下面几个要求:

  • 消息的保序性
  • 如何处理重复的消息
  • 保证消息的可靠性

首先我们如何保证消息的有序性呢?由于我们是用List这一数据结构来实现对消息队列的模拟,所以不生就可以实现对消息的保序性了,我们现在要完成的就是生产者基于Push操作完成对消息的生产,消费者基于Pop完成对信息地消费即可,一般来说下面这个组合就可以了

  • LPUSH+RPOP
  • RPUSH+LPOP

但是现在有一个问题:List本身是不会去提醒消费者有新消息写入,如果消费者想要及时处理消息,我们应该怎么做呢?首先我们的想法应该是让消费者程序不断去执行RPOP操作,如果有新消息写入,RPOP 命令就会返回结果,否则,RPOP 命令返回空值,再继续循环。但是这样一来消费者程序的 CPU 一直消耗在执行 RPOP 命令上,带来不必要的性能损失,所以这里我们可以选择使用BRPOP操作,执行该操作时,客户端在没有读到队列数据的时候会自动阻塞,直到有新的数据写入队列,再开始读取新数据。和消费者程序自己不停地调用 RPOP 命令相比,这种方式能节省 CPU 开销。

示例代码如下:

package main

import (
    "context"
    "github.com/redis/go-redis/v9"
)

var client *redis.Client
var ctx context.Context

type Custom struct {
   
   
}

type Product struct {
   
   
}

func Init() {
   
   
    client = redis.NewClient(&redis.Options{
   
   
        Addr:     "localhost:6379",
        Password: "",
        DB:       0,
    })
    ctx = context.Background()
}

func (product *Product) AddMessage(key string, value any) error {
   
    //生产消息
    return client.LPush(ctx, key, value).Err()
}

func (custom *Custom) ConsumerMessage(key string) ([]string, error) {
   
   
    message, err := client.BRPop(ctx, 0, key).Result()
    return message, err
}

在解决完消息的有序性之后我们要面临的下一个问题就是如何避免重复的处理消息?我们可以给每一个消息加上一个全局唯一 ID,这样消费者在消费时可以把已经消费的消息id记录下来,每次即将消费新消息的时候进行对比,避免对已经处理的消息进行重复操作,这里我采用了雪花算法生成分布式id的方式来实现对全局唯一id的生成,有关雪花算法的相关操作就不赘述了,我之前的文章中也有所介绍,具体可以参考:go语言后端开发学习(六) ——基于雪花算法生成用户ID

我们来看一下具体的代码可以怎么写:

func Init() {
   
   
    client = redis.NewClient(&redis.Options{
   
   
        Addr:     "localhost:6379",
        Password: "",
        DB:       0,
    })
    ctx = context.Background()
    err := sony.Init()
    if err != nil {
   
   
        fmt.Println("Init sonyflake failed,err:", err)
    }
}

func (product *Product) AddMessage(key string, value any) error {
   
    //生产消息
    id, err := sony.GetID()
    if err != nil {
   
   
        return err
    }
    value = fmt.Sprintf("%d:%v", id, value) //添加id
    return client.LPush(ctx, key, value).Err()
}

func (custom *Custom) ConsumerMessage(key string) ([]string, error) {
   
   
    message, err := client.BRPop(ctx, 0, key).Result()
    id := custom.SplitMessage(message)
    if !custom.CheckId(id) {
   
   
        err := fmt.Errorf("id:%s is already processed", id)
        return nil, err
    }
    return message, err
}

func (custom *Custom) SplitMessage(message []string) string {
   
   
    str := strings.Split(message[1], ":")
    return str[0]
}

func (custom *Custom) CheckId(id string) bool {
   
    //检测id是否已经处理过
    for _, v := range idmap {
   
   
        if v == id {
   
   
            return false //该消息已经处理过了
        }
    }
    idmap = append(idmap, id) //添加到idmap
    return true
}

这里代码主要是添加了全局唯一id的生成,以及对id的解析与判断。

最后我们如何保证消息的可靠性呢?大家乍一听这个可能有点懵,这是什么意思?现在有一个情况,如果消费者程序从 List 中读取一条消息后,List 就不会再留存这条消息了。所以,如果消费者程序在处理消息的过程出现了故障或宕机,就会导致消息没有处理完成,那么,消费者程序再次启动后,就没法再次从 List 中读取消息了,那么我们如何解决就这样情况呢?

为了留存消息,List 类型提供了 BRPOPLPUSH命令,这个命令的作用是让消费者程序从一个 List 中读取消息,同时,Redis 会把这个消息再插入到另一个 List(可以叫作备份 List)留存。
这样一来,如果消费者程序读了消息但没能正常处理,等它重启后,就可以从备份 List 中重新读取消息并进行处理了,实现也非常简单:

func (custom *Custom) ConsumerMessage(key1,key2 string) (string, error) {
   
   
    message, err := client.BRPopLPush(ctx, key1,key2,0).Result()
    id := custom.SplitMessage(message)
    if !custom.CheckId(id) {
   
   
        err := fmt.Errorf("id:%s is already processed", id)
        return "", err
    }
    return message, err
}

最后就有了我们最后的代码:

package main

import (
    "context"
    "fmt"
    "github.com/redis/go-redis/v9"
    sony "go-redis/sonyflake"
    "strings"
)

var client *redis.Client
var ctx context.Context

var idmap []string //不暴露到包外,避免被修改

type Custom struct {
   
   
}

type Product struct {
   
   
}

func Init() {
   
   
    client = redis.NewClient(&redis.Options{
   
   
        Addr:     "localhost:6379",
        Password: "",
        DB:       0,
    })
    ctx = context.Background()
    err := sony.Init()
    if err != nil {
   
   
        fmt.Println("Init sonyflake failed,err:", err)
    }
}

func (product *Product) AddMessage(key string, value any) error {
   
    //生产消息
    id, err := sony.GetID()
    if err != nil {
   
   
        return err
    }
    value = fmt.Sprintf("%d:%v", id, value) //添加id
    return client.LPush(ctx, key, value).Err()
}

func (custom *Custom) ConsumerMessage(key1, key2 string) (string, error) {
   
   
    message, err := client.BRPopLPush(ctx, key1, key2, 0).Result()
    id := custom.SplitMessage(message)
    if !custom.CheckId(id) {
   
   
        err := fmt.Errorf("id:%s is already processed", id)
        return "", err
    }
    return message, err
}

func (custom *Custom) SplitMessage(message string) string {
   
   
    str := strings.Split(message, ":")
    return str[0]
}

func (custom *Custom) CheckId(id string) bool {
   
    //检测id是否已经处理过
    for _, v := range idmap {
   
   
        if v == id {
   
   
            return false //该消息已经处理过了
        }
    }
    idmap = append(idmap, id) //添加到idmap
    return true
}

func main() {
   
     //测试样例
    Init() // 初始化 Redis 客户端和 Sonyflake

    product := &Product{
   
   }
    custom := &Custom{
   
   }

    // 测试数据
    testKey1 := "test-queue"
    testKey2 := "test-queue2"
    testValue := "Hello, world!"

    // 生产消息
    err := product.AddMessage(testKey1, testValue)
    if err != nil {
   
   
        fmt.Println("Failed to add message: %v", err)
    }

    // 消费消息
    message, err := custom.ConsumerMessage(testKey1, testKey2)
    if err != nil {
   
   
        fmt.Println("Failed to consume message: %v", err)
    }
    id := custom.SplitMessage(message)
    fmt.Println(id)
}

用List模拟消息队列缺点是比较多的,比如它不支持多个消费者消费同一条消息,因为一旦消费者拉取一条消息后,这条消息就从 List 中删除了,无法被其它消费者再次消费,在后面我们会介绍Stream这一数据类型,我们到时候会基于它实现功能更加强大的消息队列。

相关实践学习
基于Redis实现在线游戏积分排行榜
本场景将介绍如何基于Redis数据库实现在线游戏中的游戏玩家积分排行榜功能。
云数据库 Redis 版使用教程
云数据库Redis版是兼容Redis协议标准的、提供持久化的内存数据库服务,基于高可靠双机热备架构及可无缝扩展的集群架构,满足高读写性能场景及容量需弹性变配的业务需求。 产品详情:https://www.aliyun.com/product/kvstore     ------------------------------------------------------------------------- 阿里云数据库体验:数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库 ECS 实例和一台目标数据库 RDS实例。跟着指引,您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接,领取免费ECS&RDS资源,30分钟完成数据库上云实战!https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
相关文章
|
26天前
|
Shell Go API
Go语言grequests库并发请求的实战案例
Go语言grequests库并发请求的实战案例
|
15天前
|
缓存 NoSQL 应用服务中间件
Redis实战篇
Redis实战篇
|
15天前
|
存储 消息中间件 缓存
深入探析Redis常见数据类型及应用场景
深入探析Redis常见数据类型及应用场景
25 2
|
17天前
|
NoSQL Go API
go语言操作Redis
go语言操作Redis
|
1月前
|
安全 大数据 Go
深入探索Go语言并发编程:Goroutines与Channels的实战应用
在当今高性能、高并发的应用需求下,Go语言以其独特的并发模型——Goroutines和Channels,成为了众多开发者眼中的璀璨明星。本文不仅阐述了Goroutines作为轻量级线程的优势,还深入剖析了Channels作为Goroutines间通信的桥梁,如何优雅地解决并发编程中的复杂问题。通过实战案例,我们将展示如何利用这些特性构建高效、可扩展的并发系统,同时探讨并发编程中常见的陷阱与最佳实践,为读者打开Go语言并发编程的广阔视野。
|
15天前
|
存储 编译器 Go
Go to Learn Go之基本数据类型
Go to Learn Go之基本数据类型
24 0
|
2月前
|
运维 监控 NoSQL
【Redis】哨兵(Sentinel)原理与实战全解~炒鸡简单啊
Redis 的哨兵模式(Sentinel)是一种用于实现高可用性的机制。它通过监控主节点和从节点,并在主节点故障时自动进行切换,确保集群持续提供服务。哨兵模式包括主节点、从节点和哨兵实例,具备监控、通知、自动故障转移等功能,能显著提高系统的稳定性和可靠性。本文详细介绍了哨兵模式的组成、功能、工作机制以及其优势和局限性,并提供了单实例的安装和配置步骤,包括系统优化、安装、配置、启停管理和性能监控等。此外,还介绍了如何配置主从复制和哨兵,确保在故障时能够自动切换并恢复服务。
|
2月前
|
消息中间件 缓存 Kafka
go-zero微服务实战系列(八、如何处理每秒上万次的下单请求)
go-zero微服务实战系列(八、如何处理每秒上万次的下单请求)
|
2月前
|
缓存 NoSQL Redis
go-zero微服务实战系列(七、请求量这么高该如何优化)
go-zero微服务实战系列(七、请求量这么高该如何优化)
|
1月前
|
消息中间件 NoSQL Go
PHP转Go系列 | ThinkPHP与Gin框架之Redis延时消息队列技术实践
【9月更文挑战第7天】在从 PHP 的 ThinkPHP 框架迁移到 Go 的 Gin 框架时,涉及 Redis 延时消息队列的技术实践主要包括:理解延时消息队列概念,其能在特定时间处理消息,适用于定时任务等场景;在 ThinkPHP 中使用 Redis 实现延时队列;在 Gin 中结合 Go 的 Redis 客户端库实现类似功能;Go 具有更高性能和简洁性,适合处理大量消息。迁移过程中需考虑业务需求及系统稳定性。