Python後端面試題

時間 2019-11-11

標籤 python 端面試題欄目 Python 简体版

原文原文鏈接

Python後端面試題

1.語言

Python面試,基礎相關問題少不了.html

python高併發解決方案

提示:
我但願聽到twisted->tornado->geventpython
答案:
gevent
代碼看起來好看一些,可是維護比較差,patch沒有規律,並且裏面封裝了C,對python3的支持最差.
twisted
穩定性是最好的,可是須要較長時間的學習.對python3的支持較差.
tornado
兼容性最好.可是過於簡單了,功能不強,另外沒有python數據庫適配器能和tornado無縫對接,所以調用數據庫很麻煩,並且只支持web.mysql

談談python的迭代器,生成器,裝飾器,yield?

提示:
這幾個概念很容易混淆,建議經過邊畫圖,邊介紹的方式來表達.linux
答案:
迭代器
(Iterator)迭代器是帶狀態的對象,它會記錄當前迭代所在的位置,以方便下次迭代的時候獲取正確的元素.
生成器
(generator)生成器和裝飾器是python中最吸引人的兩個黑科技,生成器雖沒有裝飾器那麼經常使用,但在某些針對的情境下十分有效.
裝飾器
(Decorator)裝飾器是python中最吸引人的特性,裝飾器本質上仍是一個函數,它可讓已有的函數不作任何改動的狀況下增長功能.程序員

標準庫線程安全的隊列是哪個？不安全的是哪個？logging是線程安全的嗎？

提示:
混淆視聽,其實Python隊列都是線程安全的,該問題主要考察你對隊列的瞭解和線程安全的概念.web
答案:
線程
線程安全和非線程安全這些概念在其餘的編程語言也一樣使用.
所謂線程安全：就是對於多線程同時操做是是安全的而不會發生寫衝突,好比python的Queue
相反非線程安全：就是多線成同時操做時會發生寫衝突,好比python的其餘list,set,dict
隊列
Python的Queue模塊中提供了同步的.線程安全的隊列類,包括FIFO（先入先出)隊列Queue,LIFO（後入先出）隊列LifoQueue,和優先級隊列PriorityQueue.這些隊列都實現了鎖原語,可以在多線程中直接使用.可使用隊列來實現線程間的同步.
三種隊列
Python queue模塊有三種隊列:
1.FIFO隊列先進先出.(線程安全)
2.LifoQueue相似於堆,即先進後出(線程安全)
3.PriorityQueue優先級隊列,級別越低,越先出來(線程安全)
隊列構造函數
針對這三種隊列分別有三個構造函數:
1.class Queue.Queue(maxsize) FIFO
2.class Queue.LifoQueue(maxsize) LIFO
3.class Queue.PriorityQueue(maxsize) 優先級隊列
logging
logging是Python標準庫裏的日誌模塊(線程安全)面試

2.操做系統

能夠直接認爲是linux,畢竟搞後端的多數是和linux打交道.redis

tcp/udp的區別?tcp粘包有了解嗎?

提示:
我但願聽到TCP粘包與分包,爲何會有這種狀況,應該如何解決.能講到UDP是否會有一樣狀況發生更好.算法
答案:
tcp/udp的區別
TCP與UDP區別總結：
1.TCP面向鏈接（如打電話要先撥號創建鏈接）;UDP是無鏈接的,即發送數據以前不須要創建鏈接
2.TCP提供可靠的服務.也就是說,經過TCP鏈接傳送的數據,無差錯,不丟失,不重複,且按序到達;UDP盡最大努力交付,即不保證可靠交付
3.TCP面向字節流,其實是TCP把數據當作一連串無結構的字節流;UDP是面向報文的
UDP沒有擁塞控制,所以網絡出現擁塞不會使源主機的發送速率下降（對實時應用頗有用,如IP電話,實時視頻會議等）
4.每一條TCP鏈接只能是點到點的;UDP支持一對一,一對多,多對一和多對多的交互通訊
5.TCP首部開銷20字節;UDP的首部開銷小,只有8個字節
6.TCP的邏輯通訊信道是全雙工的可靠信道,UDP則是不可靠信道
關於分包和粘包
粘包：發送方發送兩個字符串」hello」+」world」,接收方卻一次性接收到了」helloworld」.
分包：發送方發送字符串」helloworld」,接收方卻接收到了兩個字符串」hello」和」world」.
TCP爲何會分包
TCP是以段（Segment）爲單位發送數據的,創建TCP連接後,有一個最大消息長度（MSS）.若是應用層數據包超過MSS,就會把應用層數據包拆分,分紅兩個段來發送.這個時候接收端的應用層就要拼接這兩個TCP包,才能正確處理數據.
TCP爲何會粘包
有時候,TCP爲了提升網絡的利用率,會使用一個叫作Nagle的算法.該算法是指,發送端即便有要發送的數據,若是不多的話,會延遲發送.若是應用層給TCP傳送數據很快的話,就會把兩個應用層數據包「粘」在一塊兒,TCP最後只發一個TCP數據包給接收端.
如何處理
在進行TCP Socket開發時,都須要處理數據包粘包和分包的狀況.使用的語言是Python.實際上解決該問題很簡單,在應用層下,定義一個協議：消息頭部+消息長度+消息正文便可.sql

TIME_WAIT,CLOSE_WAIT,ESTABLISHED是什麼?出現過多的CLOSE_WAIT多是什麼緣由?

提示:
考驗你對實際開發中遇到的常見問題,處理方式
答案:
使用netstat和awk命令來統計網絡鏈接數
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
TIME_WAIT：表示主動關閉,經過優化系統內核參數可容易解決.
CLOSE_WAIT：表示被動關閉,須要從程序自己出發.
ESTABLISHED：表示正在通訊過多CLOSE_WAIT緣由
出現大量close_wait的現象,主要緣由是某種狀況下對方關閉了socket連接,可是我方忙與讀或者寫,沒有關閉鏈接.代碼須要判斷socket,一旦讀到0,斷開鏈接,read返回負,檢查一下errno,若是不是AGAIN,就斷開鏈接.

epoll,select的區別？邊緣觸發,水平觸發區別？

提示:
考驗在linux開發中,服務器端處理請求的選擇問題
答案:
select和epoll這兩個機制都I/O複用的解決方案,select爲POSIX標準中的,而epoll爲Linux所特有.
更多查看

3.存儲

存儲可能包含rdbms,nosql以及緩存等,我以mysql,redis舉例

3.1mysql相關

瞭解mysql字符集和排序規則嗎？

提示:
在服務器建表時字符集(Character Set)和排序規則(Collation)是必不可少的,對他了解多少,如何選擇.
答案:
字符集
所謂字符集,就是用來定義字符在數據庫中的編碼的集合.常見的字符集有：utf8（支持中文）和ascii（不支持中文）
排序規則
數據庫中的排序規則,就是用來定義字符在進行排序和比較時的一種規則.常見的以下： 1.utf8_general_ci 不區分大小寫,utf8_general_cs 區分大小寫.2.utf8_bin 規定每一個字符串用二進制編碼存儲,區分大小寫,能夠直接存儲二進制的內容
說明：所爲排序規則,就是指字符比較時是否區分大小寫,以及是按照字符編碼進行比較仍是直接用二進制數據比較.

總結:這邊用gbk_chinese_ci來作例子.
字符集名字語言後綴,其中各個典型後綴的含義以下：
1._ci：不區分大小寫的排序方式
2._cs：區分大小寫的排序方式
3._bin：二進制排序方式,大小比較將根據字符編碼,不涉及人類語言,所以_bin的排序方式不包含人類語言
所以gbk_chinese_ci排序方式就表示：字符集爲gbk,人類語言使用中文來比較大小,比較時區分大小寫.

varchar與char的區別是什麼？大小限制？utf8字符集下varchar最多能存多少個字符?

提示:
char與varchar這兩個字符類型在mysql中常常碰見,正確的使用,能夠提升效率與避免空間上的浪費.
答案:
存數據時的區別
char定義的是固定長度,長度範圍爲0-255,存儲時,若是字符數沒有達到定義的位數,會在後面用空格補全存入數據庫中,在上例中,name實際存儲在數據中的數據爲'zejin '
varchar是變長長度,長度範圍爲0-65535,存儲時,若是字符沒有達到定義的位數,也不會在後面補空格,在上例subject字段中,實際存儲在數據中的數據爲'zejin ',固然還有一或兩個字節來描述該字節長度
取數據時的區別
數據庫取char的數據時,會把後面的空格所有丟棄掉,也就是說,在char中的尾部存入空格時,最後取出來都會被丟棄.而數據庫在取varchar數據時,尾部空格會保留.

primary key和unique key的區別？

提示:
primary key = unique + not null
答案:
Primary key與Unique Key都是惟一性約束.但兩者有很大的區別：
unique Key
1.惟一鍵,一個表只能有一個PRIMARY KEY.
2.Primary key的1個或多個列必須爲NOT NULL,若是列爲NULL,在增長PRIMARY KEY時,列自動更改成NOT NULL.
Primary key
1.主鍵,一個表能夠有多個UNIQUE KEY
2.UNIQUE KEY 對列沒有NOT NULL或NULL的特殊要求.

外鍵有什麼用,是否該用外鍵？外鍵必定須要索引嗎？

提示:
主要考你對錶的設計與優化.能夠經過使用外鍵的優缺點來分析該問題.
答案:
外鍵是什麼
程序很難100％保證數據的完整性,而用外鍵即便在數據庫服務器down機或者出現其餘問題的時候,也可以最大限度的保證數據的一致性和完整性.
是否該用外鍵
因需而定,在大型系統中（性能要求不高,安全要求高）,使用外鍵；在大型系統中（性能要求高,安全本身控制）,不用外鍵；小系統隨便,最好用外鍵.
外鍵是否須要索引
加入外鍵的主要問題就是影響性能,所以加入索引能加快關聯查詢的速度.

myisam與innodb的區別與選擇？

提示:
但願看到你經過對二者區別和針對公司的業務類型來選擇合適的表類型,這樣才能發揮mysql的性能優點.
答案:
myisam與innodb是mysql的儲引擎.
區別
1.InnoDB支持事務,MyISAM不支持,對於InnoDB每一條SQL語言都默認封裝成事務,自動提交,這樣會影響速度,因此最好把多條SQL語言放在begin和commit之間,組成一個事務；
2.InnoDB支持外鍵,而MyISAM不支持.對一個包含外鍵的InnoDB錶轉爲MYISAM會失敗；
3.InnoDB是彙集索引,數據文件是和索引綁在一塊兒的,必需要有主鍵,經過主鍵索引效率很高.可是輔助索引須要兩次查詢,先查詢到主鍵,而後再經過主鍵查詢到數據.所以,主鍵不該該過大,由於主鍵太大,其餘索引也都會很大.而MyISAM是非彙集索引,數據文件是分離的,索引保存的是數據文件的指針.主鍵索引和輔助索引是獨立的.
4.InnoDB不保存表的具體行數,執行select count() from table時須要全表掃描.而MyISAM用一個變量保存了整個表的行數,執行上述語句時只須要讀出該變量便可,速度很快； *
5.Innodb不支持全文索引,而MyISAM支持全文索引,查詢效率上MyISAM要高；* *
選擇
1.是否要支持事務,若是要請選擇innodb,若是不須要能夠考慮MyISAM；
2.若是表中絕大多數都只是讀查詢,能夠考慮MyISAM,若是既有讀寫也挺頻繁,請使用InnoDB.
3.系統奔潰後,MyISAM恢復起來更困難,可否接受；
4.MySQL5.5版本開始Innodb已經成爲Mysql的默認引擎*(以前是MyISAM),說明其優點是有目共睹的,若是你不知道用什麼,那就用InnoDB,至少不會差.

總結
讀操做多用MyISAM
寫操做多用InnoDB

索引有什麼用,大體原理是什麼？設計索引有什麼注意點？

提示:
鑑於建立索引須要額外的磁盤空間（,以及太多的索引會致使文件系統大小限制所產生的問題,因此對哪些字段創建索引,什麼狀況下使用索引,須要審慎考慮.
答案:
*索引做用
MySQL索引在MySQL數據庫中,能夠有效提升查詢的效率,尤爲是查詢數據量很是大時,效果更爲明顯,每每能使查詢速度加快成千上萬倍.
索引原理
MySQL索引主要有一下幾種索引類型:FULLTEXT,HASH,BTREE,RTREE,對不通類型有着不通的存儲引擎,如上面提到的MyISAM,InnoDB.
使用注意
並不是全部的數據庫都以相同的方式使用索引.做爲通用規則,只有當常常查詢索引列中的數據時,才須要在表上建立索引.索引佔用磁盤空間,而且下降添加.刪除和更新行的速度.在多數狀況下,索引用於數據檢索的速度優點大大超過它的不足之處.可是,若是應用程序很是頻繁地更新數據或磁盤空間有限,則可能須要限制索引的數量.

3.2redis相關

什麼場景用redis,爲何mysql不適合？

提示:
不一樣需求不一樣場景有着不一樣選擇,通常能夠redis+mysql聯用,若是能夠涉及memcache,mongoDB這些no sql系列加分.
答案:
redis場景
1.會話緩存（Session Cache）
用Redis緩存會話比其餘存儲（如Memcached）的優點在於：Redis提供持久化.
2.全頁緩存（FPC）
即便重啓了Redis實例,由於有磁盤的持久化
3.隊列
Redis做爲隊列使用的操做,就相似於本地程序語言（如Python）對 list 的 push/pop 操做.
4.排行榜/計數器
集合（Set）和有序集合（Sorted Set）也使得咱們在執行這些操做的時候變的很是簡單
5.發佈/訂閱
在社交網絡鏈接中使用,還可做爲基於發佈/訂閱的腳本觸發器,甚至用Redis的發佈/訂閱功能來創建聊天系統
redis與mysql
這二者是內存和硬盤的關係,硬盤放置主體數據用於持久化存儲,而內存則是當前運行的那部分數據,CPU訪問內存而不是磁盤,這大大提高了運行的速度,固然這是基於程序的局部化訪問原理.
推理到redis+mysql,它是內存+磁盤關係的一個映射,mysql放在磁盤,redis放在內存,這樣的話,web應用每次只訪問redis,若是沒有找到的數據,纔去訪問Mysql.

談談redis的事務？能夠處理分佈式事務嗎？怎麼解決?

提示:
redis自己不處理分佈式事物或者說它的事物很是弱,由於redis自己是單線程的.
答案:
經過Redis+Lua方案,Redis的事務對處理較複雜的業務需求很是有用.
其次,Redis中實現事務有2種方式:
1.使用MULIT,EXEC,DISCARD和WATCH等命令;
2.使用Lua腳本封裝多個redis基本命令,來實現一個複雜的事務操做.
3.DISCARD指令就是用來回滾的.

redis內存滿了會怎麼樣？

提示:
須要你描述解決該問題的過程(原由-分析-排查-解決)
答案:
當內存滿了,不容許再存數據,會出現錯誤OOM command not allowed when used memory > ‘maxmemory’

4.安全

Web安全與咱們平時開發到處關聯,那麼web開發須要在工做中注意哪些安全方面的問題？

sql注入是怎麼產生的,如何防止

提示:
對於一個有經驗的開發人員,代碼的書寫規範是門必修課,這裏考的就是程序員對書寫sql語句中是否注意書寫規範.
答案:
sql不由是Python中須要防範的問題,在其餘語言也是個必不可少的問題,這裏引用PHP的防注入方案.
1.過濾掉一些常見的數據庫操做關鍵字:select,insert,update,delete,and,*等.或者經過系統函數:addslashes(須要被過濾的內容)來進行過濾.
2.SQL語句書寫的時候儘可能不要省略小引號(tab鍵上面那個)和單引號.
3.提升數據庫命名技巧,對於一些重要的字段根據程序的特色命名,取不易被猜到的.
4.對於經常使用的方法加以封裝,避免直接暴漏SQL語句.
5.控制錯誤信息.
關閉錯誤提示信息,將錯誤信息寫到系統日誌.
6.使用Mysqli和PDO鏈接mysql數據預處理.

xss是什麼,如何預防？ - 提示:
利用django/flask都是能夠防止xss攻擊的.

答案:
什麼是XSS攻擊
XSS即跨站腳本攻擊,XSS是一種常常出如今web應用中的計算機安全漏洞,它容許惡意web用戶將代碼植入到提供給其它用戶使用的頁面中.簡單的說就是HTML注入問題.
防止XSS攻擊的兩種方式
1.對單一變量進行轉義過濾.可使用escape過濾器,無需轉義時使用safe過濾器
2.利用django的HTML自動轉義,無需autoescape 標籤,django中的HTML文檔會自動轉義.

csrf是什麼？如何防範的？

提示:
用 django 有多久,跟 csrf 這個概念打交道就有久.
答案:
csrf是什麼
CSRF,跨站點僞造請求.顧名思義,就是是僞造請求,冒充用戶在站內的正常操做.
經過Django來防範CSRF
1.首先,最基本的原則是：GET 請求不要用有反作用.也就是說任何處理 GET 請求的代碼對資源的訪問都必定要是「只讀「的.
2.啓用 django.middleware.csrf.CsrfViewMiddleware 這個中間件.
3.再次,在全部的 POST 表單元素時,須要加上一個csrf_token的tag.
4.在渲染模塊時,使用 render.它會處理 csrf_token 這個 tag,從而自動爲表單添加一個名爲csrfmiddlewaretoken 的 input.
更多XSS與CSRF詳情見

4.2密碼技術

簡單說說https的工做原理與http的區別？

提示:
但願能夠講到裏面使用了哪些加密算法
答案:
Https是一種基於SSL/TLS的Http協議,全部的http數據都是在SSL/TLS協議封裝之上傳輸的.
Https協議在Http協議的基礎上,添加了SSL/TLS握手以及數據加密傳輸,也屬於應用層協議.
1.HTTP協議運行在TCP之上,全部傳輸的內容都是明文,客戶端和服務器端都沒法驗證對方的身份.
2.HTTPS是運行在SSL/TLS之上的HTTP協議,SSL/TLS運行在TCP之上.全部傳輸的內容都通過加密,加密採用對稱加密,但對稱加密的密鑰用服務器方的證書進行了非對稱加密.

說說https有什麼優缺點?

提示:
從安全與性能方向回答.
答案:
優勢
1.使用 HTTPS 協議可認證用戶和服務器,確保數據發送到正確的客戶機和服務器;
2.HTTPS 協議是由 SSL+HTTP 協議構建的可進行加密傳輸.身份認證的網絡協議, 要比 http 協議安全,可防止數據在傳輸過程當中不被竊取.改變,確保數據的完整性.
3.HTTPS 是現行架構下最安全的解決方案,雖然不是絕對安全,但它大幅增長了中間人攻擊的成本.
缺點
1.HTTPS 協議的加密範圍也比較有限,在黑客攻擊.拒絕服務攻擊.服務器劫持等方面幾乎起不到什麼做用
2.HTTPS 協議還會影響緩存,增長數據開銷和功耗,甚至已有安全措施也會受到影響.
3.SSL 證書須要錢.功能越強大的證書費用越高.我的網站.小網站沒有必要通常不會用.
4.HTTPS 鏈接服務器端資源佔用高不少,握手階段比較費時對網站的相應速度有負面影響.
5.HTTPS 鏈接緩存不如 HTTP 高效.

對稱加密與非對稱加密區別？

提示:
對稱加密高效不安全,非對稱加密安全不高效.
答案:
對稱加密
對稱加密是指加密和解密使用的密鑰是同一個密鑰,或者能夠相互推算.對稱加密的優勢是算法簡單,加解密效率高,系統開銷小,適合對大數據量加密.缺點是解密加密使用同一個密鑰,須要考慮遠程通訊的狀況下如何安全的交換密鑰,若是密鑰丟失,所謂的加密解密就失效了.
非對稱加密
非對稱加密和解密使用的密鑰不是同一密鑰,其中一個對外界公開,被稱爲公鑰,另外一個只有全部者知道,
稱做私鑰.
用公鑰加密的信息必須用私鑰才能解開,反之,用私鑰加密的信息只有用公鑰才能解開.