杭州有赞一面面经

最新推荐文章于 2021-08-30 20:36:42 发布

waitself

最新推荐文章于 2021-08-30 20:36:42 发布

阅读量302

点赞数

分类专栏：随笔文章标签： python 面试

本文链接：https://blog.csdn.net/weixin_42137701/article/details/108550019

版权

随笔专栏收录该内容

5 篇文章 0 订阅

订阅专栏

1、实习项目经历（大数据的数据库的查询优化策略）

切片查询，缓存。。。

2、http状态码

https://www.runoob.com/http/http-status-codes.html

3、tcp的三次握手和四次挥手

三次握手：
第一次握手：建立连接时，客户端发送syn包（syn=x）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号（Synchronize Sequence Numbers）。

第二次握手：服务器收到syn包，必须确认客户的SYN（ack=x+1），同时自己也发送一个SYN包（syn=y），即SYN+ACK包，此时服务器进入SYN_RECV状态；

第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=y+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。

四次挥手：
1）客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
2）服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
3）客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
4）服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
5）客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
6）服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

3、为什么是三次握手，两次可以吗？

3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。
现在把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，S收到了这个分组，并发送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S 是否已准备好，不知道S建立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。

4、四次挥手时存在一个时间等待（TIME-WAIT）的状态，如果出现了多个这种状态，什么原因？

在高并发短连接的TCP服务器上，当服务器处理完请求后立刻主动正常关闭连接。这个场景下会出现大量socket处于TIME_WAIT状态。如果客户端的并发量持续很高，此时部分客户端就会显示连接不上。
我来解释下这个场景。主动正常关闭TCP连接，都会出现TIMEWAIT。
这篇文章讲的很详细： https://www.cnblogs.com/dadonggg/p/8778318.html

5、GIL锁产生的原因和处理

Python语言和GIL没有半毛钱关系，仅仅是由于历史原因在Cpython虚拟机（解释器），难以移除GIL。
GIL：全局解释锁，每个线程在执行的过程都需要先获取GIL，保证同一时刻只有一个线程可以执行代码。
线程释放GIL锁的情况，在IO操作等可能会引起阻塞的system call之前，可以暂时释放GIL，Python3.X使用计时器（执行时间到达阈值之后，当前线程释放GIL锁）或Python2.X，tickets技术达到100
Python使用多进程是可以利用多核CPU资源的
多线程爬取比单线程性能有提升，因为遇到IO阻塞会自动释放GIL锁
3、补充：
针对不同的环境，有相应比较合适的多任务处理方法

计算密集型：进程
io密集型：线程、协程
4、解决：
想要执行真正的多任务，可以采用进程相关操作。
由于GIL锁的产生是因为python解释器的问题，可以将每一个线程的功能实现，通过其他语言来完成功能，最后采用python解释器进行统一执行，这样也可以避开GIL锁。

6、多任务的实现（协程、进程）

7、生成器器、迭代器的理解和区别

迭代器是一个可以记住遍历位置的对象，迭代器对象从集合的第一个元素开始访问，直到所有的元素被访问完结束。迭代器只能往前不能后退。

利用迭代器，我们可以在每次迭代获取数据（通过next()方法）时按照特定的规律进行生成。但我们在实现一个迭代器时，关于当前迭代到的状态需要我们自己记录，进而才能根据当前状态生成下一个数据。为了达到记录当前状态，并配合next()函数进行迭代使用，我们可以采用更简便的语法，即生成器。
（generator）生成器是一类特殊的迭代器。

8、装饰器的理解以及举例

装饰器(decorator)功能

引入日志
函数执行时间统计
执行函数前预备处理
执行函数后清理功能
权限校验等场景
缓存
https://www.runoob.com/w3cnote/python-func-decorators.html

9、list可以作为dict的key吗？（不能，不存在hash方法）

10、python的内存管理机制（垃圾回收）

垃圾回收

当Python中的对象越来越多，占据越来越大的内存，启动垃圾回收(garbage collection)，将没用的对象清除。

1、原理

当Python的某个对象的引用计数降为0时，说明没有任何引用指向该对象，该对象就成为要被回收的垃圾。比如某个新建对象，被分配给某个引用，对象的引用计数变为1。如果引用被删除，对象的引用计数为0，那么该对象就可以被垃圾回收。

In [74]: a=[321,123]

In [75]: del a

2、解析del

del a后，已经没有任何引用指向之前建立的[321,123]，该表引用计数变为0，用户不可能通过任何方式接触或者动用这个对象，当垃圾回收启动时，Python扫描到这个引用计数为0的对象，就将它所占据的内存清空。

3、注意

1、垃圾回收时，Python不能进行其它的任务，频繁的垃圾回收将大大降低Python的工作效率；

2、Python只会在特定条件下，自动启动垃圾回收（垃圾对象少就没必要回收）

3、当Python运行时，会记录其中分配对象(object allocation)和取消分配对象(object deallocation)的次数。当两者的差值高于某个阈值时，垃圾回收才会启动。

In [93]: import gc

In [94]: gc.get_threshold()　　#gc模块中查看阈值的方法
Out[94]: (700, 10, 10)

阈值分析：

700即是垃圾回收启动的阈值；

每10次0代垃圾回收，会配合1次1代的垃圾回收；而每10次1代的垃圾回收，才会有1次的2代垃圾回收；

当然也是可以手动启动垃圾回收：

In [95]: gc.collect()    #手动启动垃圾回收
Out[95]: 2

4、何为分代回收

Python将所有的对象分为0，1，2三代；

所有的新建对象都是0代对象；

当某一代对象经历过垃圾回收，依然存活，就被归入下一代对象。

四、内存池机制

Python中有分为大内存和小内存：（256K为界限分大小内存）

1、大内存使用malloc进行分配

2、小内存使用内存池进行分配

3、Python的内存池(金字塔)

第3层：最上层，用户对Python对象的直接操作

第1层和第2层：内存池，有Python的接口函数PyMem_Malloc实现-----若请求分配的内存在1~256字节之间就使用内存池管理系统进行分配，调用malloc函数分配内存，但是每次只会分配一块大小为256K的大块内存，不会调用free函数释放内存，将该内存块留在内存池中以便下次使用。

第0层：大内存-----若请求分配的内存大于256K，malloc函数分配内存，free函数释放内存。

第-1，-2层：操作系统进行操作
在这里插入图片描述

https://www.cnblogs.com/geaozhang/p/7111961.html

11、跨域的原因以及解决办法

浏览器的同源策略限制默认情况下前端页面和后端服务在不同服务器（域名、端口不一样）时，前端页面js无法请求到后端接口服务，即存在跨域问题。

使用jsonp方式解决
使用cors解决
使用nginx代理解决

12、mysql的存储引擎有InnoDB、MyISAM的区别以及使用场景

区别：

（1）事务处理：

MyISAM是非事务安全型的，而InnoDB是事务安全型的（支持事务处理等高级处理）；

（2）锁机制不同：

MyISAM是表级锁，而InnoDB是行级锁；

（3）select ,update ,insert ,delete 操作：

MyISAM：如果执行大量的SELECT，MyISAM是更好的选择

InnoDB：如果你的数据执行大量的INSERT或UPDATE，出于性能方面的考虑，应该使用InnoDB表

（4）查询表的行数不同：

MyISAM：select count() from table,MyISAM只要简单的读出保存好的行数，注意的是，当count()语句包含 where条件时，两种表的操作是一样的

InnoDB ： InnoDB 中不保存表的具体行数，也就是说，执行select count(*) from table时，InnoDB要扫描一遍整个表来计算有多少行

（5）外键支持：

mysiam表不支持外键，而InnoDB支持

为什么MyISAM会比Innodb 的查询速度快。

INNODB在做SELECT的时候，要维护的东西比MYISAM引擎多很多；
1）数据块，INNODB要缓存，MYISAM只缓存索引块，这中间还有换进换出的减少；
2）innodb寻址要映射到块，再到行，MYISAM 记录的直接是文件的OFFSET，定位比INNODB要快
3）INNODB还需要维护MVCC一致；虽然你的场景没有，但他还是需要去检查和维护

MVCC ( Multi-Version Concurrency Control )多版本并发控制

应用场景

MyISAM适合：(1)做很多count 的计算；(2)插入不频繁，查询非常频繁；(3)没有事务。

InnoDB适合：(1)可靠性要求比较高，或者要求事务；(2)表更新和查询都相当的频繁，并且行锁定的机会比较大的情况。

13、数据库的外键的作用（保证数据的完整性和一致性。）

waitself

关注

0
点赞
踩
2

收藏

觉得还不错? 一键收藏
0
评论
杭州有赞一面面经

1、实习项目经历（大数据的数据库的查询优化策略）切片查询，缓存。。。2、http状态码https://www.runoob.com/http/http-status-codes.html3、tcp的三次握手和四次挥手三次握手：第一次握手：建立连接时，客户端发送syn包（syn=x）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号（Synchronize Sequence Numbers）。第二次握手：服务器收到syn包，必须确认客户的SYN（ack=x+1），同时自己
复制链接

扫一扫