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

为啥感觉互联网架构越来越复杂了，早期我们的系统，可能也就那么少部分人使用，大都是一些后台管理系统。
所以不用考虑很多东西，比如：

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

2 什么是秒杀/竞拍业务

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

只有少量的数据，却会在集中的时间段被一批人看到和抢购，集中式的高频读写。
业内也称为 群蜂请求 ，你可以想象下你捅了马蜂窝的场景。哈哈哈

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

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

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

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

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

公共数据做缓存
缓存是提升系统性能的重要手段。通过缓存热点数据，缓存还可以提高数据的访问速度，见很少对数据库的访问速度，提升用户体验。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篇集合

经过上面的保证之后，到数据层的量就很少了，大概率就是你定额的商品数量同等的数量。
比如1000，数据库绝对的扛得住的。
唯一可以做的就是检查数量是否符合预期，这个可以创建约束或者触发器来实现。

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

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