综述
系统设计分类
系统设计类问题是面试常见的题目，也是提升个人架构思维和系统思维的好途径，本文会持续更新，记录一些经典的系统设计问题。
常见的系统设计问题，大概分为两个类型：
垂直场景的单模块设计，例如：如何实现短网址系统，如何实现ID生成器。单模块的设计，比较需要大家平时的技术积累，例如：分布式ID生成器，其实并没有他多需要原创的地方，需要大家对现有的技术方案有个比较好的掌握。
复杂系统的构建设计，例如：设计一个秒杀系统，设计一个交易系统。这类设计题，主要考察大家对业务场景的理解，以及常见技术栈的了解。复杂的系统设计，通常是将单个模块或者是各个技术模块，以最佳的实践组织起来。
思考路径&答题技巧
参考：https://www.pianshen.com/article/14071259841/
在工作中，我们需要有以文档结合会议口述的方式说明清楚自己的方案。在面试中，我们需要以口述的方式表述出自己的方案。这两者思考路径大致是一样的。这里面比较重要的一点是，系统设计通常有多个技术方案可以选用，所以需要给出各个方案的特点，以及选用相关方案的权衡过程。
明确需求场景和功能点
面试过程中，面试官的很多表述是模糊的，例如：
面试官这种模糊表述，很多时候是有意而为之，目的是想叫你列出，这个设计题可能的需求场景和功能点。系统设计通常没有标准答案，都需要根据场景来确定方案。
设计一个像bit.ly一样的URL缩短服务，这个功能设计之前，我们首先要明确需求场景：
访问的qps，从而预估是否需要高并发方案
整体用户规模，从而预估存储空间
SLA要求，如果是严格场景，必须有较高的sal，所以需要有高可用方案
需求点：
明确了场景和功能点后再去作答比较合理。
明确系统的
单模块设计
MQ消息队列相关
消息队列在分布式系统中有这有着广泛应用，主要用于一下场景：
解耦上下游应用：将服务之间的信息同步，从系统调用方式切换成消息队列后，可以有效提升系统的鲁棒性。整体系统可以无视单点故障，依赖mq的鲁棒性来保障系统的运行。
流量消峰：一条业务线的处理信息处理节点的吞吐量不同，通过mq的接入，可以平滑流量徒增造成的处理系统访问压力。
消息分发：标准的消息处理场景，通过mq来构建消息分发链路，可以降低消息生产者的开发难度。
异步处理：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生成器需要满足以下需求：
全局唯一：不能出现重复的ID
趋势递增：整体是增加的，不需要id之间连续，但是需要新ID数值层面大于旧ID
信息安全：ID最好是无规律的，不能通过ID+1获取系统的下一个ID，否则在部分场景下，如图片URL，视频ID，连续的id，给恶意抓取造成可乘之机，会造成安全漏洞。
ID长度尽量短：ID作为唯一标识符会留存在业务系统的各个存储系统中，例如：hive离线存储，Redis在线缓存，过长的ID会造成存储的浪费。
UUID
UUID(Universally Unique Identifier)
SnowFlake 算法
数据ID自增
复杂系统设计
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
