[Go]-抢购类业务方案

文章目录

抢购类业务常用于促销活动,如热销白酒、大月饼、低价显卡、抢票,用户是想挤进去抢到东西,商家端是吸引更多的流量,但是东西就是固定数额,肯定不想被恶意刷单或者超卖等场景,
这就对系统有强烈要求,这类业务需要处理高并发请求,以确保系统的稳定性和公平性,同时避免超卖现象。

抢购类业务(如秒杀)是一种在限定时间内,以极低的价格向消费者提供少量商品的促销活动。

Go语言在此类业务中有相当的优势,内存消耗低,天生支持并发,还可以离线打包,做一些小工具很方便。

公司业务中,防止频繁搜索,爬虫等,会用到令牌桶,进行限流;增减库存、消息队列、锁等,自己遇到的毕竟不全,列举下更多处理形式。

以下列举一些场景,和针对高并发的处理方式

要点:

1. 抢购/秒杀业务的关键挑战

  • 高并发处理: 秒杀活动通常会吸引大量用户同时下单,服务器需要处理大量并发请求。
  • 库存管理: 需要确保库存的准确性,避免超卖。
  • 事务处理: 要保证多个操作的原子性,确保数据一致性。

2. 技术方案

  • 缓存层: 利用Redis等缓存技术,将库存数据保存在缓存中,减少数据库的压力。
  • 消息队列: 通过消息队列(如RabbitMQ、Kafka等)来削峰填谷,将高并发请求排队处理,避免服务器被瞬间击垮。
  • 乐观锁/悲观锁: 使用数据库锁或乐观锁来保证库存的正确性和事务的完整性。

3.关键实现点

  1. Redis 原子操作:通过 Lua 脚本确保扣减库存和判断库存是否充足的操作在 Redis 中是原子性的。
  2. 并发模拟 :使用 sync.WaitGroup 模拟多个并发用户抢购。
  3. 库存管理 :Redis 的 decr 函数用于减少库存,并且确保不会超卖。

4.性能优化建议

  • 本地缓存 :使用内存缓存(如 sync.Map 或 LRU 缓存)减少频繁的 Redis 访问。
  • 读写分离:对高并发的读操作可以通过缓存层或数据库读写分离架构优化。
  • CDN 加速:对于静态资源或非关键请求,可以通过 CDN 缓解服务器压力。

5.其他考虑因素

  • 防止重复抢购 :可以通过 Redis 的 setnx 或数据库唯一索引避免用户多次抢购同一商品。
  • 分布式锁:在高并发场景下,可以通过 Redis 分布式锁或数据库锁确保多个实例对库存的操作不会冲突。
  • 请求日志和监控:记录用户请求日志和库存变化,便于监控和追踪问题。

细节拆分:

1. 高并发处理

抢购类业务通常伴随着大量并发请求。Go 语言的高并发处理能力让它在这种场景下非常适用。

  • goroutine 并发:Go 的 goroutine 可以轻松处理大规模并发。抢购时每个用户的请求可以用 goroutine 处理。

  • 限流:为了防止服务器超载,可以引入限流机制。常见的限流方式包括:

    • 漏桶算法:按固定速率处理请求,防止过多请求冲击系统。
    • 令牌桶算法:允许一定程度的突发请求,超出限额后将请求拒绝。

    Go 中可以使用第三方库如

    golang.org/x/time/rate
    

    实现限流。

2.限流与防护

防止大量恶意请求和超高并发打垮系统,通常会采取以下策略:

  • 接口限流:通过令牌桶算法、漏桶算法或 Redis 实现接口限流,控制每秒允许的请求数量。
  • IP 限制:限制同一个 IP 的请求频率,防止 DDoS 攻击。
  • 用户限流:对于每个用户设置抢购次数的限制,防止恶意刷单。

3.库存控制

抢购业务中,库存的控制非常关键,不能超卖或少卖。常用的方法有:

  • 本地缓存库存:在抢购开始时将库存加载到应用层内存中进行扣减,以提高响应速度。用完库存后,再同步更新到数据库中。
  • 分布式锁 :在多个应用实例之间控制库存时,可以使用分布式锁来保证同一时间只有一个实例操作库存,防止超卖。可以通过 Redis 的 SETNX 实现分布式锁,或使用诸如 Etcd、Zookeeper 等注册中心自带的锁机制。
  • 乐观锁 :通过数据库字段(如版本号或库存数量)进行更新时的版本控制来防止超卖。MySQL 支持通过 UPDATE 操作中的 WHERE 条件来进行版本检查。
  • **Lua脚本:**Redis 可以用来存储库存数据,并且通过 Lua 脚本实现原子性操作,避免超卖的情况。Redis 的高性能特性也非常适合高并发场景。
  • 预减库存:当用户发起抢购请求时,先在 Redis 中预减库存,确保高并发情况下不会超卖。
  • 最终库存确认:抢购成功后,再将最终的订单写入数据库,并从 Redis 中同步更新实际库存。如果用户未成功下单,Redis 中的库存会回滚。

4. 异步处理

抢购业务中,许多操作可以异步化处理,如订单生成、库存核减、用户通知等。

  • 消息队列:可以将用户的抢购请求推入消息队列(如 Kafka、RabbitMQ),后续再异步处理订单生成和库存扣减。这样可以避免数据库的直接冲击,提高系统的稳定性。
  • 异步任务队列:针对抢购结束后的订单处理和支付,可以使用异步任务队列(如 Celery)来处理非实时任务。

5. 数据一致性

为了确保数据在高并发下的一致性,需要控制并发修改的顺序和处理好数据库事务。

  • 事务机制:在处理订单时,可以通过数据库的事务机制来保证库存扣减和订单生成的一致性。
  • 分布式事务:在分布式架构下,通过 TCC (Try-Confirm-Cancel) 模式、2PC (Two-phase Commit) 或 SAGA 模式来保证分布式系统中的事务一致性。
  • 分布式锁:如果多台服务器处理抢购订单,可以通过 Redis 分布式锁来保证同一时刻只有一台服务器操作库存数据,防止并发操作造成超卖。

6. 常用架构设计

抢购类业务的架构通常包括以下几部分:

  1. 前端限流:通过 Nginx 等代理服务器进行限流,过滤掉部分请求。
  2. 服务端限流:使用 Redis、令牌桶等方式在服务端进一步限流,防止请求压力过大。
  3. 库存预加载:将库存放入 Redis 或本地内存中进行预处理,以提高响应速度。
  4. 异步处理:将订单生成、库存扣减、用户通知等操作异步化处理,提升抢购效率。
  5. 数据持久化:最终将抢购结果持久化到数据库中,并同步更新库存信息。

7. 代码示例

以下是一个简单的Go实现,用Redis管理库存,并处理用户的抢购请求:

golang 复制代码
package main

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

var ctx = context.Background()

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

    // 初始化库存数量
    rdb.Set(ctx, "item_stock", 100, 0)

    // 模拟并发抢购
    var wg sync.WaitGroup
    for i := 0; i < 200; i++ {
        wg.Add(1)
        go func(userID int) {
            defer wg.Done()
            err := purchaseItem(rdb, userID)
            if err != nil {
                fmt.Printf("User %d failed to purchase: %s\n", userID, err)
            } else {
                fmt.Printf("User %d successfully purchased the item.\n", userID)
            }
        }(i)
    }
    wg.Wait()
}

// 处理抢购请求
func purchaseItem(rdb *redis.Client, userID int) error {
    // 乐观锁机制,减少库存
    err := rdb.Watch(ctx, func(tx *redis.Tx) error {
        stockStr, err := tx.Get(ctx, "item_stock").Result()
        if err != nil {
            return err
        }

        stock, err := strconv.Atoi(stockStr)
        if err != nil || stock <= 0 {
            return fmt.Errorf("Out of stock")
        }

        // 使用事务保证库存减少的原子性
        _, err = tx.TxPipelined(ctx, func(pipe redis.Pipeliner) error {
            pipe.Decr(ctx, "item_stock")
            return nil
        })
        return err
    }, "item_stock")

    return err
}

这个示例采用乐观锁,当然也可以采用Lua脚本配合Redis扣减库存(为了防止库存超卖,通常会使用 Redis 的原子操作 来实现库存扣减)

golang 复制代码
// Redis 脚本实现原子扣减库存
local inventory = redis.call('GET', KEYS[1])
if (tonumber(inventory) <= 0) then
    return 0
end
redis.call('DECR', KEYS[1])
return 1

8. 进一步优化

  • 防止重复下单 : 利用Redis的SETNX命令可以防止用户重复下单。
  • 分布式锁: 在分布式系统中,使用Redis的分布式锁机制,确保只有一个请求能修改库存。
  • 动态限流: 利用令牌桶等算法对并发请求进行限流,防止流量瞬间过载。

9. 注意事项

  • 幂等性: 秒杀系统中,每个操作必须是幂等的,以防止因网络延迟或重试机制造成数据的不一致。
  • 数据库优化: 针对热点数据表的读写,需要做好索引优化、分库分表等设计。

通过这些手段,能够有效地提高抢购类业务的性能和稳定性。

相关推荐
直裾2 分钟前
scala借阅图书保存记录(三)
开发语言·后端·scala
唐 城23 分钟前
curl 放弃对 Hyper Rust HTTP 后端的支持
开发语言·http·rust
星就前端叭1 小时前
【开源】一款基于Vue3 + WebRTC + Node + SRS + FFmpeg搭建的直播间项目
前端·后端·开源·webrtc
小林coding2 小时前
阿里云 Java 后端一面,什么难度?
java·后端·mysql·spring·阿里云
AI理性派思考者2 小时前
【保姆教程】手把手教你在Linux系统搭建早期alpha项目cysic的验证者&证明者
后端·github·gpu
码银2 小时前
【python】银行客户流失预测预处理部分,独热编码·标签编码·数据离散化处理·数据筛选·数据分割
开发语言·python
从善若水2 小时前
【2024】Merry Christmas!一起用Rust绘制一颗圣诞树吧
开发语言·后端·rust
机器之心2 小时前
终于等来能塞进手机的文生图模型!十分之一体量,SnapGen实现百分百的效果
人工智能·后端
机器之心3 小时前
首次!大模型自动搜索人工生命,做出AI科学家的Sakana AI又放大招
人工智能·后端
运维&陈同学3 小时前
【模块一】kubernetes容器编排进阶实战之基于velero及minio实现etcd数据备份与恢复
数据库·后端·云原生·容器·kubernetes·etcd·minio·velero