度小满--笔试系统设计题

两道系统设计题:

1. API rate Limiting

系统有模块A、B、C、D各模块的处理能力不同,A模块只能支撑100QPS,B能支撑200QPS,C能支撑300QPS,D能支撑400QPS。

设计一个通用限流模块支持A、B、C、D的并发能力。

2. 短链服务

微博或者短信都有单条发送字数的限制,如果需要分享一个长网址,很容易越出限制,短链服务可以将长网址变成短网址,方便传播。

请设计一个短链服务,要求短网址尽可能短,且保证系统安全和并发能力。

这种系统设计题第一次很认真的写了,之前遇到类似的系统设计题是在CVTE,那个时候没什么思路,但今天我感觉写的也不一定好,我从接口的参数、返回值、逻辑,以及使用的技术栈进行考虑。

第一题我的思路:

  1. 参考Java中线程池的思想,我在接口参数中,允许开发者传入最大QPS,公平策略,拒绝策略,队列

  2. 使用Redis、MySQL、Quartz以及Zookeeper作为技术栈

  3. 具体的使用逻辑:因为计算QPS需要根据访问量以及时间快速计算,所以使用Redis

  4. 模块的QPS以及一些日志需要使用MySQL持久化到硬盘中,方便复盘

  5. Quartz跟Zookeeper用来做分布式定时任务的,定时将Redis的数据存入到MySQL中

  6. 当QPS达到最大允许QPS时,启动公平策略、拒绝策略即限流

第二题,

没有思路。。。。随便写了写

#笔试题目##度小满#
全部评论
第一题主要是访问量在某个时间节点突然增大,避免服务的瘫痪,时时查询QPS并计算是否达到上限确实是可行的,但是有一个问题,定时任务怎么防止突然某个时间的增大,如果查询时间间隔太短,那么频繁的查询计算QPS计算是否会占用较大内存,浪费性能,而间隔时间太长,又没办法避免突然的访问量增大。 我查了些资料,有些想法,就是对不同模块的访问使用令牌桶,令牌桶本身就把访问量控制住,不去查询QPS,而是令牌桶的令牌分发完了启用拒绝策略,每次都去令牌桶里拿令牌访问请求才能通过,而令牌桶按照一定速率往里面添加令牌,因为桶里的令牌数量是限制固定的,所以突然时刻的访问量增大,不用去查询QPS,而是因为拿不到令牌而被拒绝。
点赞 回复
分享
发布于 2021-04-11 22:53
有收到面试吗
点赞 回复
分享
发布于 2021-04-13 15:46
联易融
校招火热招聘中
官网直投

相关推荐

4 11 评论
分享
牛客网
牛客企业服务