查看原文
其他

2019年9月拼多多面试题分享(秋招级别)

我是程序汪 我是程序汪 2021-09-08


下面是程序汪的一个B站粉丝 分享给我的最近真实面试经历

当然不是免费的(天下没有免费午餐),

程序汪也帮了他一个忙

大家共赢吧

如果你们有共赢的事情都可以找程序汪

你有比较奇葩的IT经历欢迎和程序汪沟通


阿里招聘感兴趣戳他 年薪是30万到40万

【程序汪】阿里巴巴P6级别月薪30K~40K招聘信息,地点杭州




百度京东的面试题点击进入 秋招级别



2019年9月百度面试题分享(第一部分)


2019年9月京东面试题分享(实习生秋招级别)


                               拼多多的(内容太多分2次发布) 秋招级别



1、好友数目太多怎么办? 

2、1000亿的大数据,找出其中最大的十万个数 

3、1000亿的大数据,全排序 

4、软中断和硬中断区别,种类,缺页中断是什么中断?

5、数据库查询太慢怎么优化?

7、Java内存模型 

8、TCP拥塞控制与拥塞避免、、、、滑动窗口 

9、网页服务单进程多线程好还是多进程单线程好?资源,稳定性,响应速度 

10、直播业务用什么?改进UDP。



建议大家向这几个方向发力

拼多多偏基础

1 redis数据类型

2 并发编程

3 JVM

4 写一道代码题(能写出来基本没问题了)





1、好友数目太多怎么办?

设计了一个通用的关注接口,有entity type 和entityID,既可以关注问题,也可以关注用 户。功能有我关注了谁,取关了谁,判断是否是好友。异步存储到数据库。存储数据库分为用户表和问题表 用户表就是用户+Entity ID。问题表就是用户关注了问题的ID。问题就是存储问题的ID+喜欢的用户喜欢表和不喜欢表 Redis里面根据set存储用户的ID,判断某个用户是否喜欢,喜欢的数量, Redis里面根据唯一键Like+entity type+Entity ID 值是userid 数据库存的话可以分为喜欢表和不喜欢表 键是实体ID,值是用户ID 分库分表,用一个数据表存储映射关系,当好友太多的话需要分库分表, 1-1000的好友存储到A表,1000到2000的好友存储到B表。分库分表?垂直拆分,还有水平拆分?1 基本思想之什么是分库分表?从字面上简单理解,就是把原本存储于一个库的数据分块存储到多个库上,把原本存储 于一个表的数据分块存储到多个表上。2 基本思想之为什么要分库分表?数据库中的数据量不一定是可控的,在未进行分库分表的情况下,随着时间和业务的发 展,库中的表会越来越多,表中的数据量也会越来越大,相应地,数据操作,增删改查 的开销也会越来越大;另外,由于无法进行分布式式部署,而一台服务器的资源 (CPU、磁盘、内存、IO等)是有限的,最终数据库所能承载的数据量、数据处理能 力都将遭遇瓶颈。3 分库分表的实施策略。分库分表有垂直切分和水平切分两种。3.1 何谓垂直切分,即将表按照功能模块、关系密切程度划分出来,部署到不同的库 上。例如,我们会建立定义数据库workDB、商品数据库payDB、用户数据库 userDB、日志数据库logDB等,分别用于存储项目数据定义表、商品定义表、用户数 据表、日志数据表等。3.2 何谓水平切分,当一个表中的数据量过大时,我们可以把该表的数据按照某种规 则,例如userID散列,进行划分,然后存储到多个结构相同的表,和不同的库上。例 如,我们的userDB中的用户数据表中,每一个表的数据量都很大,就可以把userDB切 分为结构相同的多个userDB:part0DB、part1DB等,再将userDB上的用户数据表 userTable,切分为很多userTable:userTable0、userTable1等,然后将这些表按照 一定的规则存储到多个userDB上。3.3 应该使用哪一种方式来实施数据库分库分表,这要看数据库中数据量的瓶颈所在, 并综合项目的业务类型进行考虑。如果数据库是因为表太多而造成海量数据,并且项目的各项业务逻辑划分清晰、低耦 合,那么规则简单明了、容易实施的垂直切分必是首选。而如果数据库中的表并不多,但单表的数据量很大、或数据热度很高,这种情况之下就 应该选择水平切分,水平切分比垂直切分要复杂一些,它将原本逻辑上属于一体的数据 进行了物理分割,除了在分割时要对分割的粒度做好评估,考虑数据平均和负载平均, 后期也将对项目人员及应用程序产生额外的数据管理负担。在现实项目中,往往是这两种情况兼而有之,这就需要做出权衡,甚至既需要垂直切 分,又需要水平切分。我们的游戏项目便综合使用了垂直与水平切分,我们首先对数据 库进行垂直切分,然后,再针对一部分表,通常是用户数据表,进行水平切分。4 分库分表存在的问题。4.1 事务问题。在执行分库分表之后,由于数据存储到了不同的库上,数据库事务管理出现了困难。如 果依赖数据库本身的分布式事务管理功能去执行事务,将付出高昂的性能代价;如果由 应用程序去协助控制,形成程序逻辑上的事务,又会造成编程方面的负担。4.2 跨库跨表的join问题。在执行了分库分表之后,难以避免会将原本逻辑关联性很强的数据划分到不同的表、不 同的库上,这时,表的关联操作将受到限制,我们无法join位于不同分库的表,也无法 join分表粒度不同的表,结果原本一次查询能够完成的业务,可能需要多次查询才能完 成。4.3 额外的数据管理负担和数据运算压力。


2、1000亿的大数据,找出其中最大的十万个数 

Hash分成小文件,每个小文件进行Hash统计,取出前十万大的数字。然后维护一个十万大 小的堆,多个文件得出最大的十万个数。


3、1000亿的大数据,全排序 

Hash分成小文件,每个小文件内部进行快排,得到多个有序小文件,然后多路归并排序。


4、软中断和硬中断区别,种类,缺页中断是什么中断?

硬中断:

1. 硬中断是由硬件产生的,比如,像磁盘,网卡,键盘,时钟等。每个设备或设备集都有 它自己的IRQ(中断请求)。基于IRQ,CPU可以将相应的请求分发到对应的硬件驱动上 (注:硬件驱动通常是内核中的一个子程序,而不是一个独立的进程)。

2. 处理中断的驱动是需要运行在CPU上的,因此,当中断产生的时候,CPU会中断当前正 在运行的任务,来处理中断。在有多核心的系统上,一个中断通常只能中断一颗CPU(也有一种特殊的情况,就是在大型主机上是有硬件通道 的,它可以在没有主CPU的支持下, 可以同时处理多个中断。)。

3. 硬中断可以直接中断CPU。它会引起内核中相关的代码被触发。对于那些需要花费一些 时间去处理的进程,中断代码本身也可以被其他的硬中断中断。

4. 对于时钟中断,内核调度代码会将当前正在运行的进程挂起,从而让其他的进程来运 行。它的存在是为了让调度代码(或称为调度器)可以调度多任务。软中断:

1. 软中断的处理非常像硬中断。然而,它们仅仅是由当前正在运行的进程所产生的。

2. 通常,软中断是一些对I/O的请求。这些请求会调用内核中可以调度I/O发生的程序。对 于某些设备,I/O请求需要被立即处理,而磁盘I/O请求通常可以排队并且可以稍后处理。根据I/O模型的不同,进程或许会被挂起直到I/O完成,此时内核调度器就会选择另一个进 程去运行。I/O可以在进程之间产生并且调度过程通常和磁盘I/O的方式是相同。

3. 软中断仅与内核相联系。而内核主要负责对需要运行的任何其他的进程进行调度。一些 内核允许设备驱动的一些部分存在于用户空间,并且当需要的时候内核也会调度这个进程去 运行。

4. 软中断并不会直接中断CPU。也只有当前正在运行的代码(或进程)才会产生软中断。这种中断是一种需要内核为正在运行的进程去做一些事情(通常为I/O)的请求。有一个特 殊的软中断是Yield调用,它的作用是请求内核调度器去查看是否有一些其他的进程可以运 行。

问题解答:

1. 问:对于软中断,I/O操作是否是由内核中的I/O设备驱动程序完成?答:对于I/O请求,内核会将这项工作分派给合适的内核驱动程序,这个程序会对I/O进 行队列化,以可以稍后处理(通常是磁盘I/O),或如果可能可以立即执行它。通常,当对 硬中断进行回应的时候,这个队列会被驱动所处理。当一个I/O请求完成的时候,下一个在 队列中的I/O请求就会发送到这个设备上。

2. 问:软中断所经过的操作流程是比硬中断的少吗?换句话说,对于软中断就是:进程 -> 内核中的设备驱动程序;对于硬中断:硬件->CPU->内核中的设备驱动程序?

答:是的,软中断比硬中断少了一个硬件发送信号的步骤。产生软中断的进程一定是当前正 在运行的进程,因此它们不会中断CPU。但是它们会中断调用代码的流程。如果硬件需要CPU去做一些事情,那么这个硬件会使CPU中断当前正在运行的代码。而后 CPU会将当前正在运行进程的当前状态放到堆栈(stack)中,

以至于之后可以返回继续运 行。这种中断可以停止一个正在运行的进程;可以停止正处理另一个中断的内核代码;或者 可以停止空闲进程。硬中断分为 外中断(中断)和内中断(异常) 软中断分为 信号和软件中断 时钟中断属于硬中断中的外中断 是处理器外的脉冲引起的 而时间片中断是由处理器内部产 生 时间片可以是多个时钟周期 缺页中断属于硬中断的内中断(异常


5、数据库查询太慢怎么优化?

1、对查询进行优化,应尽可能避免全表扫描 

1.2 建立索引查询 

1、缓存,在持久层或持久层之上做缓存 使用ehcache缓存,这个一般用于持久层的缓存,提供持久层、业务层的快速缓存, hibenate默认使用的二级缓存就是ehcache; 

2、数据库表的大字段剥离 假如一个表的字段数有100多个,学会拆分字段,保证单条记录的数据量很小; 

3、恰当地使用索引 必要时建立多级索引,分析MySQL的执行计划,通过表数据统计等方式协助数据库走正 确的查询方式,该走索引就走索引,该走全表扫描就走全表扫描;

4、表的拆分 表分区和拆分,无论是业务逻辑上的拆分(如一个月一张报表、分库)还是无业务含义 的分区(如根据ID取模分区); 

5、字段冗余 减少跨库查询和大表连接操作;,数据通过单个或多个JOB生成出来,减少实时查询; 

6、从磁盘上做文章 数据存放的在磁盘的内、外磁道上,数据获取的效率都是不一样的; 

7、放弃关系数据库的某些特性 引入NoSQL数据库; 换种思路存放数据,例如搜索中的倒排表; 

6、8G内存机器虚拟机怎么调整线程数最大?可以看出增大堆内存(-Xms,-Xmx)会减少可创建的线程数量,增大线程栈内存(- Xss,32位系统中此参数值最小为60K)也会减少可创建的线程数量。JVM中可以生成的最大数量由JVM的堆内存大小、Thread的Stack内存大小、系统最大 可创建的线程数量(Java线程的实现是基于底层系统的线程机制来实现的,Windows 下_beginthreadex,Linux下pthread_create)三个方面影响。具体数量可以根据 Java进程可以访问的最大内存(32位系统上一般2G)、堆内存、Thread的Stack内存 来估算。


7、Java内存模型 8、TCP拥塞控制与拥塞避免、、、、滑动窗口

拥塞控制包括——慢开始,拥塞避免,快重传,快恢复 拥塞控制包括慢开启与拥塞避免 

1、慢开始 发送方维持一个叫做拥塞窗口cwnd的状态变量。拥塞窗口的大小取决于网络的拥塞程度, 并且动态地在变化。发送方让自己的发送窗口等于拥塞窗口。如果还考虑接收方的接受能 力,那么发送窗口还可能小于拥塞窗口。发送方控制拥塞窗口的原则是:只要网络没有出现拥塞,拥塞窗口就在增大一些,以便把更 多的分组发送出去。但只要网络出现拥塞,拥塞窗口就减少一些,以减少注入到网络中的分 组数。慢开始算法的思路:当主机开始发送数据时,如果立即把大量数据字节注入到网络中,那么 久有可能引起网络拥塞,因为现在并不清楚网络的负荷情况。经验证明,较好的方法是先探 测一下,即由小到大逐渐增大发送窗口,也就是说,由小到大逐渐增大拥塞窗口数值。通常 在刚刚开始发送报文段时,先把拥塞窗口cwnd设置为一个最大报文段MSS数值。而在每收 到一个对新的报文段的确认后,把拥塞窗口增加之多一个MSS的数值,用这样的方法逐步 增大发送方的拥塞窗口cwnd,可以使分组注入到网络的速率更加合理。使用慢开始算法后,每经过一个传输轮次,拥塞窗口cwnd就加倍 传输轮次:一个传输轮次所经历的时间其实就是往返时间RTT。把拥塞窗口cwnd所允许发 送的报文段都连续发送出去,并收到了对已发送的最后一个字节的确认。

2、慢开始门限ssthresh 为了防止拥塞窗口cwnd增长过大引起网络拥塞,还需要设置一个慢开始门限ssthresh状态 变量. 当cwnd < ssthresh 时,使用慢开始算法。当cwnd > ssthresh 时,停止使用慢开始算法而改用拥塞避免算法。当cwnd = ssthresh 时,即可使用慢开始算法,也可使用拥塞避免算法。

3、拥塞避免 拥塞避免算法的思路:让拥塞窗口cwnd缓慢地增大,即每经过一个往返时间RTT就把发送 方的拥塞窗口cwnd加1,而不是加倍。这样,拥塞窗口cwnd按线性规律缓慢增长,比慢开 始算法的拥塞窗口增长速率缓慢的多。无论在慢开始阶段还是拥塞避免阶段,只要发送方判断网络出现拥塞(没有按时收到确 认),就要把慢开始门限ssthresh设置为出现拥塞时发送方窗口值的一半(但不能小于 2)。然后把拥塞窗口cwnd重新设置为1,执行慢开始算法。这样做的目的就是要迅速减少 主机发送到网络中的分组数,使得发送拥塞的路由器有足够的时间把队列中积压的分组处理 完。

4、“乘法减小”和“加法增大” “乘法减小”是指不论在慢开始阶段还是拥塞避免阶段,只要出现超时(即可能出现了网络 拥塞),就把慢开始门限ssthresh的值减半,即设置为当前的拥塞窗口的一半(开始执行慢 开始算法) “加法增大”是指执行拥塞避免算法后,使拥塞窗口缓慢增大,以防止网络过早出现拥塞。上面两种方法合起来常称为AIMD算法(加法增大乘法减少)。注意:“拥塞避免”并非指完全能避免了拥塞。利用以上的措施要完全避免拥塞还是不可能 的,“拥塞避免”是说在拥塞避免阶段将拥塞窗口控制为按线性规律增长,使网络不容易出 现拥塞。1、快重传 快重传算法首先要求接收方每收到一个失序的报文段就立即发出重复确认(为的是使发送方 及早的知道有报文段没有到达对方)而不要等到自己发送数据时才捎带确认。快重传算法规定,发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文 段,而不必继续等待为其设置的重传计时器到期。2、快恢复 (1)当发送方连续收到三个重复确认时,就执行“乘法减小”算法,把慢开始门限减半。这是为了预防网络发生拥塞,但不执行慢开始算法。

(2)由于发送方现在认为网络很可能没有发生拥塞(如果网络发生了严重拥塞,就不会一 连有好几个报文段连续到达接收方,也就不会导致接收方连续发送重复确认)。因此与慢开 始不同之处就是现在不执行慢开始算法(即拥塞窗口现在不设置为1)而是把拥塞窗口的值 设置为慢开始门限减半后的值,然后开始执行拥塞避免算法(“加法增大”),使拥塞窗口 缓慢地线性增大。注意:有的快重传实现是把开始时的拥塞窗口cwnd值再增大一些(增大3个报文段),即 等于ssthresh + 3*MSS 这样做的理由是:既然发送方收到三个重复的确认,就表明有三个 分组已经离开了网络。这三个分组不再消耗网络资源而是停留在接收方的缓存中。可见现在 网络中并不是堆积了分组而是减少了三个分组。因此可以适当把拥塞窗口扩大些。当采用快恢复算法时,慢开始算法只是在TCP连接建立时和网络超时时才使用。实际上接收方的缓存空间总是有限的,接收方根据自己的接收能力设定了接收窗口rwnd,并 把这个窗口值写入TCP首部中的窗口字段,传送给发送方。因此,从接收方对发送方的流量 控制的角度考虑,发送方的发送窗口一定不能超过对方给出的接收窗口值rwnd.那么,发送 方的窗口的上限值应当取为接收方窗口rwnd和拥塞窗口cwnd这两个变量中较小的一个。发送方窗口的上限值 = Min [rwnd ,cwnd] 当rwnd < cwnd 时,是接收方的接收能力限制发送方窗口的最大值 当rwnd > cwnd 时,则是网络的拥塞限制发送方窗口的最大值 流量控制:


9、网页服务单进程多线程好还是多进程单线程好?资源,稳定性,响应速度 单进程多线程,响应速度块,但是不稳定,一个线程死了全死了 多进程,稳定性好,资源占用多,响应速度不如单进程快。


10、直播业务用什么?改进UDP。改进UDP可以从减少流控,无需确认重传入手。但是上层必须维护三次握手四次挥手的状 态。可以传输过程中压缩传输,在客户端解码 CDN网络 P2P+缓存




大家注意上面都是秋招级别,不同级别面试题的难读也不一样 

后面我会持续更新 百度、京东、阿里等等社招的面试题

社招偏难大家注意了

感谢热心粉丝分享,谢谢你们



程序汪往期面试视频包含答案

面试银行经验月薪要求1万8千java程序员,这次真的通过了


面试造火箭,入职拧螺丝!一个JAVA面试官的心声


帮公司面试1万到1.5万薪资的Java程序员,来看看我问什么


目录:我把精华文章都整理出来了    (目录列的比较全)


公众号是回复 001 或 002 一直到006 都能找到面试视频以及答案

给个[在看],是对程序汪最大的支持




: . Video Mini Program Like ,轻点两下取消赞 Wow ,轻点两下取消在看

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存