这是我参与「第五届青训营 」伴学笔记创作活动的第 12 天
一、系统设计方法论
为什么要做系统设计
个人
面试、提升能力、拓展视野
工作
业务驱动、系统重构、突破创新
如何评估一个系统
- 易用性
- 可用性
- 安全性
- 扩展性
- 可维护性
- 性能
- 耦合性
- 伸缩性
系统设计的定义
为了达成某种目的,通过个体组成整体的过程被叫做系统设计
系统:
关联的个体
规则运动
组成工作的整体
设计:
设想和计划
目的
过程安排
二、电商秒杀业务介绍
电商介绍
消费者通过在线上平台订购,由产家供货完成的交易称为电商
秒杀业务的特点
瞬时流量高、读多写少、实时性要求高
秒杀的挑战
设计秒杀系统时需要考虑的诸多问题
- 高性能
- 资源成本
- 反欺诈
- 防止超卖
- 流量管控
三、如何设计秒杀系统
1.1 并发读写
秒杀要解决的主要问题是:并发读与并发写。
并发读的优化理念是尽量减少用户到服务端来读数据,或者让他们读更少的数据;并发写的处理原则一样,要求我们在数据库层面独立出一个库,做特殊的处理。
其次,还需要针对秒杀系统做一些保护,针对意料之外的情况设计兜底方案,以防止最坏的情况发生。
1.2 API设计原则
值得注意的地方是:如果想打造并维护一个超大流量并发读写、高性能、高可用的系统,在整个用户请求路径上从浏览器到服务端我们要遵循几个原则,就是保证用户请求的数据尽量少、请求数尽量少、路径尽量短、依赖尽量少,不要有单点
1.3 秒杀架构原则
1.3.1 高可用
整个系统架构需要满足高可用性,流量符合预期的时候肯定要稳定,就是超出预期也同样不能掉链子,保证秒杀产品顺利卖出。
1.3.2 一致性
数据必须一致,即成交总量必须和设定的数量一致。
1.3.3 高可用
系统的性能要足够强,支撑足够大的流量,不仅是服务端要做极致的性能优化,而且在整个请求链路上都要做协同的优化,每个地方都要快一点,整个系统就完美了。
本文将从这三个原则上来分别进行详细说明。
2. 架构原则
秒杀系统本质上是一个满足大并发、高性能和高可用的分布式系统。
2.1 数据尽量少
用户请求的数据能少就少,请求的数据包括上传给系统的数据和系统返回给用户的数据。
因为这些数据在网络上传输需要时间,其次不管是请求数据还是返回数据都需要服务器处理,而服务器在写网络的时候通常都要做压缩和字符编码,这些都非常消耗CPU,所以减少传输的数据量可以显著减少CPU的使用。
同样,数据尽量少还要求系统依赖的数据能少就少,包括系统完成某些业务逻辑需要读取和保存的数据,这些数据一般是和后台服务以及数据库打交道的。调用其他服务会涉及数据的序列化和反序列化,这也是CPU的一大杀手,同样也会增加延时。而且数据库本身也很容易成为瓶颈,因此越少和数据库打交道越好。