场景设计题全面攻略,教你如何一鸣惊人!

系统设计题
回答思路:
1、先提出需求分析和非需求分析
2、提出数据库表设计和存储方案,一般选择关系数据库+nosql
3、针对数据量大的场景选取合适的分库分表思路,根据某个id哈希或者一致性哈希
4、针对高并发场景的缓存优化,缓存和数据库一致性或者增加消息队列mq进行解耦
5、详细接口设计,接口访问时的读写数据库和缓存的顺序
6、性能优化——异步操作、批量处理、热点数据优化

设计一个类似抖音的点赞系统
1、需求分析和非需求分析
需求分析:点赞/取消点赞视频+查看视频点赞数量+查看用户点赞的所有视频+点赞状态查询
非需求分析:高性能,高可用,大数据量,数据一致性
根据实际情境扩充
2、库表设计
点赞关系(Like Relationship):存储用户对视频的点赞关系。
user_id  video_id create_time
视频点赞统计(Like Count):存储每个视频的点赞总数。
video_id count update_time
3、分库分表思路
分片策略:
按照用户 ID 或视频 ID 进行分片。
使用一致性哈希或取模的方式进行分库分表。
考虑到点赞数量大,对于点赞关系表,可按 user_id 模 N 取余,将数据分散到 N 个库或表中。
4、缓存操作
点赞/取消点赞操作
先更新数据库:执行点赞或取消点赞的数据库操作。
更新缓存:更新 Redis 中的点赞状态和点赞计数。
避免缓存不一致
消息队列异步更新:将更新操作发送到消息队列,异步更新缓存,确保最终一致性。
5、接口详细处理
以点赞和取消点赞为例
处理流程:
参数校验:检查用户和视频是否存在,验证参数合法性。
数据库操作:
点赞:插入一条点赞关系记录,更新视频点赞统计表的计数。
取消点赞:删除点赞关系记录,更新视频点赞统计表的计数。
更新缓存:更新 Redis 中的点赞状态和点赞计数缓存。
6、优化思路
1.异步处理
异步写入:将点赞/取消点赞操作通过消息队列(如 Kafka、RabbitMQ)异步写入数据库和更新缓存,减少请求的响应时间。
异步更新缓存:在数据库操作完成后,将缓存更新操作放入消息队列异步处理,避免缓存与数据库不一致。
2.批量操作
批量查询:当需要获取多个视频的点赞数量时,提供批量接口,减少网络请求次数。
批量写入:对于一些批量的点赞操作,可以批量写入数据库,减少数据库压力。
3.热点数据优化
热点缓存:对于热门视频,可能会频繁访问其点赞计数,可以在缓存中设置热点数据,确保其始终在内存中。
数据分片:将热点视频的数据分散到不同的缓存和数据库节点上,避免单节点压力过大。
在面试中,场景设计题往往是重头戏!这些问题不仅深度考察你的技术功底,更全面衡量你的工程综合能力。精彩的回答,将成为你脱颖而出的关键加分项。

本文将首先概述通用的答题思路,然后以点赞系统为例,深入解析如何细致全面地回答这类问题。

后续我将持续收集更多的设计题,不断更新和完善本文的内容,帮助你在面试中斩获佳绩。#牛客AI配图神器##牛客激励计划#
全部评论

相关推荐

搜索部 首先说下timeline8.18,投递8.19,约一面8.21,晚上一面call约二面8.22,上午二面下午oc周末等待(8.23,8.24)8.25,offer一年前,我还是懵懵懂懂,高考完的暑假,只会提前学学高数,未来的画像是什么?我或许无法预测。开学后,自学Python,接单,无数个客户的ddl,偷偷摸摸一个人找自习的地方,这一步步竟然为后来的我,搭建工程能力的基础。大一上,我也要感谢我的第一位老板,让我接触到了实习,师兄带着我一步步入门,看他们写的飞书文档。大一下,导师带我参与企业项目,这让我渐渐发现,应该去实践,增长见识,而非局限当下,盯着自己的小新pro。不久后,第一波投递开始,结果当然是约面极少。盯着简历上的文字和ssob,我开始思考,确实很多可以去提升。带着些许不甘心,继续沉淀,慢慢的约面也越来越多,有的时候两天7场,准备完就接着下一个日程。这一次,也许是刚好到位吧,比较match,面试答的流利,关关难关关过,成为度孝子展望未来,依然是重重挑战,果然只有收到offer的那一刻是开心的。愿在百度星海拆解的每一段代码,都能成为丈量宇宙的诗行;此志终赴星河,而今迈步重铸天阶。屏幕前的你们,在无数个向星海奔赴的日夜,一定一定,会在未来化作群星回响的征程——请永远相信此刻埋首耕耘的自己!!!
一天三顿半:???百度提前批发 offer了?不是统一和正式批排序完再发吗我靠
百度求职进展汇总
点赞 评论 收藏
分享
评论
4
42
分享

创作者周榜

更多
牛客网
牛客网在线编程
牛客网题解
牛客企业服务