架构与思维:秒杀和竞拍的业务架构,永不过时的话题

1 互联网架构越来越复杂?

为啥感觉互联网架构越来越复杂了,早期我们的系统,可能也就那么少部分人使用,大都是一些后台管理系统。

所以不用考虑很多东西,比如:

  • 流量少,无需考虑并发问题
  • 数据少,不用考虑什么索引优化、分库分表
  • 访问不集中,不用考虑缓存、过载保护
  • 如果数据不重要,不用考虑安全策略,甚至不用考虑容灾备份
  • 可重复提交,所以不用关系幂等性
  • 允许短暂宕机和定期关停维护,所以不用考虑多活架构

但是随着互联网的普及和用户的激增,为了应对流量增量带来的各种问题,我们的架构体系衍生出很多强大的技术方案。

2 什么是秒杀/竞拍业务

秒杀业务也是随着互联网电商的发展而不断普及的,我们来看看普通业务和秒杀业务的区别

2.1 普通的业务

  1. 微信的个人信息:个人的注册信息,公众号、视频号的基础信息,微信好友列表,微信群列表。这种是 1:1 的,一般也不会被别人看到。
  2. 微信朋友圈:你盆友圈公开的内容是可以被多个好友看到的,你也可以对应看到你多个好友的盆友圈。这种是 1:n 的,多读的一种场景。

2.2 秒杀/竞拍业务

只有少量的数据,却会在集中的时间段被一批人看到和抢购,集中式的高频读写。

业内也称为 群蜂请求 ,你可以想象下你捅了马蜂窝的场景。哈哈哈

典型秒杀/竞拍业务案例:

  1. 春运前的火车票开售那一刻,可能瞬间有千万级请求涌入
  2. 将来某个遥遥领先开售,可能是一秒售罄

这些业务场景有如下技术难点:

  1. 瞬时流量特别大,你的接入层、应用层、数据层等能否扛得住
  2. 大量流量涌入 对一个数据进行操作,怎么保证数据原子增减、顺序公平性,怎么保证数据不超卖
  3. 如何 保证数据安全,如防攻击、防刷数、保持幂等
  4. 如果使用 并发控制,如何保证不产生死锁

所以,一个优秀的秒杀业务架构,在现在的互联网业务中,是一个永不过时的话题

3 如何优化

这边只针对几个对秒杀业务有效改进的点做展开,什么集群动态扩容、流量控制、弹性伸缩、智能限流啊,可以参考我的这篇文章《千万级流量冲击下,如何保证极致性能》。

3.1 清除无效请求

尽量在前面就把一些无效请求给清理掉,所以这些操作Web前端 或者 App Client端做就行了,越前端越好,尽量不要伤害到服务端,比如:

  • 未登录拦截
  • 重复提交拦截(未响应则按钮置灰,直至响应或者5S超时才恢复,幂等保证)
  • 频繁提交拦截(单用户一分钟不超过100次,避免AI刷机)
  • 验证码拦截(避免AI刷数据、黑客攻击等)
  • 参与条件拦截(可提前加载名单):如用户等级不够、注册未满3个月、用户进入黑名单等

3.2 服务端+缓存层做高效原子操作

公共数据做缓存

缓存是提升系统性能的重要手段。通过缓存热点数据,缓存还可以提高数据的访问速度,见很少对数据库的访问速度,提升用户体验。Redis单机每秒10w没什么问题,再加上多集群多副本模式。

原子操作保证秒杀的计数

在Redis中,高效地进行原子计数通常使用INCRINCRBYDECRDECRBY等命令。这些命令都是原子操作,意味着在执行时不会被其他Redis命令打断,从而保证了计数的准确性和一致性。

# 计算已售卖1000台库里南
> INCRBY cullinan_counter 1000

# 获取当前售卖数量
> GET cullinan_counter
> 1000

# 超过1000,返回秒杀失败

队列保证请求有序进入

使用Redis的 Stream 队列功能。Stream 实际上是一个 key,你可以使用 XADD 命令向其中添加消息。

XADD mystream * field1 value1 field2 value2

这里 mystream 是 Stream 的名称,* 表示让 Redis 自动生成一个唯一的消息 ID。field1 value1 和 field2 value2 是消息的内容,你可以根据需要添加任意数量的字段。

如果你只有1000台库里南供抢购,那么第1001就不要进入队列了。

扩展阅读

缓存可以扩展阅读作者的这个系列的文章:★ Redis24篇集合

3.3 数据层做终兜底

经过上面的保证之后,到数据层的量就很少了,大概率就是你定额的商品数量同等的数量。

比如1000,数据库绝对的扛得住的。

唯一可以做的就是检查数量是否符合预期,这个可以创建约束或者触发器来实现。

3.4 全球式业务,单元化处理

有些人可能会说,我的商品全球售卖,那我的缓存中心、数据中心放哪里,如果放中国,那跨地域跨机房访问,在0.1微妙都能决定我是不是买得到,欧洲的客户铁定抢不到库里南了。

现在的做法一般是单元化隔离,比如:

A/B中心都有这样的缓存或者数据结构,配置中心统一下发配置。然后在各自的单元里面玩耍,互不干预。 秒杀业务千万不要想着跨地域+跨机房,用户存在不公平性。

4 写在最后

  1. 无效请求拦截,尽量在前端完成,避免走入后端,造成服务端压力
  2. 缓存支持高性能检索、原子计算和有序队列
  3. 数据层做存储兜底
  4. 分治原理:单元化隔离,避免集中处理
相关推荐
运维&陈同学6 天前
【Elasticsearch03】企业级日志分析系统ELK之Elasticsearch访问与优化
大数据·elk·elasticsearch·搜索引擎·云原生·全文检索·高可用
MClink10 天前
聊聊系统的弹力设计-服务器性能指标篇(一)
运维·服务器·高可用
极客先躯13 天前
mysql 架构详解
数据库·mysql·架构·文件系统·半同步复制·高可用·主从复制
ChaITSimpleLove1 个月前
K8s 一键部署 MongoDB 的 Replica-Set 和 MongoDB-Express
mongodb·kubernetes·express·高可用·yaml·replica-set
OceanBase数据库官方博客1 个月前
如何实现主备租户的无缝切换 | OceanBase应用实践
oceanbase·分布式数据库·高可用
架构悟道1 个月前
不当愣头青、聊聊软件架构中的那些惯用的保命手段
java·分布式·架构·设计·高可用·可靠性·容错
OceanBase数据库官方博客2 个月前
OceanBase中扩容OCP节点step by step
oceanbase·分布式数据库·开闭原则·高可用·安装部署
冰 河2 个月前
【实战】Nginx+Lua脚本+Redis 实现自动封禁访问频率过高IP
redis·nginx·程序员·lua·高可用
DieSnowK3 个月前
[Redis][集群][下]详细讲解
数据库·redis·分布式·缓存·集群·高可用·新手向
DieSnowK3 个月前
[Redis][集群][上]详细讲解
数据库·redis·分布式·缓存·集群·高可用·新手向