架构实战 - 毕业设计和知识点总结

知识点回顾

存储架构知识点回顾

复制架构：分为主从复制和主备复制。

主从复制是在会有一台主机和多台从机，主机进行读写，在读的同时，主机进行数据复制给从机，业务服务器在读的时候，会对任意一台主从机进行读。

主备复制是有多台备机进行数据复制，只有在主机出现问题时，才会切换到备机。

分片架构和分区架构

背景：当复制架构遇到性能瓶颈时，可采用分片分区架构。

• 主从复制的缺陷：主机承担写责任，写性能存在瓶颈。读是全量复制，存在读的瓶颈。

• 分片架构的本质：通过叠加更多的服务器来提升写性能和存储性能。将数据分片存储在不同的服务器上。

• 分区架构的本质：避免城市级别的灾难，提供就近访问。

存储架构设计思路

• 估算性能需求

有以下几种方案，规划：根据成本预算目标确定。推算：基于已有数据推算。对比：跟已有标杆进行对比

结果：这里主要是估算出 tps/qps，然后根据性能进行方案设计。

• 选择存储架构

选择存储系统的时候应选择技术本质相对应的存储技术。采用主从还是主备，是否要有集群选举、分区分表。

• 存储方案设计

计算架构知识点回顾

缓存架构

5 级缓存架构

重点：每级缓存技术的应用场景和常见技术

分布式缓存知识点

• 分布式缓存的两种架构模式

• 数据缓存一致性设计

• 缓存穿透、缓存雪崩、缓存热点原理出现的场景和解决方案

负载均衡架构

学习重点

• 负载均衡每一级的技术原理和应用场景，优缺点等等

• 负载均衡算法（轮询、加权轮询、随机、负载优先、性能优先、nginx）

• 业务负载均衡技巧

接口高可用

学习重点：每种方案的技术本质和优缺点。

微服务架构

微服务技术介绍

和 sop 的区别

微服务架构的技术挑战

1. 拆分力度越细，服务关系复杂

2. 拆分力度太细，团队效率下降

3. 拆分力度太细，问题定位困难

4. 拆分力度太细，系统性能下降

5. 缺乏基础设施，无法快速交付

6. 多个服务的数据一致性问题

7. 如何保证新老接口兼容（其他服务调用不同的接口），避免接口循环调用

学习重点：实现最终一致性的解决方案。

微服务拆分技巧

单体架构微服务化应该从非核心业务开始拆分，逐步完善基础设施，一方面是熟悉微服务的技术模式，一方面也能让团队成员进行试错，不会影响到核心业务。

异地多活架构

高可用架构三大核心原理

• FLP 定理：

safety：系统中非故障节点达成了一致和合法的共识，又称 agreement。

liveness：系统中非故障节点在有限时间内达成共识，又称 termination。

fault tolerance：协议必须在节点故障的时候同样有效。

• CAP

一致性：每次读取都会读到最新写入的数据，或者返回的数据。

可用性：每次请求都会得到非错请求，但是不保证返回最新的数据。

分区容忍性：系统在发生分区的时候继续提供服务。

• BASE：基本可用、软状态、最终一致性。base 理论就是 cap 中 ap 方案的完善落地后技巧，虽然没保证强一致性，但是保证了最终一致。

作业

项目背景：设计电商秒杀架构

背景要素提取：设计完整的架构，例如存储、负载均衡、缓存、高可用、高扩展

基本功能分析：商品选购、加入购物车、商品秒杀、登录、注册

信息：日活 80 万、老板说做到万无一失

秒杀架构方案设计思路

分析业务背景：登录、秒杀、商品浏览、添加购物车、下单

业务分析

1.高可用负载均衡高性能分析复杂度分析

2.存储性能估算

3.存储架构设计

4.计算性能估算

5.计算架构负载均衡

6.计算架构缓存架构

7.可扩展架构设计微服务拆分

8.详细架构设计/秒杀方案重点介绍

电商秒杀系统复杂度分析

先看题目中的几个重点技术背景，已经落地了微服务架构，目前只有单机房，老板要求万无一失，创业团队。所以我们的方案还是偏向于采用小成本的方案，尽量解决，至于那些成本较高的方案，需要跟老板进行讨论。

• 高可用：要求服务器能做到不宕机，关键服务能扛住压力，老板要求万无一失，这里我们有接口高可用，异地多活等方案，但是根据上下文的条件，我们还是采用接口高可用方案，这里下文有详细的方案设计

• 高性能：可以采用多级缓存，负载均衡架构。

• 一致性：不允许出现超卖等情况

电商秒杀系统性能模型估算

• 登录：假设秒杀当天的活跃用户达到 120 万，这里大概是一个时间点，抢购时间设置为半个小时，所以这里 qps 的大概为 1200000/1800 约为 666/s。

• 秒杀前，浏览商品信息等， 这里做 redis 缓存。

• 秒杀中：我们假设 120 万用户在 3s 内进行秒杀，所以这里的 qps 请求大概为 40w/s。

• 秒杀下单：秒杀活动选择 1000 个充电宝，12 台 iphone12 为秒杀商品，以 1000 个充电宝为订单数据，则秒杀成功下单 tps 为 1000/3=500/s。

电商秒杀系统架构方案设计

负载均衡

1. 根据上面两张图和大约 60w/s qps 计算，负载均衡每一级服务器数量：f5/lvs 一台就够了，nginx 大概 7 台左右，网关大概 15 台

2. 秒杀服务大多是在 redis 中进行，一台 redis 能支撑的最大 tps 假设为 4w/s，所以我们应该为秒杀服务准备的服务器大概在 13 台

3. 负载均衡算法采用轮询/随机算法

4. 如果预算足够的话可以考虑异地多活等架构

缓存架构

秒杀具体流程分析

这里我们可以采取以下措施进行减少服务器的压力

• 限流：当秒杀开始时，会有大量的请求到达服务器，为了减少服务器的压力，会限制部分请求，这里相关算法有令牌桶、漏桶算法。（这里参考京东秒杀茅台，当去下单时，会进行一步提示当前已无货，如果进行多次按钮， 会有时候进入到下单页面，然后去购买的时候还会提示货物已被抢光，相当于双重验限制）

• 削峰：减少高峰时期的请求，常见做法是采用验证码或者回答问题，一是快速拦截掉部分刷子流量，防止机器作弊，起到防刷的作用；二是平滑秒杀的毛刺请求，延缓并发，对流量进行削峰。还有一个就是异步消息队列，下图是流程图。

采用消息队列

参考案例分享：

https://blog.csdn.net/zhaohuodian/article/details/127056664

https://www.jianshu.com/p/1a177dfd40cb