Python web面試題
Python后端面試題
1.語言
Python面試,基礎(chǔ)相關(guān)問題少不了.
提示:
我希望聽到twisted->tornado->gevent答案:
gevent
代碼看起來好看一些,但是維護(hù)比較差,patch沒有規(guī)律,而且里面封裝了C,對python3的支持最差.
twisted
穩(wěn)定性是最好的,但是需要較長時(shí)間的學(xué)習(xí).對python3的支持較差.
tornado
兼容性最好.但是過于簡單了,功能不強(qiáng),另外沒有python數(shù)據(jù)庫適配器能和tornado無縫對接,因此調(diào)用數(shù)據(jù)庫很麻煩,而且只支持web.
提示:
這幾個(gè)概念很容易混淆,建議通過邊畫圖,邊介紹的方式來表達(dá).答案:
迭代器
(Iterator)迭代器是帶狀態(tài)的對象,它會記錄當(dāng)前迭代所在的位置,以方便下次迭代的時(shí)候獲取正確的元素.
生成器
(generator)生成器和裝飾器是python中最吸引人的兩個(gè)黑科技,生成器雖沒有裝飾器那么常用,但在某些針對的情境下十分有效.
裝飾器
(Decorator)裝飾器是python中最吸引人的特性,裝飾器本質(zhì)上還是一個(gè)函數(shù),它可以讓已有的函數(shù)不做任何改動的情況下增加功能.
提示:
混淆視聽,其實(shí)Python隊(duì)列都是線程安全的,該問題主要考察你對隊(duì)列的了解和線程安全的概念.答案:
線程
線程安全和非線程安全這些概念在其他的編程語言也同樣使用.
所謂線程安全：就是對于多線程同時(shí)操作是是安全的而不會發(fā)生寫沖突,比如python的Queue
相反非線程安全：就是多線成同時(shí)操作時(shí)會發(fā)生寫沖突,比如python的其他list,set,dict
隊(duì)列
Python的Queue模塊中提供了同步的.線程安全的隊(duì)列類,包括FIFO（先入先出)隊(duì)列Queue,LIFO（后入先出）隊(duì)列LifoQueue,和優(yōu)先級隊(duì)列PriorityQueue.這些隊(duì)列都實(shí)現(xiàn)了鎖原語,能夠在多線程中直接使用.可以使用隊(duì)列來實(shí)現(xiàn)線程間的同步.
三種隊(duì)列
Python queue模塊有三種隊(duì)列:
1.FIFO隊(duì)列先進(jìn)先出.(線程安全)
2.LifoQueue類似于堆,即先進(jìn)后出(線程安全)
3.PriorityQueue優(yōu)先級隊(duì)列,級別越低,越先出來(線程安全)
隊(duì)列構(gòu)造函數(shù)
針對這三種隊(duì)列分別有三個(gè)構(gòu)造函數(shù):
1.class Queue.Queue(maxsize) FIFO
2.class Queue.LifoQueue(maxsize) LIFO
3.class Queue.PriorityQueue(maxsize) 優(yōu)先級隊(duì)列
logging
logging是Python標(biāo)準(zhǔn)庫里的日志模塊(線程安全)
2.操作系統(tǒng)
可以直接認(rèn)為是linux,畢竟搞后端的多數(shù)是和linux打交道.
提示:
我希望聽到TCP粘包與分包,為什么會有這種情況,應(yīng)該如何解決.能講到UDP是否會有同樣情況發(fā)生更好.答案:
tcp/udp的區(qū)別
TCP與UDP區(qū)別總結(jié)：
1.TCP面向連接（如打電話要先撥號建立連接）;UDP是無連接的,即發(fā)送數(shù)據(jù)之前不需要建立連接
2.TCP提供可靠的服務(wù).也就是說,通過TCP連接傳送的數(shù)據(jù),無差錯,不丟失,不重復(fù),且按序到達(dá);UDP盡最大努力交付,即不保 證可靠交付
3.TCP面向字節(jié)流,實(shí)際上是TCP把數(shù)據(jù)看成一連串無結(jié)構(gòu)的字節(jié)流;UDP是面向報(bào)文的
UDP沒有擁塞控制,因此網(wǎng)絡(luò)出現(xiàn)擁塞不會使源主機(jī)的發(fā)送速率降低（對實(shí)時(shí)應(yīng)用很有用,如IP電話,實(shí)時(shí)視頻會議等）
4.每一條TCP連接只能是點(diǎn)到點(diǎn)的;UDP支持一對一,一對多,多對一和多對多的交互通信
5.TCP首部開銷20字節(jié);UDP的首部開銷小,只有8個(gè)字節(jié)
6.TCP的邏輯通信信道是全雙工的可靠信道,UDP則是不可靠信道
關(guān)于分包和粘包
粘包：發(fā)送方發(fā)送兩個(gè)字符串”hello”+”world”,接收方卻一次性接收到了”helloworld”.
分包：發(fā)送方發(fā)送字符串”helloworld”,接收方卻接收到了兩個(gè)字符串”hello”和”world”.
TCP為什么會分包
TCP是以段（Segment）為單位發(fā)送數(shù)據(jù)的,建立TCP鏈接后,有一個(gè)最大消息長度（MSS）.如果應(yīng)用層數(shù)據(jù)包超過MSS,就會把應(yīng)用層數(shù)據(jù)包拆分,分成兩個(gè)段來發(fā)送.這個(gè)時(shí)候接收端的應(yīng)用層就要拼接這兩個(gè)TCP包,才能正確處理數(shù)據(jù).
TCP為什么會粘包
有時(shí)候,TCP為了提高網(wǎng)絡(luò)的利用率,會使用一個(gè)叫做Nagle的算法.該算法是指,發(fā)送端即使有要發(fā)送的數(shù)據(jù),如果很少的話,會延遲發(fā)送.如果應(yīng)用層給TCP傳送數(shù)據(jù)很快的話,就會把兩個(gè)應(yīng)用層數(shù)據(jù)包“粘”在一起,TCP最后只發(fā)一個(gè)TCP數(shù)據(jù)包給接收端.
如何處理
在進(jìn)行TCP Socket開發(fā)時(shí),都需要處理數(shù)據(jù)包粘包和分包的情況.使用的語言是Python.實(shí)際上解決該問題很簡單,在應(yīng)用層下,定義一個(gè)協(xié)議：消息頭部+消息長度+消息正文即可.
提示:
考驗(yàn)?zāi)銓?shí)際開發(fā)中遇到的常見問題,處理方式答案:
使用netstat和awk命令來統(tǒng)計(jì)網(wǎng)絡(luò)連接數(shù)
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
TIME_WAIT：表示主動關(guān)閉,通過優(yōu)化系統(tǒng)內(nèi)核參數(shù)可容易解決.
CLOSE_WAIT：表示被動關(guān)閉,需要從程序本身出發(fā).
ESTABLISHED：表示正在通信過多CLOSE_WAIT原因
出現(xiàn)大量close_wait的現(xiàn)象,主要原因是某種情況下對方關(guān)閉了socket鏈接,但是我方忙與讀或者寫,沒有關(guān)閉連接.代碼需要判斷socket,一旦讀到0,斷開連接,read返回負(fù),檢查一下errno,如果不是AGAIN,就斷開連接.
提示:
考驗(yàn)在linux開發(fā)中,服務(wù)器端處理請求的選擇問題答案:
select和epoll這兩個(gè)機(jī)制都I/O復(fù)用的解決方案,select為POSIX標(biāo)準(zhǔn)中的,而epoll為Linux所特有.
更多查看
3.存儲
存儲可能包含rdbms,nosql以及緩存等,我以mysql,redis舉例
3.1mysql相關(guān)
提示:
在服務(wù)器建表時(shí)字符集(Character Set)和排序規(guī)則(Collation)是必不可少的,對他了解多少,如何選擇.答案:
字符集
所謂字符集,就是用來定義字符在數(shù)據(jù)庫中的編碼的集合.常見的字符集有：utf8（支持中文）和ascii（不支持中文）
排序規(guī)則
數(shù)據(jù)庫中的排序規(guī)則,就是用來定義字符在進(jìn)行排序和比較時(shí)的一種規(guī)則.常見的如下： 1.utf8_general_ci 不區(qū)分大小寫,utf8_general_cs 區(qū)分大小寫.2.utf8_bin 規(guī)定每個(gè)字符串用二進(jìn)制編碼存儲,區(qū)分大小寫,可以直接存儲二進(jìn)制的內(nèi)容
說明：所為排序規(guī)則,就是指字符比較時(shí)是否區(qū)分大小寫,以及是按照字符編碼進(jìn)行比較還是直接用二進(jìn)制數(shù)據(jù)比較.
總結(jié):這邊用
gbk_chinese_ci來做例子.
字符集名字語言后綴,其中各個(gè)典型后綴的含義如下：
1._ci：不區(qū)分大小寫的排序方式
2._cs：區(qū)分大小寫的排序方式
3._bin：二進(jìn)制排序方式,大小比較將根據(jù)字符編碼,不涉及人類語言,因此_bin的排序方式不包含人類語言
因此gbk_chinese_ci排序方式就表示：字符集為gbk,人類語言使用中文來比較大小,比較時(shí)區(qū)分大小寫.
提示:
char與varchar這兩個(gè)字符類型在mysql中經(jīng)常遇見,正確的使用,可以提高效率與避免空間上的浪費(fèi).答案:
存數(shù)據(jù)時(shí)的區(qū)別
char定義的是固定長度,長度范圍為0-255,存儲時(shí),如果字符數(shù)沒有達(dá)到定義的位數(shù),會在后面用空格補(bǔ)全存入數(shù)據(jù)庫中,在上例中,name實(shí)際存儲在數(shù)據(jù)中的數(shù)據(jù)為'zejin '
varchar是變長長度,長度范圍為0-65535,存儲時(shí),如果字符沒有達(dá)到定義的位數(shù),也不會在后面補(bǔ)空格,在上例subject字段中,實(shí)際存儲在數(shù)據(jù)中的數(shù)據(jù)為'zejin ',當(dāng)然還有一或兩個(gè)字節(jié)來描述該字節(jié)長度
取數(shù)據(jù)時(shí)的區(qū)別
數(shù)據(jù)庫取char的數(shù)據(jù)時(shí),會把后面的空格全部丟棄掉,也就是說,在char中的尾部存入空格時(shí),最后取出來都會被丟棄.而數(shù)據(jù)庫在取varchar數(shù)據(jù)時(shí),尾部空格會保留.
提示:
primary key = unique + not null答案:
Primary key與Unique Key都是唯一性約束.但二者有很大的區(qū)別：
unique Key
1.唯一鍵,一個(gè)表只能有一個(gè)PRIMARY KEY.
2.Primary key的1個(gè)或多個(gè)列 必須為NOT NULL,如果列為NULL,在增加PRIMARY KEY時(shí),列自動更改為NOT NULL.
Primary key
1.主鍵,一個(gè)表可以有多個(gè)UNIQUE KEY
2.UNIQUE KEY 對列沒有NOT NULL或NULL的特殊要求.
提示:
主要考你對表的設(shè)計(jì)與優(yōu)化.可以通過使用外鍵的優(yōu)缺點(diǎn)來分析該問題.答案:
外鍵是什么
程序很難100％保證數(shù)據(jù)的完整性,而用外鍵即使在數(shù)據(jù)庫服務(wù)器down機(jī)或者出現(xiàn)其他問題的時(shí)候,也能夠最大限度的保證數(shù)據(jù)的一致性和完整性.
是否該用外鍵
因需而定,在大型系統(tǒng)中（性能要求不高,安全要求高）,使用外鍵；在大型系統(tǒng)中（性能要求高,安全自己控制）,不用外鍵；小系統(tǒng)隨便,最好用外鍵.
外鍵是否需要索引
加入外鍵的主要問題就是影響性能,因此加入索引能加快關(guān)聯(lián)查詢的速度.
提示:
希望看到你通過對兩者區(qū)別和針對公司的業(yè)務(wù)類型來選擇合適的表類型,這樣才能發(fā)揮mysql的性能優(yōu)勢.答案:
myisam與innodb是mysql的儲引擎.
區(qū)別
1.InnoDB支持事務(wù),MyISAM不支持,對于InnoDB每一條SQL語言都默認(rèn)封裝成事務(wù),自動提交,這樣會影響速度,所以最好把多條SQL語言放在begin和commit之間,組成一個(gè)事務(wù)；
2.InnoDB支持外鍵,而MyISAM不支持.對一個(gè)包含外鍵的InnoDB表轉(zhuǎn)為MYISAM會失??；
3.InnoDB是聚集索引,數(shù)據(jù)文件是和索引綁在一起的,必須要有主鍵,通過主鍵索引效率很高.但是輔助索引需要兩次查詢,先查詢到主鍵,然后再通過主鍵查詢到數(shù)據(jù).因此,主鍵不應(yīng)該過大,因?yàn)橹麈I太大,其他索引也都會很大.而MyISAM是非聚集索引,數(shù)據(jù)文件是分離的,索引保存的是數(shù)據(jù)文件的指針.主鍵索引和輔助索引是獨(dú)立的.
4.InnoDB不保存表的具體行數(shù),執(zhí)行select count() from table時(shí)需要全表掃描.而MyISAM用一個(gè)變量保存了整個(gè)表的行數(shù),執(zhí)行上述語句時(shí)只需要讀出該變量即可,速度很快； *
5.Innodb不支持全文索引,而MyISAM支持全文索引,查詢效率上MyISAM要高；* *
選擇
1.是否要支持事務(wù),如果要請選擇innodb,如果不需要可以考慮MyISAM；
2.如果表中絕大多數(shù)都只是讀查詢,可以考慮MyISAM,如果既有讀寫也挺頻繁,請使用InnoDB.
3.系統(tǒng)奔潰后,MyISAM恢復(fù)起來更困難,能否接受；
4.MySQL5.5版本開始Innodb已經(jīng)成為Mysql的默認(rèn)引擎*(之前是MyISAM),說明其優(yōu)勢是有目共睹的,如果你不知道用什么,那就用InnoDB,至少不會差.
總結(jié)
讀操作多用MyISAM
寫操作多用InnoDB
提示:
鑒于創(chuàng)建索引需要額外的磁盤空間（,以及太多的索引會導(dǎo)致文件系統(tǒng)大小限制所產(chǎn)生的問題,所以對哪些字段建立索引,什么情況下使用索引,需要審慎考慮.答案:
*索引作用
MySQL索引在MySQL數(shù)據(jù)庫中,可以有效提高查詢的效率,尤其是查詢數(shù)據(jù)量非常大時(shí),效果更為明顯,往往能使查詢速度加快成千上萬倍.
索引原理
MySQL索引主要有一下幾種索引類型:FULLTEXT,HASH,BTREE,RTREE,對不通類型有著不通的存儲引擎,如上面提到的MyISAM,InnoDB.
使用注意
并非所有的數(shù)據(jù)庫都以相同的方式使用索引.作為通用規(guī)則,只有當(dāng)經(jīng)常查詢索引列中的數(shù)據(jù)時(shí),才需要在表上創(chuàng)建索引.索引占用磁盤空間,并且降低添加.刪除和更新行的速度.在多數(shù)情況下,索引用于數(shù)據(jù)檢索的速度優(yōu)勢大大超過它的不足之處.但是,如果應(yīng)用程序非常頻繁地更新數(shù)據(jù)或磁盤空間有限,則可能需要限制索引的數(shù)量.
3.2redis相關(guān)
提示:
不同需求不同場景有著不同選擇,一般可以redis+mysql聯(lián)用,如果可以涉及memcache,mongoDB這些no sql系列加分.答案:
redis場景
1.會話緩存（Session Cache）
用Redis緩存會話比其他存儲（如Memcached）的優(yōu)勢在于：Redis提供持久化.
2.全頁緩存（FPC）
即使重啟了Redis實(shí)例,因?yàn)橛写疟P的持久化
3.隊(duì)列
Redis作為隊(duì)列使用的操作,就類似于本地程序語言（如Python）對 list 的 push/pop 操作.
4.排行榜/計(jì)數(shù)器
集合（Set）和有序集合（Sorted Set）也使得我們在執(zhí)行這些操作的時(shí)候變的非常簡單
5.發(fā)布/訂閱
在社交網(wǎng)絡(luò)連接中使用,還可作為基于發(fā)布/訂閱的腳本觸發(fā)器,甚至用Redis的發(fā)布/訂閱功能來建立聊天系統(tǒng)
redis與mysql
這兩者是內(nèi)存和硬盤的關(guān)系,硬盤放置主體數(shù)據(jù)用于持久化存儲,而內(nèi)存則是當(dāng)前運(yùn)行的那部分?jǐn)?shù)據(jù),CPU訪問內(nèi)存而不是磁盤,這大大提升了運(yùn)行的速度,當(dāng)然這是基于程序的局部化訪問原理.
推理到redis+mysql,它是內(nèi)存+磁盤關(guān)系的一個(gè)映射,mysql放在磁盤,redis放在內(nèi)存,這樣的話,web應(yīng)用每次只訪問redis,如果沒有找到的數(shù)據(jù),才去訪問Mysql.
提示:
redis本身不處理分布式事物或者說它的事物非常弱,因?yàn)閞edis本身是單線程的.答案:
通過Redis+Lua方案,Redis的事務(wù)對處理較復(fù)雜的業(yè)務(wù)需求非常有用.
其次,Redis中實(shí)現(xiàn)事務(wù)有2種方式:
1.使用MULIT,EXEC,DISCARD和WATCH等命令;
2.使用Lua腳本封裝多個(gè)redis基本命令,來實(shí)現(xiàn)一個(gè)復(fù)雜的事務(wù)操作.
3.DISCARD指令就是用來回滾的.
提示:
需要你描述解決該問題的過程(起因-分析-排查-解決)答案:
當(dāng)內(nèi)存滿了,不允許再存數(shù)據(jù),會出現(xiàn)錯誤OOM command not allowed when used memory > ‘maxmemory’
4.安全
Web安全與我們平時(shí)開發(fā)處處關(guān)聯(lián),那么web開發(fā)需要在工作中注意哪些安全方面的問題？
<h4 id="4.1">4.1安全</h4>
提示:
對于一個(gè)有經(jīng)驗(yàn)的開發(fā)人員,代碼的書寫規(guī)范是門必修課,這里考的就是程序員對書寫sql語句中是否注意書寫規(guī)范.答案:
sql不禁是Python中需要防范的問題,在其他語言也是個(gè)必不可少的問題,這里引用PHP的防注入方案.
1.過濾掉一些常見的數(shù)據(jù)庫操作關(guān)鍵字:select,insert,update,delete,and,*等.或者通過系統(tǒng)函數(shù):addslashes(需要被過濾的內(nèi)容)來進(jìn)行過濾.
2.SQL語句書寫的時(shí)候盡量不要省略小引號(tab鍵上面那個(gè))和單引號.
3.提高數(shù)據(jù)庫命名技巧,對于一些重要的字段根據(jù)程序的特點(diǎn)命名,取不易被猜到的.
4.對于常用的方法加以封裝,避免直接暴漏SQL語句.
5.控制錯誤信息.
關(guān)閉錯誤提示信息,將錯誤信息寫到系統(tǒng)日志.
6.使用Mysqli和PDO連接mysql數(shù)據(jù)預(yù)處理.
-
xss是什么,如何預(yù)防？ - 提示:
利用django/flask都是可以防止xss攻擊的.
- 答案:
什么是XSS攻擊
XSS即跨站腳本攻擊,XSS是一種經(jīng)常出現(xiàn)在web應(yīng)用中的計(jì)算機(jī)安全漏洞,它允許惡意web用戶將代碼植入到提供給其它用戶使用的頁面中.簡單的說就是HTML注入問題.
防止XSS攻擊的兩種方式
1.對單一變量進(jìn)行轉(zhuǎn)義過濾.可以使用escape過濾器,無需轉(zhuǎn)義時(shí)使用safe過濾器
2.利用django的HTML自動轉(zhuǎn)義,無需autoescape 標(biāo)簽,django中的HTML文檔會自動轉(zhuǎn)義.
- 提示:
用 django 有多久,跟 csrf 這個(gè)概念打交道就有久. - 答案:
csrf是什么
CSRF,跨站點(diǎn)偽造請求.顧名思義,就是是偽造請求,冒充用戶在站內(nèi)的正常操作.
通過Django來防范CSRF
1.首先,最基本的原則是：GET 請求不要用有副作用.也就是說任何處理 GET 請求的代碼對資源的訪問都一定要是“只讀“的.
2.啟用django.middleware.csrf.CsrfViewMiddleware這個(gè)中間件.
3.再次,在所有的 POST 表單元素時(shí),需要加上一個(gè)csrf_token的tag.
4.在渲染模塊時(shí),使用 render.它會處理csrf_token這個(gè) tag,從而自動為表單添加一個(gè)名為csrfmiddlewaretoken的 input.
更多XSS與CSRF詳情見
4.2密碼技術(shù)
- 簡單說說https的工作原理與http的區(qū)別？
提示:
希望可以講到里面使用了哪些加密算法答案:
Https是一種基于SSL/TLS的Http協(xié)議,所有的http數(shù)據(jù)都是在SSL/TLS協(xié)議封裝之上傳輸?shù)?
Https協(xié)議在Http協(xié)議的基礎(chǔ)上,添加了SSL/TLS握手以及數(shù)據(jù)加密傳輸,也屬于應(yīng)用層協(xié)議.
1.HTTP協(xié)議運(yùn)行在TCP之上,所有傳輸?shù)膬?nèi)容都是明文,客戶端和服務(wù)器端都無法驗(yàn)證對方的身份.
2.HTTPS是運(yùn)行在SSL/TLS之上的HTTP協(xié)議,SSL/TLS運(yùn)行在TCP之上.所有傳輸?shù)膬?nèi)容都經(jīng)過加密,加密采用對稱加密,但對稱加密的密鑰用服務(wù)器方的證書進(jìn)行了非對稱加密.
- 說說https有什么優(yōu)缺點(diǎn)?
提示:
從安全與性能方向回答.答案:
優(yōu)點(diǎn)
1.使用 HTTPS 協(xié)議可認(rèn)證用戶和服務(wù)器,確保數(shù)據(jù)發(fā)送到正確的客戶機(jī)和服務(wù)器;
2.HTTPS 協(xié)議是由 SSL+HTTP 協(xié)議構(gòu)建的可進(jìn)行加密傳輸.身份認(rèn)證的網(wǎng)絡(luò)協(xié)議, 要比 http 協(xié)議安全,可防止數(shù)據(jù)在傳輸過程中不被竊取.改變,確保數(shù)據(jù)的完整性.
3.HTTPS 是現(xiàn)行架構(gòu)下最安全的解決方案,雖然不是絕對安全,但它大幅增加了中間人攻擊的成本.
缺點(diǎn)
1.HTTPS 協(xié)議的加密范圍也比較有限,在黑客攻擊.拒絕服務(wù)攻擊.服務(wù)器劫持等方 面幾乎起不到什么作用
2.HTTPS 協(xié)議還會影響緩存,增加數(shù)據(jù)開銷和功耗,甚至已有安全措施也會受到影響.
3.SSL 證書需要錢.功能越強(qiáng)大的證書費(fèi)用越高.個(gè)人網(wǎng)站.小網(wǎng)站沒有必要一般不會用.
4.HTTPS 連接服務(wù)器端資源占用高很多,握手階段比較費(fèi)時(shí)對網(wǎng)站的相應(yīng)速度有負(fù)面 影響.
5.HTTPS 連接緩存不如 HTTP 高效.
提示:
對稱加密高效不安全,非對稱加密安全不高效.答案:
對稱加密
對稱加密是指加密和解密使用的密鑰是同一個(gè)密鑰,或者可以相互推算.對稱加密的優(yōu)點(diǎn)是算法簡單,加解密效率高,系統(tǒng)開銷小,適合對大數(shù)據(jù)量加密.缺點(diǎn)是解密加密使用同一個(gè)密鑰,需要考慮遠(yuǎn)程通信的情況下如何安全的交換密鑰,如果密鑰丟失,所謂的加密解密就失效了.
非對稱加密
非對稱加密和解密使用的密鑰不是同一密鑰,其中一個(gè)對外界公開,被稱為公鑰,另一個(gè)只有所有者知道,
稱作私鑰.
用公鑰加密的信息必須用私鑰才能解開,反之,用私鑰加密的信息只有用公鑰才能解開.
5.總結(jié)
5.1新手需掌握技能點(diǎn)
- 談?wù)勓b飾器,迭代器,yield,內(nèi)存管理等
- 計(jì)算密集型,IO密集型任務(wù)怎么辦
- Tcp/Udp協(xié)議,Http協(xié)議
- sql,cache, nosql
- web安全相關(guān),sql注入,xss等
5.2老鳥需掌握技能點(diǎn)
- WSGI 和 FastCGI 的關(guān)系
- Gevent 和 threading / multiprocessing 的關(guān)系
- cookie 和 session 的關(guān)系,以及 xsrf 的攻擊和防范方法
- Django 和 Tornado 的關(guān)系.差別
- 考考數(shù)據(jù)庫知識,SQL 語法和調(diào)優(yōu),SQLAlchemy ,redis的用法
- restfull 風(fēng)格的api怎么寫
