这是我参与「第五届青训营」伴学笔记创作活动的第7天
内容梗概
本文主要梳理了以下内容：
- 啊啊
- 俺是
- 是
1 系统设计方法论
1.1 基本概念
1.1.1 概述
系统设计：为了达成某种目的，通过个体组成整体的过程。
系统设计流程：（4S分析法）
1.1.2 其他基本概念
-
压测指标
- 事务：一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。
- TPS：（Transactions Per Second），服务器每秒处理的事务数。客户机在发送请求时开始计时至收到服务器响应后结束，以此计算使用的时间和完成的事务个数。
- QPS：（Queries Per Second），服务器每秒处理的查询数。现在习惯对单一接口服务的处理能力用QPS表述（即使它并不是查询操作）。QPS基本类似TPS，不同的是，对于一个页面的一次访问，形成一个TPS；但一次页面请求，可能产生多次对服务器的请求，这些对服务器的请求，就可计入QPS中。
- RT：（Resonse Time），响应时间。处理一次请求所需要的平均时间。
- 并发数：系统能同时处理的请求数量。
- 吞吐量：反映系统对request的处理能力。（单个request对CPU消耗越高，外部系统接口、IO响应速度越慢。吞吐能力越低，反之越高。）
1.2 发现系统的瓶颈
- 火焰图分析：针对单个实例（CPU、内存的使用）的分析，找到代码的一些瓶颈。
- 链路追踪：对于微服务而言（一次请求对应有成百上千的服务），对同一个请求做链路追踪，了解该请求经过了哪些服务，在每个服务上的耗失是多少。因此，借助链路追踪可分析一次请求在哪些服务上的耗失比较大。
- 性能测试：用于发掘整个系统性能的不足。
1.3 可用性、稳定性保证
- 链路梳理：对于微服务要梳理出一条核心链路（分清主次）。
- 核心链路 ：以电商系统为例，包含其核心的功能，如：商品详情、计算价格、提单、下单、支付等。（其他的为非核心链路，若非核心链路发生错误，可适当降级，核心链路不能降级）
- 流量漏斗：流量的层级性提纯。（如所浏览的商品，仅部分会加入购物车；购物车中的商品仅部分会下单购买）
- 强弱依赖：弱依赖可降级，强依赖不可降级。（参看“核心链路”）
- 可观测性：对系统各项指标的可观测性。
- 链路追踪：对一次请求做全链路上微服务的追踪。
- 核心监控：监控核心指标。
- 业务报警：基于核心监控，对核心业务异常作出报警
- 全链路测试
- 压力测试：接近或超过链路压力的临界点，观察其服务表现（是否仍能满足服务的可用性）。
- 负载测试：测试出链路的负载大小。
- 容量测试：测试出系统容量的大小（容载能力）。
- 稳定性控制：通过一些手段保障系统的稳定性。
- 系统限流：限制流量，是一种有效保护系统稳定性的手段。
- 业务兜底：下游依赖返回错误，当前服务可返回一些兜底数据。
- 熔断降级：非核心链路（弱依赖）发生错误可降级，参看“强弱依赖”。
- 容灾演练
- 混沌工程：以故障注入的方式，进行一些故障演练。
- 应急手册：通过演练等，总结沉淀出一些故障应对手册。
- 容灾预案：当某些核心服务出现故障时，需要启动该预案。
2 电商秒杀业务
2.1 基本概念
商品：具有交易价值和属性的信息载体。
SPU：标准产品单元（Standard Product Unit），标准化以降低管理成本。
SKU：库存保持单元（Stock Keeping Unit），含有库存、交易价格等信息的一种交易属性概念。
2.2 秒杀业务
2.2.1 秒杀业务特点
- 瞬时流量高（如准点秒杀、定时秒杀）
- 读多写少（刷新读取次数远比下单多）
- 实时性要求高（下完单立马出结果）
2.2.2 秒杀的挑战
- 资源成本：系统资源有限，但工作体量大。
- 反欺诈：秒杀商品的价格一般比较低，容易引起黄牛、虚假二次售卖等。
- 高性能：实时性高，性能要求也高。
- 防止超卖：秒杀产品价格较低，库存有限，因此要严格控制可下单量，防止超卖，确保销售量<= 库存量。
- 流量管控：商品数量是有限的，对应所需的流量也应在合适的范围内（不一定是越大越好），过大的流量反而可能是种资源浪费，因此需要对一些无用的流量作出拦截、过滤。
- 扩展性
- 鲁棒性
2.3 秒杀系统设计
采用4S分析法（参考1.1），从场景分析、存储设计、服务设计、可扩展性这几个角度设计秒杀系统。
2.3.1 场景分析
- 功能
- 秒杀活动发布（商家侧、写接口）
- 秒杀商品详情（用户侧、高流量的读接口）
- 秒杀下单（写接口）
- 并发
- 万人参与秒杀
- QPS：1w+
- TPS：1k+
2.3.2 存储设计
三级存储：
