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

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中，高效地进行原子计数通常使用INCR、INCRBY、DECR、DECRBY等命令。这些命令都是原子操作，意味着在执行时不会被其他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. 分治原理：单元化隔离，避免集中处理