腾讯复活赛,腾讯云面经

一小时项目+八股拷打,简历从头问到尾,问到不会为止,最后十五分钟手撕LRU(典中典)
(1)实习拷打(引申了一个ABA问题,不会,当头棒喝)
(2)LRU用在OS的哪些地方
(3)mmap使用的是物理地址吗
(4)mmap会将整个文件映射到内存里吗
(5)Page Fault具体过程
(6)发生Page Fault后要将虚拟地址映射到物理地址,如何判断映射到哪个文件的哪个部分?(答了根据虚拟地址的偏移量对应到文件起始地址的偏移量,被追问如何确定要映射哪个文件,懵)
(7)时钟中断
(8)OS如何选择从内核态返回哪个线程(答了调度器会从“线程表”里根据调度算法,选择下一个线程)
(9)“线程表”具体是什么数据结构(队列、红黑树、链表)
(10)协程
(11)你实现的协程是非抢夺式的,如果有一个协程死循环了怎么办(答时间片耗尽后线程强制切换上下文,被追问当前线程已经被这个协程“占据”了,又该如何实现上下文切换。懵了,面试官说可以用信号)
(12)打开文件的具体过程
(13)项目介绍
(14)TCP粘包
(15)JWT流程,JWT可能被伪造吗
(16)raft协议,读操作可以位于任意节点上吗?(我回答是,面试官表示质疑,引申下面的问题)
(17)强一致性的实现,假设客户端连上一个follower,但此时最新的日志还没从leader上同步过去,客户端又想读取到最新的数据该怎么办(不会,面试官说follower返回数据的同时返回一个“日志长度”)
(18)raft选举
(19)投票规则(答了任期,面试官说还有一点)
(20)Proactor
(21)忘了问的啥,掰扯了一下IO模型
(22)epoll,对比其它两个
(23)普通的IO会阻塞轮询,阻塞的时候可否做其它事情,让别的进程读(没get到面试官意思)
(24)ps命令会显示哪些信息(追问会显示进程状态吗)
(25)HTTP
(26)http优化,keep alive
(27)继续优化,若有一个复杂场景,服务器需要频繁推送,怎么处理(答了2.0多路复用,主动推送,升级成websocket,结果都不是面试官想要的,最后没辙了答了一个本地缓存,面试官和我都发出愉快的笑声)
(28)数据库索引
(29)索引常见数据类型
(30)索引查找
(31)联合索引
(32)redis日志
(33)AOF日志解决了什么问题
全部评论
问到都写不下了 (34)docker是啥,讲讲原理(不懂,我只是一只猫猫怎么会懂这么深奥的原理) (35)手撕LRU (36)反问
1 回复 分享
发布于 03-13 22:45 湖南
腾讯云几面?
点赞 回复 分享
发布于 03-13 23:08 上海
这也太逆天了
点赞 回复 分享
发布于 03-14 11:50 广东
太狠了
点赞 回复 分享
发布于 03-14 12:15 广东
又疯一个
点赞 回复 分享
发布于 03-14 13:09 广东
佬做的操作系统项目吗,xv6?
点赞 回复 分享
发布于 03-14 17:26 江苏
好充实的一次面试
点赞 回复 分享
发布于 03-15 02:27 上海
佬是腾讯云哪个部门?感觉大家问的都差不多😂
点赞 回复 分享
发布于 03-15 19:49 广东
面试好猛
点赞 回复 分享
发布于 03-17 17:38 安徽
16是可以的,可以了解一下etcd的线性读
点赞 回复 分享
发布于 03-20 09:36 辽宁
27可以考虑一下sse
点赞 回复 分享
发布于 03-20 09:37 辽宁
具体是啥业务啊,害怕
点赞 回复 分享
发布于 03-21 13:45 上海
经典raft不支持读写分离的吧
点赞 回复 分享
发布于 03-25 13:16 浙江
这么多问题,到底是在招什么啊?
点赞 回复 分享
发布于 昨天 21:54 安徽

相关推荐

上来先手撕lru , si完 问优化 ● 1. 如何实现一个lockfree 的 并发控制的缓存  ○ 问ringbuffer的优点?  无锁并发 ● 2. lru结合lfu 实现兼顾折中, 结合优点的算法实现● 也可以使用结构体记录, 在数据存储 基本单元上● 面试官给的思路: 设计多个lruclass, 或者多个队列, hot, warm, cold 队列  ○ 访问频率高的就放入hot里边( 比如多少次以上评价为高  ○ 那么可以使用结构体, 记录每一个访问的次数  ○ 那如何解决这个过期呢? 还能设计一个过期时间, 每次要检索这个数据的时候, 获取这个过期时间,看是否过期, 过期就直接丢掉,  不能访问了 ● 另一个思路 :  整体还是按照lru来,替换之前检查一下,前三个即将被替换的里面选择频率最低的删除,但是每个最多连续比较三次(我瞎说的)  ○ 避免某些短时间频繁访问的节点被删除    ■ 防止抖动现象产生 布隆过滤器+ redis bitmap 的原理● 自己的思路, 使用一个散列函数, 根据你当前的访问频率(设计一个struct node ), 去决定你随机的在list里边的插入位置  ○ 如果频率比较高, 就将其在get 的时候放到靠近队头的位置  ○ 频率比较低, 将其get 的时候放在队尾的位置(反正你短期大量访问, 后续频率上来了也会 逐渐的放到队头的  ○ 并且反正插入和查询都是O1     ■ 如果是伪高频,  插入位置比较低, 后续也会直接被淘汰, 说明你根本不是真正的短期热数据● 如果再问频率优化?  ○ CMS, caffeine 的本地淘汰策略算法● lru和lfu 的区别, lfu适合短期高频, 而lfu适合长期高频 数据paxos和raft 的区别● paxos 对比raft 的优点?● raft 为啥容易实现? 和paxos对比? 不允许空洞->强leader->容易实现● 选主的时候有没有 可能设计一个方案, 无锁选主?   ○ 1. 回答哨兵机制, 交给另一个集群哨兵去做选举这件事( 从而让数据节点专心做数据  ○ 2. 问其他思路, 我说不锁不行, 不锁的话可能导致选票许诺给多个人->整个集群的逻辑总票数增加 -> 脑裂问题均摊分析, 插入1e数据 ,扩容因子为4的 hash插入 的复杂度( 不会● 两阶段提交的缺点   ○ 全局阻塞, io次数多( 根据mysql 的两阶段提交谈了谈, 三级队列优化思路  ○ 没有事先通知 参与者, 不知道他可不可达, 宕机没 就直接提交了( 浪费网络带宽  ○ 协调者比重太大,  一旦故障, 其他参与者也会跟着阻塞  ○ 可能导致的数据库不一致, 比如commit阶段 ,参与者并没有收到提交请求, 导致落后 ( 可以引入mq解决消息消费问题    ■ 回答 数据同步机制, 结合项目增量和全量, 以及mysql 的集群组提交策略(半数以上● 解决,引入tcc,  不过侵入性较大, 并且实际效率也不一定高 (
腾讯一面1633人在聊 查看12道真题和解析
点赞 评论 收藏
分享
评论
10
79
分享

创作者周榜

更多
牛客网
牛客企业服务