个人中心
gpt4 book ai didi

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

转载 作者：撒哈拉 更新时间：2024-07-19 11:16:44 59 4
gpt4 key购买 nike

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个月、用户进入黑名单等

image

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篇集合 。

image

3.3 数据层做终兜底

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

image

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

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

image

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

4 写在最后

  1. 无效请求拦截，尽量在前端完成，避免走入后端，造成服务端压力
  2. 缓存支持高性能检索、原子计算和有序队列
  3. 数据层做存储兜底
  4. 分治原理：单元化隔离，避免集中处理

最后此篇关于架构与思维：秒杀和竞拍的业务架构，永不过时的话题的文章就讲到这里了,如果你想了解更多关于架构与思维：秒杀和竞拍的业务架构，永不过时的话题的内容请搜索CFSDN的文章或继续浏览相关文章，希望大家以后支持我的博客！ 。

59 4 0
文章推荐： .NET单元测试使用AutoFixture按需填充属性的几种方式,以及最佳实践
文章推荐： 基于Three.js的3D模型加载优化
文章推荐： 解读GaussDB(forMySQL)灵活多维的二级分区表策略
文章推荐： 前端开发个人职业发展的四个阶段，你处于哪里？
撒哈拉
个人简介

我是一名优秀的程序员,十分优秀！

滴滴打车优惠券免费领取
滴滴打车优惠券
全站热门文章
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com