场景题目

函数调用次数

题目:

设计一个函数,返回最近 5000 毫秒内本函数被调用的次数,不使用外部存储。能够承载高并发场景,性能、空间尽可能优化。

思路(不确定是否最优):

  • 变量:1)5000 长度的 AutoInteger 数组 2)上一个时间戳。3)sumvalue 4)可能需要锁
  • 毫秒级时间戳映射到对应的起始点;判断失效的存储位置,当前时间戳位置+1;更新 sumvalue

排队与倒计时场景

  1. 排队任务,显示前面还有多少人+还有多长时间
  2. 实现一个显示等待人数以及大概多长时间就绪的游戏等待提示。

大数据去重

大数据分析常用去重算法分析_大数据_陶加涛_InfoQ精选文章

如何在 1 秒内做到大数据精准去重? - 知乎

大数据去重方案 - jingsupo - 博客园

如果有两份 50G 的数据,要查重,内存 4G,怎么查?

想法是先将 50G 的数据分别做 hash%1000,分成 1000 个文件,理论上 hash 做得好那么这 1000 个文件的大小是差不多接近的。如果有重复,那么 A 和 B 的重复数据一定在相对同一个文件内,因为 hash 结果是一样的。将 1000 个文件分别加载进来,一一比对是否有 hash 重复。这种想法是先把所有数据按照相关性进行分组,相关的数据会处于同样或者接近的位置中,再将小文件进行对比。

有 1 千万条短信,找出重复出现最多的前 10 条?

可以用哈希表的方法对 1 千万条分成若干组进行边扫描边建散列表。第一次扫描,取首字节,尾字节,中间随便两字节作为 Hash Code,插入到 hash table 中。并记录其地址和信息长度和重复次数,1 千万条信息,记录这几个信息还放得下。同 Hash Code 且等长就疑似相同,比较一下。相同记录只加 1 次进 hash table,但将重复次数加 1。一次扫描以后,已经记录各自的重复次数,进行第二次 hash table 的处理。用线性时间选择可在 O(n)的级别上完成前 10 条的寻找。分组后每份中的 top10 必须保证各不相同,可 hash 来保证,也可直接按 hash 值的大小来分类。

场景

实现一个功能,给定任何一篇文章,检查这篇文章里面是否包含几百个关键词中的任何一个?
文章怎么分成一个个词呢?文章分成一个个词算法复杂度是多少?

  • 场景题:开 10 个线程读取一个大文件,每个线程读特定的一段,怎么保证线程互相之间不会读到别的线程需要读的内容——这个我真没搞懂是什么意思
  • 场景题:现在视频面试的过程中如何建立连接,视频和音频怎么样在网络中传输

系统设计

复杂度

系统设计可能遇到高性能、高可用、高扩展、成本(人力/时间/资源/金钱)、安全、规模化中一个或多个问题。

学习方法

twi 上搜索 alex xu 看看吧或者油管上搜印度小哥的 sys design
油管也挺多的
《system design interview》
github 的 system design primer 也刷过 2 遍,常规的 scaling,caching,nosql,sharding,cap,calculation 也基本熟悉,

  1. ddia 《数据密集型应用系统设计》
  2. alex xu 的 system desgin interview
  3. grokking system design interview
  4. understanding distributed systems 2nd edition
  • 系统设计经典题库
    • educative.io ,收费的,但是油管上一堆免费讲解的。淘宝可以买这家网站的会员,便宜一些
    • bytebytego alex xu

架构整洁之道,密集型应用系统设计
P of EAA
领域特定语言
分析模式-可复用对象模型
实现领域驱动设计
unix 设计哲学
YouTube 上有 Google 官方的 system design interview 流程指导和很多老外的 mock interview。题目本身不难,但是要熟悉流程+全程英语+能绘制合适的架构图 or 流程图

题目

秒杀系统
设计 rpc
短链接
排行榜
微信抢红包
设计点赞功能
微博 feed 流或微信朋友圈
定时任务
分布式 id 锁事务
各种海量数据处理
设计一个延时队列
健康码扫码系统
演唱会抢票系统可以一次买多个票连排的
可以补充点 ood 的题例如设计停车场系统
二维码登入
基于 Redis 分布式调度任务
设计微信搜索系统
短链接
设计高并发系统,水平分表策略,接口的安全性幂等性响应慢

你讲的都是技术层面,殊不知系统设计要先看什么业务,和面试官沟通业务,然后做需求分析,产出用例,领域模型,技术选型,边缘 case 的取舍,会用到什么中间件和工具实现等等,这是开放性的考验你的思维模型的东西。

system design 很容易判断水平的,网上那些只是套路,告诉你该怎么回答问题,但是很多实践细节和取舍,没有自己做过是不清楚也说不到的。还有算法“过”的标准不是你写出来能跑就行,理想情况是一次性 bug free 再加规范 unit test.

系统设计没办法说完全靠经验不是你看到几个架构套来套去就行涉及很多方面

可能你不信,有不少小年轻就是硬背的啊。不是每个人都有机会设计完整的系统的,很多人只能背啦

统一回复下,学习或者备考系统设计的方法,只做参考。1,学习短网址,news feed 等经典的 10 个案例,system design prime 好像有 2,九章算法里面这些套路,记得一定面试的时候多交流,通过数学计算跟 tradeoff 给出合适的结论跟方案

你可以先学习一下最基本的 10 个系统设计案例,github 搜索九章算法系统设计,这种面试很多都是程式化的,system design 不分前后端

权限系统设计
分布式 id 系统设计
秒杀系统设计
短链系统设计
任务调度系统设计
分布式事务问题处理
rocket MQ 各个组件及功能
kafka 各个组件及功能
两个 MQ 区别及使用场景
服务治理如何进行
RPC 框架的结构及运行机制原理
DDD 在项目中的实践,洋葱模型和六边形模型
幂等如何处理
数据库和缓存一致性问题
spring 的初始化过程,自动装配
mvcc,间隙锁,当前读快照读
SQL 优化,分库分表
juc 内容,ThreadLocal

分布式 id 设计,分布式限流,定时任务调度,负载均衡,序列化,压缩,分布式一致性协议,,top k 问题,im 系统,feed 系统,搜索引擎,推荐引擎等等

设计个电梯系统。设计个微信朋友圈,字节面试官问的
一亩三分地就有,现成外企面试题

先设计后研发,找业界对标,参考开源实现,难度挺大
中间件是这样的

我说个油管上官方视频公开的吧:“设计一个短网址系统”,面试官就这一句话,没了。剩下所有的需求都要你开口去问去确认,甚至还有先要求低,后面再考你怎么修改架构扩容这种环节。

沟通,业务建模,技术建模,核心业务及质量需求,权衡能力,都在考察项内

设计一个直播系统

做个游戏匹配系统,怎么做?

设计一个弹幕系统

从方案设计,稳定性设计,容量设计,降级容错方案等方面展开

你自己多考虑啊,各种场景,比如你刷剧,思考下弹幕系统实现,停车场 etc 怎么实现,每段时间自己有个问题点,然后再去思考和积累,这东西研究多了发现很多东西共通的

第二个 tech2,图片上传系统设计,图片断点续传系统设计。因为我是前端,答得非常不好,数据库表设计不出来满意的,也没考虑太多缓存。(确实没深入做过后端)

如何设计评论系统,需要哪些 api,几张数据库表,怎么维护嵌套评论
内部是一个评论中台系统,到你们这一个表吊打一切

一张评论表足矣。按帖子 id hash 分表。结构:贴子 id,from,to,time。数据取出,直接丢给前端,to 默认为 none。时间排序。完毕。
Hash 分表是不是会导致冷热不均?那得看你怎么 hash 了。

用户评论表:保存用户发表的评论
评论表:评论 id 评论数据父 id(嵌套关系) 时间评论主体 id 层级,评论 id 作为主键,唯一 id 生成,按主体 id 分表,首先按主体 id 拉取一级评论列表(父 id 为 0),拉取某个评论的下一级评论列表,查父 id 等于该评论 id 即可
点赞表:id 点赞人 id 点赞的评论 id 点赞时间,按评论 id 分表,量不大放一个表也行
api: 发表拉取主体 id 下评论列表等

嵌套评论 - 有点像存储一个树的形式

微信朋友圈怎么设计?
分布式缓存系统怎么设计?
微博粉丝关注怎么设计?
红包系统怎么设计?
消息系统怎么设计?

面试题,有 100w 滴滴司机,司机每 3s 上报一次自己的位置。请你设计一个系统,能够实时的将司机的位置存储进系统,并且能够给另外一个系统实时显示路径(每 3 秒刷新一次最新点),历史数据要能够随时可以查询。
那些说 es hbase 这些东西的真是笑死我了,这题考的不是工具考察的重点是数据结构 quad tree。是道北美经典 system design 面试题, design uber。
首先分成上报模块和消费模块,通知可以通过 pull 模式,避免写放大。上报模块每个公司都有可靠上报系统,没有就自己用 kafka 等消息系统上报,这个量级(三秒百万数据)基本属于大数据范畴了,不可能用传统存储模型,后台可通过 flink 消费流式数据放到 hive/hbase 等存储模型,其他存储结构如果选择也需要选择写性能友好的,存储可扩展的,但写性能友好的需要优化读,如果允许秒级别延迟,可以导入到 click house,或者上 Cassandra 等
不建议用时序数据库,业务场景不匹配,时序数据库通常适合固定采样时间埋点上传,写多读少,越是历史数据读性能也越差,通常不直接用于线上业务系统
http 消息上报,写到 kafka 用 flink 消费,flink 端两条 sink 链路,kafka2hive 存放全量数据用作离线,kafka2starrocks,用 olap 引擎实时查询,做各种聚合计算

面试题,有100w滴滴司机,司机每3s上报一次自己的位置。请你设计一个系统,能够实时的将司机的位置存- 脉脉

最近想学系统设计,但是时间比较紧,想临时冲击一下,有没有系统设计的大佬想挣外快?给我1V1培训,一个- 脉脉

system-design-primer/README-zh-Hans.md at master · donnemartin/system-design-primer · GitHub

停车场管理系统

最基本的内容:

  • 用户角度:停车需求
    • 根据车辆进出,获得停车场内剩余车位个数,提供能否停车的需求
  • 服务角度:收费需求
    • 根据车辆进出,获得车辆在停车场存留时间,生成对应价格

单停车场:

  • 车牌号 - 时间 - 状态(出 or 入)
  • 对车牌号建立前缀索引,加快获取速度
  • 空闲 or 定期更新数据库数据,删除无用数据

多停车场:

  • 停车场 ID - 车牌号 - 时间 - 状态(出 or 入)
  • (停车场 ID, 车牌号)联合索引

更多需求:

  1. 临时停车 or 永久停车
    1. 永久停车
      1. 付费问题、停车点固定
      2. 若停车点被占据,提供永久车位缓冲区 or 临时区域,暂时停放。并
    2. 临时停车
      1. 提示是否有空位置
  2. 个人信息
    1. 基本信息:姓名、年龄、手机号、账户余额、会员状态
  3. 支付/充值信息
    1. 微信/支付宝 API 进行余额充值,提供自动扣除费用
  4. 优惠手段
    2. 策略模式 - 不同的优惠策略

如何设计一个银行账户系统

断点续传

开放性问题

如何降低自动驾驶系统的延迟

  1. 架构侧
    1. 系统信息流架构优化,谁产生数据,就近处理编码数据,降低大数据量的跨域传输
  2. 硬件层面
    2. 通过硬件设施加快算法处理,如 GPU。
  3. 系统层面
    1. 避免大粒度的锁、降低线程之间的竞争、共享内存方式降低内存拷贝
  4. 算法层面
    2. 合理的设计模式、内存的申请和释放、高效的算法(剪枝、启发式搜素)

架构

架构经验
https://github.com/aalansehaiyang/technology-talk/blob/master/system-architecture/architecture-experience.md

架构经典案例
https://github.com/aalansehaiyang/technology-talk/blob/master/system-architecture/architecture-good-case.md

场景题/系统设计

用户,收藏夹,收藏夹内有视频。设计数据库和缓存 key
如果收藏夹内视频可以任意拖动排序,设计数据库和缓存 key
如何判断用户有没有收藏一个视频
如果视频信息出现更新,数据库怎么办?

Design Dropbox - A System Design Interview Question - GeeksforGeeks
Dropbox / Google Drive System Architecture | by JIN | InterviewNoodle | Medium

系统设计面试题精选
https://soulmachine.gitbooks.io/system-design/content/cn/

系统可用性

哪些情况会导致系统不可用?

  1. 黑客攻击;
  2. 硬件故障,比如服务器坏掉。
  3. 并发量/用户请求量激增导致整个服务宕掉或者部分服务不可用。
  4. 代码中的坏味道导致内存泄漏或者其他问题导致程序挂掉。
  5. 网站架构某个重要的角色比如 Nginx 或者数据库突然不可用。
  6. 自然灾害或者人为破坏。

提高系统可用性的方法

  1. code review
  2. 使用集群,减少单点故障
  3. 限流,避免瞬时流量过大
  4. 超时和重试机制设置
  5. 熔断机制
  6. 异步调用
  7. 使用缓存 - 避免数据库不可用
  8. 灰度发布
  9. 注意备份,必要时回滚

常用限流算法

固定窗口计数器算法

  • 方法
    • 变量 counter 记录请求数目,当 counter 达到阈值,则拒绝剩余请求,每隔一分钟清零。
  • 缺点
    • 无法保证限流速率,无法应对徒增流量。例如,接口 1 分钟只能访问 1000 次,前 55 秒没有访问请求,紧接着 1 秒,突然收到了 1000 次请求。那么 1s 内是没办法被处理完的,从而被击垮。

滑动窗口计数器算法

  • 方法
    • 把时间以一定比例分片。例如我们的接口限流每分钟处理 60 个请求,我们可以把 1 分钟分为 60 个窗口。每隔 1 秒移动一次,每个窗口一秒只能处理不大于 60(请求数)/60(窗口数) 的请求,如果当前窗口的请求计数总和超过了限制的数量的话就不再处理其他请求。
  • 缺点
    • 和固定窗口计数器相同,但会更平滑。

漏桶算法/消息队列

  • 方法
    • 把发请求的动作比作成注水到桶中,我们处理请求的过程可以比喻为漏桶漏水。我们往桶中以任意速率流入水,以一定速率流出水。当水超过桶流量则丢弃,因为桶容量是不变的,保证了整体的速率。
    • 如果想要实现这个算法的话也很简单,准备一个队列用来保存请求,然后我们定期从队列中拿请求来执行就好了(和消息队列削峰/限流的思想是一样的)。

令牌桶算法

  • 方法
    • 向桶里以固定的速率放令牌,到来的请求去桶里取令牌,取到令牌的请求能够进行处理。如果桶满了,多余的令牌被直接丢弃。
  • 设计一个排行榜,百万数量级,支持按照 score 插入,按照 uid 查找排名,按照名次查找 uid
  • redis 的 zset,保证分布式一致(所有服务器访问同一个排行榜
  • zrange,zrank,zscore 等命令原生支持