手把手带你搭建秒杀系统
佘志东
前京东交易平台(上海)负责人、资深架构师
12374 人已学习
新⼈⾸单¥59
登录后,你可以任选2讲全文学习
课程目录
已完结/共 18 讲
前期准备:技术选型与环境准备 (2讲)
准确无误:打造不超卖和公平的秒杀系统 (2讲)
雷令风行:性能调优更上一层楼 (3讲)
手把手带你搭建秒杀系统
15
15
1.0x
00:00/00:00
登录|注册

08|化骨绵掌:降级、热点和容灾处理

你好,我是志东,欢迎和我一起从零打造秒杀系统。
上节课我们介绍了秒杀的削峰,你在手写秒杀系统的时候,可以采用验证码 / 问答题、异步消息队列或者限流的方式进行削峰,以此平滑流量峰值,减轻单位时间分片内的系统压力。这节课我们将把重点放在其他高可用的方面——降级、热点数据和容灾,持续打造秒杀系统的高可用
当秒杀活动开启,流量洪峰来临时,交易系统压力陡增,具体表现一般会包括 CPU 升高,IO 等待变长,请求响应时间 TP99 指标变差,整个系统变得越来越不稳定。为了力保核心交易流程,我们需要对非核心的一些服务进行降级,减轻系统负担,这种降级一般是有损的,属于“弃卒保帅”。
而秒杀的核心问题,是要解决单个商品的高并发读和高并发写的问题,这是典型的热点数据问题,我们需要有相应的机制,避免热点数据打垮系统。
机房容灾其实不仅仅是秒杀系统需要思考的,重要的软件系统,不管是互联网应用,还是传统应用,比如银行系统等,都需要考虑机房容灾的问题。不同的场景,容灾的设计也不尽相同,这节课我们将从常见的互联网公司的角度,看看他们一般会怎么搭建交易系统的容灾。

降级

我们先说说“降级”,其实和削峰一样,降级解决的也是有限的机器资源和超大的流量需求之间的矛盾。如果你的资源够多,或者你的流量不够大,就不需要对系统进行降级了;只有当资源和流量的矛盾突出时,我们才需要考虑系统的降级。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

在构建高可用秒杀系统时,面临着降级、热点数据和容灾处理等挑战。本文首先强调了降级的重要性,详细分析了写服务降级、读服务降级和简化系统功能等方面的解决方法。其次,针对热点数据问题,提出了避免热点数据对系统造成影响的机制。文章深入讨论了读热点和写热点的解决方案,包括增加热点数据的副本数、让热点数据离用户越近越好等解决思路。最后,强调了在设计交易系统时需要考虑容灾问题,介绍了“同城双活”方案的设计。通过对降级、热点数据和容灾处理的讨论,读者可以了解到在构建高可用秒杀系统时需要考虑的关键技术特点和解决方案。文章内容涵盖了降级策略、热点数据处理方式以及容灾方案,为构建高可用秒杀系统提供了重要参考。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《手把手带你搭建秒杀系统》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(10)

  • 最新
  • 精选
  • nana👄
    预约总人数取随机数的流程图没看懂,老师可以解答下吗

    作者回复: 取随机数主要是解决异步计数带来的用户体验问题,单从解决性能问题的角度看,我们可以不取随机数,也可以每次100后累加,但是这样,前端用户看到的预约人数就是成百的增加,会被质疑计数的真实性,带来投诉。

    2021-10-18
    5
    6
  • 公号-技术夜未眠
    所以,如果是异地多活的情况,一般是需要把数据划分成不同单元,让流量在单元内闭环 请问,这句话怎么理解了?谢谢

    作者回复: 这是单元化的解决方法,在多活机房建设中,把数据按照一定规则划分成不同的单元,比如按照用户hash,这样单元内的业务层,缓存层,db层都闭环在单元机房内,避免了跨机房的调用。当然数据能不能划分成单元,也要看数据特性,像一些配置类的数据就不太适合,这样的数据可以放在中心机房,而一些用户相关的数据就可以进行单元划分

    2021-10-31
    1
  • 小鱼儿吐泡泡
    问题: 热点数据如何发下你,以及预警? -- 可以使用统计计数,当统计计数达到阈值,则进行告警

    作者回复: 是的,需要对不同的redis key统计计数,但要注意避免统计计数成为单点热点,可以单实例对key进行计数。

    2021-10-24
    1
  • 小五
    热点数据处理方案中一致性问题比较大,具体实现还要看业务要求,基于 CAP 折中。

    作者回复: 是的,在处理高并发场景时,很多时候需要根据cap折中,而为了高性能,一致性问题往往是可以先妥协的

    2021-10-16
  • 🇨🇳范💢er
    老师,一个写热点问题。 我思考了一个场景,请教下: 某个爆品SKU商品库存有5W, 瞬间来了20W的请求, 也就是此时有20W用户都在点击。 经过重重限流过来 还剩5W的请求, 瞬间打到Redis,而那个爆品的redis Key只在一台redis上, 假设这一台Redis又扛不住。 那该怎么办呢?
    2022-01-25
    3
    1
  • 李雪楠
    老师我有个问题想请教下。redis中有个库存key,nginx通过这个key来判断库存是否足够,从而判断是否用户请求进入业务服务器。并且此时下单成功的用户也会对这个key进行--的操作。那么高并发的情况下,这个key的一致性应该如何保证呢?比如key的初始值为10,50w用户统一时刻访问,那么读取到的key都是10,那么都会进入业务系统,然后这50w都是用lua脚本(1)、get;(2)、-1。从而使得库存减少。像这种情况要怎么解决呢?
    2023-05-08归属地:北京
    1
  • pc
    “.对单 SKU 的库存直接在 Redis 单分片上进行扣减”这个没有理解,是指一个sku就指定放在一个redis实例?相当于10个秒杀sku就对应10个redis实例?
    2022-02-13
  • 半夏
    有体系,很好的经验积累
    2021-11-16
  • 每天晒白牙
    配置中心下发降级开关这种操作我理解属于人为介入,在处理问题上会不会有时延 感觉自动触发降级策略比较好 老师在自动降级这点上有啥经验分享不
    2021-11-10
  • 一个卖火柴的老男人
    如饥似渴,太给力了!膜拜
    2021-10-15
收起评论
显示
设置
留言
10
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部