容量保障核心技术与实战
吴骏龙
前阿里巴巴本地生活P8高级专家
新⼈⾸单¥55
546 人已学习
课程目录
已更新 7 讲 / 共 17 讲
0/2登录后,你可以任选2讲全文学习。
开篇词 (1讲)
开篇词 | 互联网时代,人人肩负容量保障的职责
免费
基础篇 (4讲)
01 | 容量保障的目标:容量保障的目标是什么?该如何度量?
02 | 容量测试与验证:怎样科学实施容量测试?
03 | 容量指标分析经典5问:响应时间真的是越短越好吗?
04 | 容量治理的三板斧:扩容、限流与降级
进阶篇 (2讲)
05 | 全链路压测:系统整体容量保障的“核武器”(上)
06 | 全链路压测:系统整体容量保障的“核武器”(下)
容量保障核心技术与实战
15
15
1.0x
00:00/00:00
登录|注册

06 | 全链路压测:系统整体容量保障的“核武器”(下)

吴骏龙 2021-05-24
你好,我是吴骏龙。
上一讲,我为你讲解了在正式实施全链路压测前,我们要做的三项改造工作,包括数据隔离、中间件改造和应用服务改造。这一讲,我们就正式进入两项压测工作:压测模型构建和压测流量构造,把全链路压测的建设过程完整展示给你。除了技术工作之外,在这一讲中我还会与你分享全链路压测的组织协调和运营工作,它们对全链路压测的完整落地同样起到至关重要的作用。
我们先看看如何构建压测模型。

两项压测工作:压测模型构建

构建压测模型的重点是准确度,如果模型与真实场景相差过大,那么压测结果的可参考性将会大打折扣,下面是一些典型的由于压测模型不准确导致压测结果无效的反面教材:
下单链路中,压测用户没有使用红包,导致对营销服务的压测结果偏优。
压测用户数据未考虑 sharding 分布,导致数据库单片过热。
压测用户数量过少,使用有限的压测用户反复下单后,导致单个用户订单量过多。
压测商户数量过少,压测时针对单个商户的操作过于密集,导致菜品扣减库存的锁争抢激烈。
压测模型包含业务模型和数据两部分,我再来通过几个实例讲解一下如何构建尽可能真实的场景。
实例一: 读请求
读请求由于不会对数据造成污染,因此可以直接使用真实请求和数据进行回放。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《容量保障核心技术与实战》,如需阅读全部文章,
请订阅文章所属专栏新⼈⾸单¥55
立即订阅
登录 后留言

精选留言(1)

  • Roy Liang
    原因可能是全链路压测不能完全复刻外部依赖接口,例如银联支付等场景

    作者回复: 回答的不错!对外部依赖的第三方接口调用处理不好,很容易成为全链路压测场景失真的一个因素。改进这一点的策略就是尽可能仿真,比如针对支付场景,我们可以mock支付回调,并按照真实回调的响应时间设置一定的延时,甚至可以制造一些波动,来尽可能逼近实际情况。

    2021-05-24
收起评论
1
返回
顶部