架构与思维：秒杀和竞拍的业务架构，永不过时的话题
1 互联网架构越来越复杂？
为啥感觉互联网架构越来越复杂了，早期我们的系统，可能也就那么少部分人使用，大都是一些后台管理系统。
所以不用考虑很多东西，比如：
- 流量少，无需考虑并发问题
- 数据少，不用考虑什么索引优化、分库分表
- 访问不集中，不用考虑缓存、过载保护
- 如果数据不重要，不用考虑安全策略，甚至不用考虑容灾备份
- 可重复提交，所以不用关系幂等性
- 允许短暂宕机和定期关停维护，所以不用考虑多活架构
但是随着互联网的普及和用户的激增，为了应对流量增量带来的各种问题，我们的架构体系衍生出很多强大的技术方案。
2 什么是秒杀/竞拍业务
秒杀业务也是随着互联网电商的发展而不断普及的，我们来看看普通业务和秒杀业务的区别
2.1 普通的业务
- 微信的个人信息：个人的注册信息，公众号、视频号的基础信息，微信好友列表，微信群列表。
这种是 1：1 的，一般也不会被别人看到。 - 微信朋友圈：你盆友圈公开的内容是可以被多个好友看到的，你也可以对应看到你多个好友的盆友圈。
这种是 1：n 的，多读的一种场景。
2.2 秒杀/竞拍业务
只有少量的数据，却会在集中的时间段被一批人看到和抢购，集中式的高频读写。
业内也称为
群蜂请求
，你可以想象下你捅了马蜂窝的场景。哈哈哈
典型秒杀/竞拍业务案例：
- 春运前的火车票开售那一刻，可能瞬间有千万级请求涌入
- 将来某个遥遥领先开售，可能是一秒售罄
这些业务场景有如下技术难点：
-
瞬时流量特别大
，你的接入层、应用层、数据层等能否扛得住 - 大量流量涌入
对一个数据进行操作，怎么保证数据原子增减、顺序公平性
，怎么保证数据不超卖 - 如何
保证数据安全
，如防攻击、防刷数、保持幂等 - 如果使用
并发控制，如何保证不产生死锁
所以，一个优秀的秒杀业务架构，在现在的互联网业务中，是一个永不过时的话题
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 写在最后
- 无效请求拦截，尽量在前端完成，避免走入后端，造成服务端压力
- 缓存支持高性能检索、原子计算和有序队列
- 数据层做存储兜底
- 分治原理：单元化隔离，避免集中处理