常见的系统设计问题以及思路

综述

系统设计分类

系统设计类问题是面试常见的题目，也是提升个人架构思维和系统思维的好途径，本文会持续更新，记录一些经典的系统设计问题。

常见的系统设计问题，大概分为两个类型：

1. 垂直场景的单模块设计，例如：如何实现短网址系统，如何实现ID生成器。单模块的设计，比较需要大家平时的技术积累，例如：分布式ID生成器，其实并没有他多需要原创的地方，需要大家对现有的技术方案有个比较好的掌握。

2. 复杂系统的构建设计，例如：设计一个秒杀系统，设计一个交易系统。这类设计题，主要考察大家对业务场景的理解，以及常见技术栈的了解。复杂的系统设计，通常是将单个模块或者是各个技术模块，以最佳的实践组织起来。

思考路径&答题技巧

参考：https://www.pianshen.com/article/14071259841/

在工作中，我们需要有以文档结合会议口述的方式说明清楚自己的方案。在面试中，我们需要以口述的方式表述出自己的方案。这两者思考路径大致是一样的。这里面比较重要的一点是，系统设计通常有多个技术方案可以选用，所以需要给出各个方案的特点，以及选用相关方案的权衡过程。

明确需求场景和功能点

面试过程中，面试官的很多表述是模糊的，例如：

• 设计一个像bit.ly一样的URL缩短服务。

面试官这种模糊表述，很多时候是有意而为之，目的是想叫你列出，这个设计题可能的需求场景和功能点。系统设计通常没有标准答案，都需要根据场景来确定方案。

设计一个像bit.ly一样的URL缩短服务，这个功能设计之前，我们首先要明确需求场景：

1. 访问的qps，从而预估是否需要高并发方案

2. 整体用户规模，从而预估存储空间

3. SLA要求，如果是严格场景，必须有较高的sal，所以需要有高可用方案

需求点：

• 返回一个比原始URL短的URL

• 必须存储原始URL

• 新生成的URL必须能够链接到存储的原始

• 缩短的URL应该允许重定向

• 必须支持自定义短url

明确了场景和功能点后再去作答比较合理。

明确系统的

单模块设计

MQ消息队列相关

消息队列在分布式系统中有这有着广泛应用，主要用于一下场景：

1. 解耦上下游应用：将服务之间的信息同步，从系统调用方式切换成消息队列后，可以有效提升系统的鲁棒性。整体系统可以无视单点故障，依赖mq的鲁棒性来保障系统的运行。

2. 流量消峰：一条业务线的处理信息处理节点的吞吐量不同，通过mq的接入，可以平滑流量徒增造成的处理系统访问压力。

3. 消息分发：标准的消息处理场景，通过mq来构建消息分发链路，可以降低消息生产者的开发难度。

4. 异步处理：mq为异步处理提供了很好机制，之前的异步处理，是基于系统轮训 去回调查询状态来进行的，这样做会增加被调用方的网络负载。引入mq后，只需要系统执行完成后，向mq写入一条消息，调用方只需要监听mq即可。

使用mysql实现消息队列 wip

使用redis实现消息队列 wip

ID生成器

参考文章：https://mp.weixin.qq.com/s?__biz=MzU0OTE4MzYzMw==&mid=2247489483&idx=3&sn=fbf4945e6474d19ab98e99d4088fe441&chksm=fbb29e35ccc51723d20211820715346c70c25e6eaf49d80cde0314aff4ab2d072658038f1a3b&scene=21#wechat_redirect

在业务系统中，实体需要ID作为唯一标识符，进行管理查找了操作。例如：抖音的短视频，每个视频都需要持有一个ID，从而拉通视频生命周期的每一个业务和分析环节。在美团外卖，每一个订单都需要有个唯一ID，串联起从下单，到支付，再到配送中间的各个环节。

通常ID生成器需要满足以下需求：

1. 全局唯一：不能出现重复的ID

2. 趋势递增：整体是增加的，不需要id之间连续，但是需要新ID数值层面大于旧ID

3. 信息安全：ID最好是无规律的，不能通过ID+1获取系统的下一个ID，否则在部分场景下，如图片URL，视频ID，连续的id，给恶意抓取造成可乘之机，会造成安全漏洞。

4. ID长度尽量短：ID作为唯一标识符会留存在业务系统的各个存储系统中，例如：hive离线存储，Redis在线缓存，过长的ID会造成存储的浪费。

UUID

UUID(Universally Unique Identifier)

SnowFlake 算法

数据ID自增

复杂系统设计