系统架构设计面试题

十大经典系统架构设计面试题_架构_程序员石磊_InfoQ写作社区翻译自:https://medium.com/geekculture/top-10-system-design-interview-questions-10f7b5ea123d在我作为微软和Facebicon-default.png?t=N7T8https://xie.infoq.cn/article/4c0c9328a725a76922f6547ad

任何 SDI 问题的提示

  • 通过陈述你所知道的来开始每个问题:列出系统所需的所有特征,你期望在这类系统中遇到的常见问题,以及你期望系统处理的流量。列出清单的过程可以让面试官看到你的计划技巧,并在你开始解决问题之前纠正任何可能的误解。

  • 叙述任何权衡:每个系统设计选择都很重要。在每个决定点,列出至少一个积极和消极的选择的影响。

  • 让面试官澄清:大多数系统设计的问题都是有意模糊的。提出澄清问题,向面试官展示你是如何看待这个问题的,以及你对系统需求的了解。

  • 讨论新兴技术:总结每个问题,概述系统如何以及在哪里可以从机器学习中受益。这将表明你不仅为当前的解决方案做好了准备,而且也为未来的解决方案做好了准备。

一、设计一个 URL 缩短服务

当设计一个 URL 缩短服务时,会涉及多方面的考量和设计。

下面是一些可能会涉及的问题和讨论点:(除了项目特定需求,其他都是设计项目应该考虑的点)

  1. 功能需求:

    • 用户输入长链接,服务生成短链接。
    • 用户访问短链接时,被重定向到原始长链接。
  2. 设计考虑因素:

    • 性能和扩展性:高并发访问的处理、服务扩展能力。
    • 持久性:短链接和原始链接的存储方式,数据库选择等。
    • 安全性:如何确保链接安全性,防止被猜测、滥用或恶意使用。
    • 短链接生成算法:如何生成唯一的短链接,碰撞几率等。
    • 数据访问模式:读取和写入的比例,对存储系统的压力等。
  3. 存储方式:

    • 数据库选择:关系型、NoSQL、键值对存储等。
    • 数据模型:如何存储原始链接和对应的短链接。
  4. 短链接生成算法:

    • 如何确保短链接的唯一性?
    • 算法的设计和性能。
  5. 访问处理:

    • 如何处理短链接的访问请求?
    • 重定向的逻辑实现。
  6. 安全和防护:

    • 如何防止恶意用户生成大量短链接?
    • 访问权限控制等。
  7. 服务扩展:

    • 如何处理大规模的访问量?
    • 是否需要分布式服务?采用什么样的架构?
  8. 统计和分析:

    • 是否需要统计链接的点击次数?
    • 如何进行链接访问的分析和报告?
  9. 定期清理:

    • 如何处理长时间未使用的链接或者失效链接?
    • 是否需要定期清理数据库中的数据?
  10. API 设计:

    • 如果提供 API 服务,如何设计 API 接口?
    • 接口的权限控制和访问限制。
  11. 监控与告警:

    • 如何监控服务的稳定性和性能?
    • 针对服务异常如何设置告警和处理机制?
  12. 国际化和本地化:

    • 是否需要考虑多语言环境下的短链接生成和访问?
  13. 错误处理:

    • 如何处理用户访问错误、404 页面等异常情况?
  14. 容灾和备份:

    • 如何确保服务的高可用性?采取什么样的容灾备份措施?

二、案例分析:京东转链接

原始链接:福临门 粳米 5kg/袋【13.41】
https://item.m.jd.com/product/3911869.html?ad_od=share&utm_user=plusmember&gx=RnAomDgLPTTeyp5Z_sA9&gxd=RnAowmYKPGXfnp4Sq4B_W578vOMp4E7JgUugKDcomXTOIlSPI-BCnvuytD0G7kc&cu=true&rid=10109&utm_source=kong&utm_medium=jingfen&utm_campaign=t_2011419013_&utm_term=6a1e75e36a4b44ef938ebc20867d6fd0

转链接之后:福临门 粳米 5kg/袋【13.41】
https://u.jd.com/ZijidW8

组合方式

英文大小写[a-zA-Z] :合计有 52个= 26+26

数字[0-9]:合计有9个

(他估计能塞入其他符号)

合计有:62 = 26+26+10

7个位置可以放的商品是 3,521,614,606,208 = 62 ^ 7

理论上可以放3.5万亿的数据,够用。

关于jd的转法,我研究下再出个学习文章~

三、假如我来设计

1、长连接如何转成短链接? ShortGenerator

  1. 功能需求:

    • 用户输入长链接,服务生成短链接。
    • 用户访问短链接时,被重定向到原始长链接。
  2. 短链接生成算法:

    • 如何确保短链接的唯一性?
    • 算法的设计和性能。
  1. 考虑用 AES 加密算法 (但是需要消耗CPU)
  2. 考虑用UUID(但是uuid是字符串乱序的,如果存mysql做index的话,会有性能影响)
  3. 雪花算法,42位的long + 商品Id后8位 + 8位随机数字(单纯的42位容易被爬虫,商品id后八位,转完之后也才50位长度,放mysql的bigInt没问题,bigInt是64位),生成的纯数字有两个缺点太长 + 容易被暴力猜出来,那么可以转化成62进制(a-zA-Z0-9合计62=26+26+10)

2、链接之间的对应关系如何存储与转换

  1. 存储方式:

    • 数据库选择:关系型、NoSQL、键值对存储等。
    • 数据模型:如何存储原始链接和对应的短链接。
  1. Mysql (市面上的公司存储都用Mysql,因为他最成熟,最可靠)
  2. 数据通过 binlog异构到 Tair 或者 Redis (存缓存的目的是为了高效查)

3、如何实现高并发与可扩展?(分布式+动态伸缩)

  1. 设计考虑因素:

    • 性能和扩展性:高并发访问的处理、服务扩展能力。
    • 持久性:短链接和原始链接的存储方式,数据库选择等。
    • 安全性:如何确保链接安全性,防止被猜测、滥用或恶意使用。
    • 短链接生成算法:如何生成唯一的短链接,碰撞几率等。
    • 数据访问模式:读取和写入的比例,对存储系统的压力等

  1. 多机器多机房部署(挂了就切换机房)
  2. 服务器可以根据流量动态伸缩
  3. 关于DB的选择,肯定是选择mysql,关于缓存的选择,可以考虑Tair和Redis, Tair的优势是可以无限扩容,毕竟冷数据放磁盘,热数据放内存,Redis的话,用户群体相对较多,但是会淘汰数据,需要考虑缓存大面积失效的情况下,缓存雪崩给Mysql造成的大量query请求压力

4、如何防止恶意流量?

缓存穿透:redis失效,redis查不到数据,访问mysql拿到数据

缓存雪崩:大量的缓存穿透造成缓存雪崩

缓存击穿:redis查不到数据,mysql也查不到数据(恶意流量大概率是缓存击穿,干爆Mysql)

针对短链接服务,你可以考虑以下几种方法来防止缓存穿透:

方案描述缺点采纳
缓存空对象(Cache Null Objects)对于数据库中不存在的短链接,也将这些查询结果缓存,但设置一个较短的过期时间,这样可以在一定时间内拒绝相同的无效请求,同时减少数据库的访问次数。由于淘汰机制,如果此时来了大量的无效短链接请求,会把正常的缓存数据给冲掉。
使用限流器(Rate Limiter)对短链接服务进行流量控制,限制单个用户或IP地址的请求频率,以防止暴力遍历和恶意请求。攻击者还是有可能伪造大量的虚拟ip地址来进行攻击无法预防
CDN 防护使用 CDN(内容分发网络)作为中间层,可以对请求进行过滤,拦截无效请求,从而减轻服务器的压力。CDN 防护通常适用于已知的请求和基于静态内容的服务。对于不断变化的动态请求,CDN 防护的效果可能会受到影响。
布隆过滤器(Bloom Filter)使用布隆过滤器来过滤掉无效的短链接请求,它可以快速判断一个元素是否存在于集合中,如果元素不存在,可以直接拒绝请求,从而减轻对数据库的访问压力。无法删除数据,但是可以接受,毕竟是要拦截恶意请求
权限控制访问的时候,先检查登录状态,如果没登录,就直接拦截,如果登录了,那么配合限流器,对同一用户可以进行拦截(比如京东的短连接进去之后,都会先检查你是否登录)

可能影响用户体验(比如微博短连接跳进去老要求登录)

攻击者可能模仿多个用户多个ip进行攻击

5、数据统计

1、实时统计
  • 使用 SpringCloud的 Sentinel 进行流量控制与限流
  • Redis4.0后使用 redis-cli -h xxxxxx.com -a <password> --hotkeys
  • Redis4.0前用公司组件看
2、离线数据统计
  • 数据入 Hive (linkId,userid, dt(YYYY-MM-DD hh mm) , 商品id,门店id)
  • 按月、天、小时统计(门店访问量 Top100 ,商品访问量 Top100)

6、预警

假如我是淘宝,核心指标是门店id与商品id,

我关心的是

  • 某个门店某段时间内是否有尖刺流量,如果有,那是否是这家门店运营设置错价格出bug了?
  • 某个商品有尖刺流量,那么是不是这个商品价格设置有问题?
  • 某段时间所有门店流量突增,是不是有营销的同学在搞活动?
  • 查询或者写入接口流量突增,观察是不是某个业务方在刷数据?(根据来源的appkey,看看是不是业务方上线,代码有问题?需要回滚?)

上述都要求考虑应急方案,比如限流、比如熔断、比如机器扩容~

1、实时告警(超出阈值告警)
  • 根据门店id打点(该门店的商品被访问一次就打点一次)
  • 根据商品id打点(商品被访问一次就打点一次)
  • 接口流量尖刺告警
  • 接口流量跌零告警
2、离线数据预警
  • 如果某个门店,或者某个商品一直占据 Top100,去看看是否有问题

7、数据定期归档清理

  1. Redis中数据根据 LFU 自动淘汰,暂时无需处理
  2. Mysql 超出1年的数据,归档到 Hbase 里面去(如果放hive,hive查询响应很慢的)
  3. Mysql中数据的清理 delete,需要考虑分表分库下,对于同一个集群的写压力,删除数据后,记得治理表空洞(治理表空洞需要关注磁盘容量,记得及时删除临时表)
  4. 若存在删除链接的场景,Redis中布隆过滤器可以定期重新扫描生成。

数据的情况,可以考虑采用定时任务~

98、项目FAQ

99、项目应急预案

1、应急步骤

  1. 先通报,后处理(看到报警,先响应,然后通报给组内同事或者Leader)
  2. 先止损,后定位(该摘流量摘流量,服务上线到一半也先停止)
  3. 有变更,先回滚(配置变更,服务上线变更,先回滚)
  4. 预定级,要从重(引起重视)
  5. COE复盘(后续如何避免)

2、应急处理人员

  1. 总指挥
  2. 处理人(rd负责止损操作)
  3. 协调者(中间件的协助同学,比如需要替换机器、比如需要扩容,运营客服同学帮忙安抚客户)

3、服务的某台机器挂了

  1. 去哪个平台摘除流量?
  2. 去哪个平台 dump下现场环境?(保存堆栈信息)
  3. 去那个平台进行服务扩容?或者替换机器?

4、es挂了

  1. 能否降级到Mysql?
  2. 如何替换机器?
  3. 如何转移节点?
  4. 联系哪个运维同学?

5、tair

  1. 能否降级到Mysql
  2. 联系哪个运维同学?

6、Mysql挂了

  1. 能否降级?
  2. 联系哪个 DBA ?

7、kafak挂了

  1. 如何停止消费?
  2. 如何降级?
  3. 联系哪个运维同学?

  • 8
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值