目錄

Web

Flask

140.對Flask藍(lán)圖(Blueprint)的理解？

141.Flask 和 Django 路由映射的區(qū)別？

Django

142.什么是wsgi,uwsgi,uWSGI?

143.Django、Flask、Tornado的對比？

144.CORS 和 CSRF的區(qū)別？

145.Session,Cookie,JWT的理解

146.簡述Django請求生命周期

147.用的restframework完成api發(fā)送時間時區(qū)

148.nginx,tomcat,apach到都是什么？

149.請給出你熟悉關(guān)系數(shù)據(jù)庫范式有哪些，有什么作用？

150.簡述QQ登陸過程

151.post 和 get的區(qū)別?

152.項目中日志的作用

153.django中間件的使用？

154.談一下你對uWSGI和nginx的理解？

155.Python中三大框架各自的應(yīng)用場景？

156.Django中哪里用到了線程？哪里用到了協(xié)程？哪里用到了進(jìn)程？

157.有用過Django REST framework嗎？

158.對cookies與session的了解？他們能單獨用嗎？

爬蟲

159.試列出至少三種目前流行的大型數(shù)據(jù)庫

160.列舉您使用過的Python網(wǎng)絡(luò)爬蟲所用到的網(wǎng)絡(luò)數(shù)據(jù)包?

161.爬取數(shù)據(jù)后使用哪個數(shù)據(jù)庫存儲數(shù)據(jù)的，為什么？

162.你用過的爬蟲框架或者模塊有哪些？優(yōu)缺點？

163.寫爬蟲是用多進(jìn)程好？還是多線程好？

164.常見的反爬蟲和應(yīng)對方法？

165.解析網(wǎng)頁的解析器使用最多的是哪幾個?

166.需要登錄的網(wǎng)頁，如何解決同時限制ip，cookie,session

167.驗證碼的解決?

168.使用最多的數(shù)據(jù)庫，對他們的理解？

169.編寫過哪些爬蟲中間件？

170.“極驗”滑動驗證碼如何破解？

171.爬蟲多久爬一次，爬下來的數(shù)據(jù)是怎么存儲？

172.cookie過期的處理問題？

173.動態(tài)加載又對及時性要求很高怎么處理？

174.HTTPS有什么優(yōu)點和缺點？

175.HTTPS是如何實現(xiàn)安全傳輸數(shù)據(jù)的？

176.TTL，MSL，RTT各是什么？

177.談一談你對Selenium和PhantomJS了解

178.平常怎么使用代理的 ？

179.存放在數(shù)據(jù)庫(redis、mysql等)。

180.怎么監(jiān)控爬蟲的狀態(tài)?

181.描述下scrapy框架運(yùn)行的機(jī)制？

182.談?wù)勀銓crapy的理解？

183.怎么樣讓 scrapy 框架發(fā)送一個 post 請求（具體寫出來）

184.怎么監(jiān)控爬蟲的狀態(tài) ？

185.怎么判斷網(wǎng)站是否更新？

186.圖片、視頻爬取怎么繞過防盜連接

187.你爬出來的數(shù)據(jù)量大概有多大？大概多長時間爬一次？

188.用什么數(shù)據(jù)庫存爬下來的數(shù)據(jù)？部署是你做的嗎？怎么部署？

189.增量爬取

190.爬取下來的數(shù)據(jù)如何去重，說一下scrapy的具體的算法依據(jù)。

191.Scrapy的優(yōu)缺點?

192.怎么設(shè)置爬取深度？

193.scrapy和scrapy-redis有什么區(qū)別？為什么選擇redis數(shù)據(jù)庫？

194.分布式爬蟲主要解決什么問題？

195.什么是分布式存儲？

196.你所知道的分布式爬蟲方案有哪些？

197.scrapy-redis，有做過其他的分布式爬蟲嗎？

---

Web

Flask

140.對Flask藍(lán)圖(Blueprint)的理解？

藍(lán)圖的定義

藍(lán)圖 /Blueprint 是Flask應(yīng)用程序組件化的方法，可以在一個應(yīng)用內(nèi)或跨越多個項目共用藍(lán)圖。使用藍(lán)圖可以極大簡化大型應(yīng)用的開發(fā)難度，也為Flask擴(kuò)展提供了一種在應(yīng)用中注冊服務(wù)的集中式機(jī)制。

藍(lán)圖的應(yīng)用場景：

把一個應(yīng)用分解為一個藍(lán)圖的集合。這對大型應(yīng)用是理想的。一個項目可以實例化一個應(yīng)用對象，初始化幾個擴(kuò)展，并注冊一集合的藍(lán)圖。

以URL前綴和/或子域名，在應(yīng)用上注冊一個藍(lán)圖。URL前綴/子域名中的參數(shù)即成為這個藍(lán)圖下的所有視圖函數(shù)的共同的視圖參數(shù)（默認(rèn)情況下） 在一個應(yīng)用中用不同的URL規(guī)則多次注冊一個藍(lán)圖。

通過藍(lán)圖提供模板過濾器、靜態(tài)文件、模板和其他功能。一個藍(lán)圖不一定要實現(xiàn)應(yīng)用或視圖函數(shù)。

初始化一個Flask擴(kuò)展時，在這些情況中注冊一個藍(lán)圖。

藍(lán)圖的缺點：

不能在應(yīng)用創(chuàng)建后撤銷注冊一個藍(lán)圖而不銷毀整個應(yīng)用對象。

使用藍(lán)圖的三個步驟

1.創(chuàng)建一個藍(lán)圖對象

blue = Blueprint("blue",__name__)

2.在這個藍(lán)圖對象上進(jìn)行操作，例如注冊路由、指定靜態(tài)文件夾、注冊模板過濾器...

@blue.route('/') def blue_index():return "Welcome to my blueprint"

3.在應(yīng)用對象上注冊這個藍(lán)圖對象

app.register_blueprint(blue,url_prefix="/blue")

141.Flask 和 Django 路由映射的區(qū)別？

在django中，路由是瀏覽器訪問服務(wù)器時，先訪問的項目中的url，再由項目中的url找到應(yīng)用中url，這些url是放在一個列表里，遵從從前往后匹配的規(guī)則。在flask中，路由是通過裝飾器給每個視圖函數(shù)提供的，而且根據(jù)請求方式的不同可以一個url用于不同的作用。

Django

142.什么是wsgi,uwsgi,uWSGI?

WSGI:

web服務(wù)器網(wǎng)關(guān)接口，是一套協(xié)議。用于接收用戶請求并將請求進(jìn)行初次封裝，然后將請求交給web框架。

實現(xiàn)wsgi協(xié)議的模塊：wsgiref,本質(zhì)上就是編寫一socket服務(wù)端，用于接收用戶請求（django)

werkzeug,本質(zhì)上就是編寫一個socket服務(wù)端，用于接收用戶請求(flask)

uwsgi:

與WSGI一樣是一種通信協(xié)議，它是uWSGI服務(wù)器的獨占協(xié)議，用于定義傳輸信息的類型。 uWSGI:

是一個web服務(wù)器，實現(xiàn)了WSGI的協(xié)議，uWSGI協(xié)議，http協(xié)議

143.Django、Flask、Tornado的對比？

1、 Django走的大而全的方向，開發(fā)效率高。它的MTV框架，自帶的ORM,admin后臺管理,自帶的sqlite數(shù)據(jù)庫和開發(fā)測試用的服務(wù)器，給開發(fā)者提高了超高的開發(fā)效率。 重量級web框架，功能齊全，提供一站式解決的思路，能讓開發(fā)者不用在選擇上花費(fèi)大量時間。

自帶ORM和模板引擎，支持jinja等非官方模板引擎。

自帶ORM使Django和關(guān)系型數(shù)據(jù)庫耦合度高，如果要使用非關(guān)系型數(shù)據(jù)庫，需要使用第三方庫

自帶數(shù)據(jù)庫管理app

成熟，穩(wěn)定，開發(fā)效率高，相對于Flask，Django的整體封閉性比較好，適合做企業(yè)級網(wǎng)站的開發(fā)。python web框架的先驅(qū)，第三方庫豐富

2、 Flask 是輕量級的框架，自由，靈活，可擴(kuò)展性強(qiáng)，核心基于Werkzeug WSGI工具 和jinja2 模板引擎

適用于做小網(wǎng)站以及web服務(wù)的API,開發(fā)大型網(wǎng)站無壓力，但架構(gòu)需要自己設(shè)計

與關(guān)系型數(shù)據(jù)庫的結(jié)合不弱于Django，而與非關(guān)系型數(shù)據(jù)庫的結(jié)合遠(yuǎn)遠(yuǎn)優(yōu)于Django

3、 Tornado走的是少而精的方向，性能優(yōu)越，它最出名的異步非阻塞的設(shè)計方式

Tornado的兩大核心模塊：

iostraem:對非阻塞的socket進(jìn)行簡單的封裝

ioloop: 對I/O 多路復(fù)用的封裝,它實現(xiàn)一個單例

144.CORS 和 CSRF的區(qū)別？

什么是CORS？

CORS是一個W3C標(biāo)準(zhǔn),全稱是“跨域資源共享"(Cross-origin resoure sharing). 它允許瀏覽器向跨源服務(wù)器，發(fā)出XMLHttpRequest請求，從而客服了AJAX只能同源使用的限制。

什么是CSRF？

CSRF主流防御方式是在后端生成表單的時候生成一串隨機(jī)token,內(nèi)置到表單里成為一個字段，同時，將此串token置入session中。每次表單提交到后端時都會檢查這兩個值是否一致，以此來判斷此次表單提交是否是可信的，提交過一次之后，如果這個頁面沒有生成CSRF token,那么token將會被清空,如果有新的需求，那么token會被更新。 攻擊者可以偽造POST表單提交，但是他沒有后端生成的內(nèi)置于表單的token，session中沒有token都無濟(jì)于事。

145.Session,Cookie,JWT的理解

為什么要使用會話管理

眾所周知，HTTP協(xié)議是一個無狀態(tài)的協(xié)議，也就是說每個請求都是一個獨立的請求，請求與請求之間并無關(guān)系。但在實際的應(yīng)用場景，這種方式并不能滿足我們的需求。舉個大家都喜歡用的例子，把商品加入購物車，單獨考慮這個請求，服務(wù)端并不知道這個商品是誰的，應(yīng)該加入誰的購物車？因此這個請求的上下文環(huán)境實際上應(yīng)該包含用戶的相關(guān)信息，在每次用戶發(fā)出請求時把這一小部分額外信息，也做為請求的一部分，這樣服務(wù)端就可以根據(jù)上下文中的信息，針對具體的用戶進(jìn)行操作。所以這幾種技術(shù)的出現(xiàn)都是對HTTP協(xié)議的一個補(bǔ)充，使得我們可以用HTTP協(xié)議+狀態(tài)管理構(gòu)建一個的面向用戶的WEB應(yīng)用。

Session 和Cookie的區(qū)別

這里我想先談?wù)剆ession與cookies,因為這兩個技術(shù)是做為開發(fā)最為常見的。那么session與cookies的區(qū)別是什么？個人認(rèn)為session與cookies最核心區(qū)別在于額外信息由誰來維護(hù)。利用cookies來實現(xiàn)會話管理時，用戶的相關(guān)信息或者其他我們想要保持在每個請求中的信息，都是放在cookies中,而cookies是由客戶端來保存，每當(dāng)客戶端發(fā)出新請求時，就會稍帶上cookies,服務(wù)端會根據(jù)其中的信息進(jìn)行操作。 當(dāng)利用session來進(jìn)行會話管理時，客戶端實際上只存了一個由服務(wù)端發(fā)送的session_id,而由這個session_id,可以在服務(wù)端還原出所需要的所有狀態(tài)信息，從這里可以看出這部分信息是由服務(wù)端來維護(hù)的。

除此以外，session與cookies都有一些自己的缺點：

cookies的安全性不好，攻擊者可以通過獲取本地cookies進(jìn)行欺騙或者利用cookies進(jìn)行CSRF攻擊。使用cookies時,在多個域名下，會存在跨域問題。 session 在一定的時間里，需要存放在服務(wù)端，因此當(dāng)擁有大量用戶時，也會大幅度降低服務(wù)端的性能，當(dāng)有多臺機(jī)器時，如何共享session也會是一個問題.(redis集群)也就是說，用戶第一個訪問的時候是服務(wù)器A，而第二個請求被轉(zhuǎn)發(fā)給了服務(wù)器B，那服務(wù)器B如何得知其狀態(tài)。實際上，session與cookies是有聯(lián)系的，比如我們可以把session_id存放在cookies中的。

JWT是如何工作的

首先用戶發(fā)出登錄請求，服務(wù)端根據(jù)用戶的登錄請求進(jìn)行匹配，如果匹配成功，將相關(guān)的信息放入payload中，利用算法，加上服務(wù)端的密鑰生成token，這里需要注意的是secret_key很重要，如果這個泄露的話，客戶端就可以隨機(jī)篡改發(fā)送的額外信息，它是信息完整性的保證。生成token后服務(wù)端將其返回給客戶端，客戶端可以在下次請求時，將token一起交給服務(wù)端，一般是說我們可以將其放在Authorization首部中，這樣也就可以避免跨域問題。

146.簡述Django請求生命周期

一般是用戶通過瀏覽器向我們的服務(wù)器發(fā)起一個請求(request),這個請求會去訪問視圖函數(shù)，如果不涉及到數(shù)據(jù)調(diào)用，那么這個時候視圖函數(shù)返回一個模板也就是一個網(wǎng)頁給用戶） 視圖函數(shù)調(diào)用模型毛模型去數(shù)據(jù)庫查找數(shù)據(jù)，然后逐級返回，視圖函數(shù)把返回的數(shù)據(jù)填充到模板中空格中，最后返回網(wǎng)頁給用戶。

1.wsgi ,請求封裝后交給web框架（Flask，Django)

2.中間件，對請求進(jìn)行校驗或在請求對象中添加其他相關(guān)數(shù)據(jù)，例如：csrf,request.session

3.路由匹配 根據(jù)瀏覽器發(fā)送的不同url去匹配不同的視圖函數(shù)

4.視圖函數(shù)，在視圖函數(shù)中進(jìn)行業(yè)務(wù)邏輯的處理，可能涉及到：orm，templates

5.中間件，對響應(yīng)的數(shù)據(jù)進(jìn)行處理

6.wsgi，將響應(yīng)的內(nèi)容發(fā)送給瀏覽器

147.用的restframework完成api發(fā)送時間時區(qū)

當(dāng)前的問題是用django的rest framework模塊做一個get請求的發(fā)送時間以及時區(qū)信息的api

class getCurrenttime(APIView):def get(self,request):local_time = time.localtime()time_zone =settings.TIME_ZONEtemp = {'localtime':local_time,'timezone':time_zone}return Response(temp)

148.nginx,tomcat,apach到都是什么？

Nginx（engine x)是一個高性能的HTTP和反向代理服務(wù)器，也是 一個IMAP/POP3/SMTP服務(wù)器，工作在OSI七層，負(fù)載的實現(xiàn)方式：輪詢，IP_HASH,fair,session_sticky. Apache HTTP Server是一個模塊化的服務(wù)器，源于NCSAhttpd服務(wù)器 Tomcat 服務(wù)器是一個免費(fèi)的開放源代碼的Web應(yīng)用服務(wù)器，屬于輕量級應(yīng)用服務(wù)器，是開發(fā)和調(diào)試JSP程序的首選。

149.請給出你熟悉關(guān)系數(shù)據(jù)庫范式有哪些，有什么作用？

在進(jìn)行數(shù)據(jù)庫的設(shè)計時，所遵循的一些規(guī)范，只要按照設(shè)計規(guī)范進(jìn)行設(shè)計，就能設(shè)計出沒有數(shù)據(jù)冗余和數(shù)據(jù)維護(hù)異常的數(shù)據(jù)庫結(jié)構(gòu)。

數(shù)據(jù)庫的設(shè)計的規(guī)范有很多，通常來說我們在設(shè)是數(shù)據(jù)庫時只要達(dá)到其中一些規(guī)范就可以了，這些規(guī)范又稱之為數(shù)據(jù)庫的三范式，一共有三條，也存在著其他范式，我們只要做到滿足前三個范式的要求，就能設(shè)陳出符合我們的數(shù)據(jù)庫了，我們也不能全部來按照范式的要求來做，還要考慮實際的業(yè)務(wù)使用情況，所以有時候也需要做一些違反范式的要求。 1.數(shù)據(jù)庫設(shè)計的第一范式(最基本)，基本上所有數(shù)據(jù)庫的范式都是符合第一范式的，符合第一范式的表具有以下幾個特點：

數(shù)據(jù)庫表中的所有字段都只具有單一屬性，單一屬性的列是由基本的數(shù)據(jù)類型（整型，浮點型，字符型等）所構(gòu)成的設(shè)計出來的表都是簡單的二比表

2.數(shù)據(jù)庫設(shè)計的第二范式(是在第一范式的基礎(chǔ)上設(shè)計的)，要求一個表中只具有一個業(yè)務(wù)主鍵，也就是說符合第二范式的表中不能存在非主鍵列對只對部分主鍵的依賴關(guān)系

3.數(shù)據(jù)庫設(shè)計的第三范式，指每一個非主屬性既不部分依賴與也不傳遞依賴于業(yè)務(wù)主鍵，也就是第二范式的基礎(chǔ)上消除了非主屬性對主鍵的傳遞依賴

150.簡述QQ登陸過程

qq登錄，在我們的項目中分為了三個接口，

第一個接口是請求qq服務(wù)器返回一個qq登錄的界面;

第二個接口是通過掃碼或賬號登陸進(jìn)行驗證，qq服務(wù)器返回給瀏覽器一個code和state,利用這個code通過本地服務(wù)器去向qq服務(wù)器獲取access_token覆返回給本地服務(wù)器，憑借access_token再向qq服務(wù)器獲取用戶的openid(openid用戶的唯一標(biāo)識)

第三個接口是判斷用戶是否是第一次qq登錄，如果不是的話直接登錄返回的jwt-token給用戶，對沒有綁定過本網(wǎng)站的用戶，對openid進(jìn)行加密生成token進(jìn)行綁定

151.post 和 get的區(qū)別?

1.GET是從服務(wù)器上獲取數(shù)據(jù)，POST是向服務(wù)器傳送數(shù)據(jù)

2.在客戶端，GET方式在通過URL提交數(shù)據(jù)，數(shù)據(jù)在URL中可以看到，POST方式，數(shù)據(jù)放置在HTML——HEADER內(nèi)提交

3.對于GET方式，服務(wù)器端用Request.QueryString獲取變量的值，對于POST方式，服務(wù)器端用Request.Form獲取提交的數(shù)據(jù)

152.項目中日志的作用

一、日志相關(guān)概念

1.日志是一種可以追蹤某些軟件運(yùn)行時所發(fā)生事件的方法

2.軟件開發(fā)人員可以向他們的代碼中調(diào)用日志記錄相關(guān)的方法來表明發(fā)生了某些事情

3.一個事件可以用一個包含可選變量數(shù)據(jù)的消息來描述

4.此外，事件也有重要性的概念，這個重要性也可以被成為嚴(yán)重性級別(level)

二、日志的作用

1.通過log的分析，可以方便用戶了解系統(tǒng)或軟件、應(yīng)用的運(yùn)行情況;

2.如果你的應(yīng)用log足夠豐富，可以分析以往用戶的操作行為、類型喜好，地域分布或其他更多信息;

3.如果一個應(yīng)用的log同時也分了多個級別，那么可以很輕易地分析得到該應(yīng)用的健康狀況，及時發(fā)現(xiàn)問題并快速定位、解決問題，補(bǔ)救損失。

4.簡單來講就是我們通過記錄和分析日志可以了解一個系統(tǒng)或軟件程序運(yùn)行情況是否正常，也可以在應(yīng)用程序出現(xiàn)故障時快速定位問題。不僅在開發(fā)中，在運(yùn)維中日志也很重要，日志的作用也可以簡單。總結(jié)為以下幾點：

1.程序調(diào)試

2.了解軟件程序運(yùn)行情況，是否正常

3,軟件程序運(yùn)行故障分析與問題定位

4,如果應(yīng)用的日志信息足夠詳細(xì)和豐富，還可以用來做用戶行為分析

153.django中間件的使用？

Django在中間件中預(yù)置了六個方法，這六個方法的區(qū)別在于不同的階段執(zhí)行，對輸入或輸出進(jìn)行干預(yù)，方法如下：

1.初始化：無需任何參數(shù)，服務(wù)器響應(yīng)第一個請求的時候調(diào)用一次，用于確定是否啟用當(dāng)前中間件

def __init__():pass

2.處理請求前：在每個請求上調(diào)用，返回None或HttpResponse對象。

def process_request(request):pass

3.處理視圖前:在每個請求上調(diào)用，返回None或HttpResponse對象。

def process_view(request,view_func,view_args,view_kwargs):pass

4.處理模板響應(yīng)前：在每個請求上調(diào)用，返回實現(xiàn)了render方法的響應(yīng)對象。

def process_template_response(request,response):pass

5.處理響應(yīng)后：所有響應(yīng)返回瀏覽器之前被調(diào)用，在每個請求上調(diào)用，返回HttpResponse對象。

def process_response(request,response):pass

6.異常處理：當(dāng)視圖拋出異常時調(diào)用，在每個請求上調(diào)用，返回一個HttpResponse對象。

def process_exception(request,exception):pass

154.談一下你對uWSGI和nginx的理解？

1.uWSGI是一個Web服務(wù)器，它實現(xiàn)了WSGI協(xié)議、uwsgi、http等協(xié)議。Nginx中HttpUwsgiModule的作用是與uWSGI服務(wù)器進(jìn)行交換。WSGI是一種Web服務(wù)器網(wǎng)關(guān)接口。它是一個Web服務(wù)器（如nginx，uWSGI等服務(wù)器）與web應(yīng)用（如用Flask框架寫的程序）通信的一種規(guī)范。

要注意WSGI/uwsgi/uWSGI這三個概念的區(qū)分。

WSGI是一種通信協(xié)議。

uwsgi是一種線路協(xié)議而不是通信協(xié)議，在此常用于在uWSGI服務(wù)器與其他網(wǎng)絡(luò)服務(wù)器的數(shù)據(jù)通信。

uWSGI是實現(xiàn)了uwsgi和WSGI兩種協(xié)議的Web服務(wù)器。

nginx 是一個開源的高性能的HTTP服務(wù)器和反向代理：

1.作為web服務(wù)器，它處理靜態(tài)文件和索引文件效果非常高

2.它的設(shè)計非常注重效率，最大支持5萬個并發(fā)連接，但只占用很少的內(nèi)存空間

3.穩(wěn)定性高，配置簡潔。

4.強(qiáng)大的反向代理和負(fù)載均衡功能，平衡集群中各個服務(wù)器的負(fù)載壓力應(yīng)用

155.Python中三大框架各自的應(yīng)用場景？

django:主要是用來搞快速開發(fā)的，他的亮點就是快速開發(fā)，節(jié)約成本，,如果要實現(xiàn)高并發(fā)的話，就要對django進(jìn)行二次開發(fā)，比如把整個笨重的框架給拆掉自己寫socket實現(xiàn)http的通信,底層用純c,c++寫提升效率，ORM框架給干掉，自己編寫封裝與數(shù)據(jù)庫交互的框架,ORM雖然面向?qū)ο髞聿僮鲾?shù)據(jù)庫，但是它的效率很低，使用外鍵來聯(lián)系表與表之間的查詢; flask: 輕量級，主要是用來寫接口的一個框架，實現(xiàn)前后端分離，提考開發(fā)效率，Flask本身相當(dāng)于一個內(nèi)核，其他幾乎所有的功能都要用到擴(kuò)展(郵件擴(kuò)展Flask-Mail，用戶認(rèn)證Flask-Login),都需要用第三方的擴(kuò)展來實現(xiàn)。比如可以用Flask-extension加入ORM、文件上傳、身份驗證等。Flask沒有默認(rèn)使用的數(shù)據(jù)庫，你可以選擇MySQL，也可以用NoSQL。

其WSGI工具箱用Werkzeug(路由模塊)，模板引擎則使用Jinja2,這兩個也是Flask框架的核心。

Tornado： Tornado是一種Web服務(wù)器軟件的開源版本。Tornado和現(xiàn)在的主流Web服務(wù)器框架（包括大多數(shù)Python的框架）有著明顯的區(qū)別：它是非阻塞式服務(wù)器，而且速度相當(dāng)快。得利于其非阻塞的方式和對epoll的運(yùn)用，Tornado每秒可以處理數(shù)以千計的連接因此Tornado是實時Web服務(wù)的一個理想框架

156.Django中哪里用到了線程？哪里用到了協(xié)程？哪里用到了進(jìn)程？

1.Django中耗時的任務(wù)用一個進(jìn)程或者線程來執(zhí)行，比如發(fā)郵件，使用celery.

2.部署django項目是時候，配置文件中設(shè)置了進(jìn)程和協(xié)程的相關(guān)配置。

157.有用過Django REST framework嗎？

Django REST framework是一個強(qiáng)大而靈活的Web API工具。使用RESTframework的理由有：

Web browsable API對開發(fā)者有極大的好處

包括OAuth1a和OAuth2的認(rèn)證策略

支持ORM和非ORM數(shù)據(jù)資源的序列化

全程自定義開發(fā)--如果不想使用更加強(qiáng)大的功能，可僅僅使用常規(guī)的function-based views額外的文檔和強(qiáng)大的社區(qū)支持

158.對cookies與session的了解？他們能單獨用嗎？

Session采用的是在服務(wù)器端保持狀態(tài)的方案，而Cookie采用的是在客戶端保持狀態(tài)的方案。但是禁用Cookie就不能得到Session。因為Session是用Session ID來確定當(dāng)前對話所對應(yīng)的服務(wù)器Session，而Session ID是通過Cookie來傳遞的，禁用Cookie相當(dāng)于SessionID,也就得不到Session。

爬蟲

159.試列出至少三種目前流行的大型數(shù)據(jù)庫

160.列舉您使用過的Python網(wǎng)絡(luò)爬蟲所用到的網(wǎng)絡(luò)數(shù)據(jù)包?

requests, urllib,urllib2, httplib2

161.爬取數(shù)據(jù)后使用哪個數(shù)據(jù)庫存儲數(shù)據(jù)的，為什么？

162.你用過的爬蟲框架或者模塊有哪些？優(yōu)缺點？

Python自帶：urllib,urllib2

第三方：requests

框架： Scrapy

urllib 和urllib2模塊都做與請求URL相關(guān)的操作，但他們提供不同的功能。

urllib2: urllib2.urlopen可以接受一個Request對象或者url,(在接受Request對象時，并以此可以來設(shè)置一個URL的headers),urllib.urlopen只接收一個url。

urllib 有urlencode,urllib2沒有，因此總是urllib, urllib2常會一起使用的原因

scrapy是封裝起來的框架，他包含了下載器，解析器，日志及異常處理，基于多線程，twisted的方式處理，對于固定單個網(wǎng)站的爬取開發(fā)，有優(yōu)勢，但是對于多網(wǎng)站爬取100個網(wǎng)站，并發(fā)及分布式處理不夠靈活，不便調(diào)整與擴(kuò)展

requests是一個HTTP庫，它只是用來請求，它是一個強(qiáng)大的庫，下載，解析全部自己處理，靈活性高

Scrapy優(yōu)點：異步，xpath，強(qiáng)大的統(tǒng)計和log系統(tǒng)，支持不同url。shell方便獨立調(diào)試。寫middleware方便過濾。通過管道存入數(shù)據(jù)庫

163.寫爬蟲是用多進(jìn)程好？還是多線程好？

164.常見的反爬蟲和應(yīng)對方法？

165.解析網(wǎng)頁的解析器使用最多的是哪幾個?

166.需要登錄的網(wǎng)頁，如何解決同時限制ip，cookie,session

167.驗證碼的解決?

168.使用最多的數(shù)據(jù)庫，對他們的理解？

169.編寫過哪些爬蟲中間件？

170.“極驗”滑動驗證碼如何破解？

171.爬蟲多久爬一次，爬下來的數(shù)據(jù)是怎么存儲？

172.cookie過期的處理問題？

173.動態(tài)加載又對及時性要求很高怎么處理？

174.HTTPS有什么優(yōu)點和缺點？

175.HTTPS是如何實現(xiàn)安全傳輸數(shù)據(jù)的？

176.TTL，MSL，RTT各是什么？

177.談一談你對Selenium和PhantomJS了解

178.平常怎么使用代理的 ？

179.存放在數(shù)據(jù)庫(redis、mysql等)。

180.怎么監(jiān)控爬蟲的狀態(tài)?

181.描述下scrapy框架運(yùn)行的機(jī)制？

182.談?wù)勀銓crapy的理解？

183.怎么樣讓 scrapy 框架發(fā)送一個 post 請求（具體寫出來）

184.怎么監(jiān)控爬蟲的狀態(tài) ？

185.怎么判斷網(wǎng)站是否更新？

186.圖片、視頻爬取怎么繞過防盜連接

187.你爬出來的數(shù)據(jù)量大概有多大？大概多長時間爬一次？

188.用什么數(shù)據(jù)庫存爬下來的數(shù)據(jù)？部署是你做的嗎？怎么部署？

189.增量爬取

190.爬取下來的數(shù)據(jù)如何去重，說一下scrapy的具體的算法依據(jù)。

191.Scrapy的優(yōu)缺點?

192.怎么設(shè)置爬取深度？

193.scrapy和scrapy-redis有什么區(qū)別？為什么選擇redis數(shù)據(jù)庫？

194.分布式爬蟲主要解決什么問題？

195.什么是分布式存儲？

196.你所知道的分布式爬蟲方案有哪些？

197.scrapy-redis，有做過其他的分布式爬蟲嗎？

總結(jié)

以上是生活随笔為你收集整理的Python面试题大全（三）：Web开发（Flask、爬虫）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。