[Go]-抢购类业务方案

在这里插入图片描述

文章目录

- 要点：
- - 1. 抢购/秒杀业务的关键挑战
  - 2. 技术方案
  - 3.关键实现点
  - 4.性能优化建议
  - 5.其他考虑因素
- 细节拆分：
- - 1. **高并发处理**
  - 2.**限流与防护**
  - 3.**库存控制**
  - 4. **异步处理**
  - 5. **数据一致性**
  - 6. **常用架构设计**
  - 7. **代码示例**
  - 8. 进一步优化
  - 9. 注意事项

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

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

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

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

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

要点：

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

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

2. 技术方案

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

3.关键实现点

Redis 原子操作：通过 Lua 脚本确保扣减库存和判断库存是否充足的操作在 Redis 中是原子性的。
并发模拟：使用 sync.WaitGroup 模拟多个并发用户抢购。
库存管理：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. 常用架构设计

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

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

7. 代码示例

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

golang">package mainimport ("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.WaitGroupfor 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) thenreturn 0
end
redis.call('DECR', KEYS[1])
return 1