[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. 注意事项

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

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

相关推荐
Asthenia04121 小时前
Spring扩展点与工具类获取容器Bean-基于ApplicationContextAware实现非IOC容器中调用IOC的Bean
后端
bobz9651 小时前
ovs patch port 对比 veth pair
后端
Asthenia04121 小时前
Java受检异常与非受检异常分析
后端
uhakadotcom1 小时前
快速开始使用 n8n
后端·面试·github
JavaGuide2 小时前
公司来的新人用字符串存储日期,被组长怒怼了...
后端·mysql
bobz9652 小时前
qemu 网络使用基础
后端
Asthenia04122 小时前
面试攻略:如何应对 Spring 启动流程的层层追问
后端
Asthenia04122 小时前
Spring 启动流程:比喻表达
后端
Asthenia04123 小时前
Spring 启动流程分析-含时序图
后端
ONE_Gua3 小时前
chromium魔改——CDP(Chrome DevTools Protocol)检测01
前端·后端·爬虫