答：javascript
HTTP是一個屬於應用層的面向對象的協議，因爲其簡捷、快速的方式，適用於分佈式超媒體信息系統。它於1990年提出，通過幾年的使用與發展，獲得不斷地完善和擴展。目前在WWW中使用的是HTTP/1.0的第六版，HTTP/1.1的規範化工做正在進行之中，並且HTTP-NG(Next Generation of HTTP)的建議已經提出。
HTTP協議的主要特色可歸納以下：
1.支持客戶/服務器模式。
2.簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法經常使用的有GET、HEAD、POST。每種方法規定了客戶與服務器聯繫的類型不一樣。因爲HTTP協議簡單，使得HTTP服務器的程序規模小，於是通訊速度很快。
3.靈活：HTTP容許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。
4.無鏈接：無鏈接的含義是限制每次鏈接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開鏈接。採用這種方式能夠節省傳輸時間。
5.無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺乏狀態意味着若是後續處理須要前面的信息，則它必須重傳，這樣可能致使每次鏈接傳送的數據量增大。另外一方面，在服務器不須要先前信息時它的應答就較快。html
答：前端
WebSocket協議支持（在受控環境中運行不受信任的代碼的）客戶端與（選擇加入該代碼的通訊的）遠程主機之間進行全雙工通訊。用於此的安全模型是Web瀏覽器經常使用的基於原始的安全模式。 協議包括一個開放的握手以及隨後的TCP層上的消息幀。 該技術的目標是爲基於瀏覽器的、須要和服務器進行雙向通訊的（服務器不能依賴於打開多個HTTP鏈接（例如，使用XMLHttpRequest或<iframe>和長輪詢））應用程序提供一種通訊機制。java
答:node
所謂魔數和魔字符串就是在代碼中直接使用某一個數字或者字符串，而不是常量。python
4.答：jquery
經過瀏覽器和設備分辨率的改變作出相應的變化ios
本質是經過 @media屬性來完成：nginx
<style>git
body{
margin:0;}
.pg-header{
height: 48px;}
@media( min-width: 768px ){
.pg-header{}}
@media( min-width: 992px ){
.pg-header{}}
</style>
1.佈局及設置meta標籤
2.經過媒體查詢來設置樣式media query
3.設置多種視圖寬度
4.字體設置
5.答：
- jQuery
- BootStrap
- Vue.js、React、Angular.js
6．答：
AJAX，Asynchronous JavaScript and XML (異步的JavaScript和XML)，一種建立交互式網頁應用的網頁開發技術方案。
異步的JavaScript：
使用 【JavaScript語言】 以及 相關【瀏覽器提供類庫】 的功能向服務端發送請求，當服務端處理完請求以後，【自動執行某個JavaScript的回調函數】。
PS：以上請求和響應的整個過程是【偷偷】進行的，頁面上無任何感知。
XML
XML是一種標記語言，是Ajax在和後臺交互時傳輸數據的格式之一
利用AJAX能夠作：
一、註冊時，輸入用戶名自動檢測用戶是否已經存在。
二、登錄時，提示用戶名密碼錯誤
三、刪除數據行時，將行ID發送到後臺，後臺在數據庫中刪除，數據庫刪除成功後，在頁面DOM中將數據行也刪除。（博客園）
<!DOCTYPE html>
<html>
<head lang="en">
<meta charset="UTF-8">
<title></title>
</head>
<body>
<p>
<input type="button" onclick="XmlSendRequest();" value='Ajax請求' />
</p>
<script type="text/javascript" src="jquery-1.12.4.js"></script>
<script>
function JqSendRequest(){
$.ajax({
url: "http://c2.com:8000/test/",
type: 'GET',
dataType: 'text',
success: function(data, statusText, xmlHttpRequest){
console.log(data);
}
})
}
</script>
</body>
</html>
基於jQueryAjax - Demo
7.答：
輪詢
輪詢是在特定的的時間間隔（如每1秒），由瀏覽器對服務器發出HTTP request，而後由服務器返回最新的數據給客戶端的瀏覽器。這種傳統的HTTP request 的模式帶來很明顯的缺點 – 瀏覽器須要不斷的向服務器發出請求，然而HTTP request 的header是很是長的，裏面包含的有用數據可能只是一個很小的值，這樣會佔用不少的帶寬。
var xhr = new XMLHttpRequest();
setInterval(function(){
xhr.open('GET','/user');
xhr.onreadystatechange = function(){
};
xhr.send();
},1000)
8. 答：
ajax實現:在發送ajax後,服務器端會阻塞請求直到有數據傳遞或超時才返回。 客戶端JavaScript響應處理函數會在處理完服務器返回的信息後，再次發出請求，從新創建鏈接。
function ajax(){
var xhr = new XMLHttpRequest();
xhr.open('GET','/user');
xhr.onreadystatechange = function(){
ajax();
};
xhr.send();
}
9.答：
它採用集中式存儲管理應用的全部組件的狀態，並以相應的規則保證狀態以一種可預測的方式發生變化。
10.答：
在每次http的請求響應以後，若是設置了攔截器以下，會優先執行攔截器函數，獲取響應體，而後纔會決定是否把response返回給then進行接收。那麼咱們能夠在這個攔截器裏邊添加對響應狀態碼的判斷，來決定是跳轉到登陸頁面仍是留在當前頁面繼續獲取數據。
11. 答：
Axios的特色
從瀏覽器中建立 XMLHttpRequests
從 node.js 建立 http 請求
支持 Promise API
攔截請求和響應 （就是有interceptor）
轉換請求數據和響應數據
取消請求
自動轉換 JSON 數據
客戶端支持防護 XSRF
12. 答：
v-if//v-show//v-else//v-for//v-bind//v-on
13.答：
JSONP原理：
首先在客戶端註冊一個callback, 而後把callback的名字傳給服務器。
此時，服務器先生成 json 數據。
而後以 javascript 語法的方式，生成一個function , function 名字就是傳遞上來的參數 jsonp.
最後將 json 數據直接以入參的方式，放置到 function 中，這樣就生成了一段 js 語法的文檔，返回給客戶端。
客戶端瀏覽器，解析script標籤，並執行返回的 javascript 文檔，此時數據做爲參數，傳入到了客戶端預先定義好的 callback 函數裏.（動態執行回調函數）
14. 答：
Cross-Origin Resource Sharing（CORS）跨域資源共享是一份瀏覽器技術的規範，提供了 Web 服務從不一樣域傳來沙盒腳本的方法，以避開瀏覽器的同源策略，是 JSONP 模式的現代版。與 JSONP 不一樣，CORS 除了 GET 要求方法之外也支持其餘的 HTTP 要求。用 CORS 可讓網頁設計師用通常的 XMLHttpRequest，這種方式的錯誤處理比 JSONP 要來的好。另外一方面，JSONP 能夠在不支持 CORS 的老舊瀏覽器上運做。現代的瀏覽器都支持 CORS。
15．答：
GET： 用於請求訪問已經被URI（統一資源標識符）識別的資源，能夠經過URL傳參給服務器
POST：用於傳輸信息給服務器，主要功能與GET方法相似，但通常推薦使用POST方式。
PUT： 傳輸文件，報文主體中包含文件內容，保存到對應URI位置。
HEAD： 得到報文首部，與GET方法相似，只是不返回報文主體，通常用於驗證URI是否有效。
DELETE：刪除文件，與PUT方法相反，刪除對應URI位置的文件。
OPTIONS：查詢相應URI支持的HTTP方法。
16.答：
200：請求被正常處理
204：請求被受理但沒有資源能夠返回
206：客戶端只是請求資源的一部分，服務器只對請求的部分資源執行GET方法，相應報文中經過Content-Range指定範圍的資源。
301：永久性重定向
302：臨時重定向
303：與302狀態碼有類似功能，只是它但願客戶端在請求一個URI的時候，能經過GET方法重定向到另外一個URI上
304：發送附帶條件的請求時，條件不知足時返回，與重定向無關
307：臨時重定向，與302相似，只是強制要求使用POST方法
400：請求報文語法有誤，服務器沒法識別
401：請求須要認證
403：請求的對應資源禁止被訪問
404：服務器沒法找到對應資源
500：服務器內部錯誤
503：服務器正忙
17.答：
1. 通用首部字段（請求報文與響應報文都會使用的首部字段）
- Date：建立報文時間
- Connection：鏈接的管理
- Cache-Control：緩存的控制
- Transfer-Encoding：報文主體的傳輸編碼方式
2. 請求首部字段（請求報文會使用的首部字段）
- Host：請求資源所在服務器
- Accept：可處理的媒體類型
- Accept-Charset：可接收的字符集
- Accept-Encoding：可接受的內容編碼
- Accept-Language：可接受的天然語言
3. 響應首部字段（響應報文會使用的首部字段）
- Accept-Ranges：可接受的字節範圍
- Location：令客戶端從新定向到的URI
- Server：HTTP服務器的安裝信息
4. 實體首部字段（請求報文與響應報文的的實體部分使用的首部字段）
- Allow：資源可支持的HTTP方法
- Content-Type：實體主類的類型
- Content-Encoding：實體主體適用的編碼方式
- Content-Length：實體主體的的字節數
- Content-Range：實體主體的位置範圍，通常用於發出部分請求時使用
18.答：李傑
19.答：武沛齊
20.答：老男孩
21.答：undefined
22.答: 武沛齊
23.答：ALEX
24.答：
1、對外數據接口
三者做爲web框架，都是經過url映射對外的接口
flask：以decorator的形式，映射到函數中
django：以字典形式，映射到函數
tornado: 以字典形式，映射到類中
flask的接口散落在整個app文件中，多了的話，稍微不易於管理；django單獨集中在url.py文件中，挺好。
對於接口簡單（如cms系統），映射到函數，簡單明瞭；對於複雜的接口（富應用的web app），映射到類，更適合面向對象編程。
2、可擴展性
flask：做爲微型框架，它能夠自由組配外部功能模塊，如orm、template機制等
django：做爲大而全框架，它幾乎不可能組配其餘外部功能模塊，可是能夠增長豐富它的Middlerware/contrib等
tornado：接近flask
3、代碼層次結構
做爲framwork，三者的架構基本都是一個callable的App類爲核心，
django對使用者，呈現的是mvc結構。比較符合如今的主流。固然flask/tornado都容易作到mvc，只是額外增長工做量。
4、開發效率
flask：因爲它協助完成功能不多，除非是小型應用，不然它開發效率比較大
django：大而全的框架，完成了session/orm/等。若是考慮安全性在內，對於通常網站，它的開發效率是很是高的。
tornado：介於flask、django之間。因爲沒有session機制，因此開發效率也不低。但它原生實現了websocket，因此對於開發須要不少長鏈接的web應用，會比較快。
5、併發能力
flask：內容不多，對於大應用，性能如何，很大程度看後面人員如何擴展
django：因爲代碼量大，並且又是同步的，因此抗壓能力很弱
tornado：異步框架，性能相對好
實際上，生產時候，都是把framework經過nginx/gevent部署，而tornado對於前面兩者來講，併發性能也沒有優點。
整體而言：
flask適合用於小型應用開發；若是開發團隊能力強，也能夠用來作大中型應用
django適合應用用於訪問量不大的大中型應用
tornado適合用於開發長鏈接多的web應用。好比股票信息推送、網絡聊天等。
25.答：
是web服務網關接口，是一套協議。如下模塊實現了wsgi協議：
- wsgiref ：性能低，易配置
- werkzurg
- uwsgi
以上模塊本質：實現socket監聽請求，獲取請求後將數據封裝，而後交給web框架處理
詳解：
本質是編寫了socket服務端，用來監聽用戶的請求，若是有請求到來，則將請求進行一次封裝而後將【請求】交給web框架來進行下一步處理
26.答：
1. 當用戶在瀏覽器中輸入url時,瀏覽器會生成請求頭和請求體發給服務端 請求頭和請求體中會包含瀏覽器的動做(action),這個動做一般爲get或者post,體如今url之中.
2. url通過Django中的wsgi,再通過Django的中間件,最後url到過路由映射表,在路由中一條一條進行匹配, 一旦其中一條匹配成功就執行對應的視圖函數,後面的路由就再也不繼續匹配了.
3. 視圖函數根據客戶端的請求查詢相應的數據.返回給Django,而後Django把客戶端想要的數據作爲一個字符串返回給客戶端.
4. 客戶端瀏覽器接收到返回的數據,通過渲染後顯示給用戶.
27.答：model form,form,admin ,view,middleware.
28.答：
django 中的中間件（middleware），在django中，中間件其實就是一個類，在請求到來和結束後，django會根據本身的規則在合適的時機執行中間件中相應的方法。
中間件中能夠定義五個方法，分別是：
process_request(self,request)
process_view(self, request, callback, callback_args, callback_kwargs)
process_template_response(self,request,response)
process_exception(self, request, exception)
process_response(self, request, response)
29.答：
FBV（function base views） 就是在視圖裏使用函數處理請求。
CBV（class base views） 就是在視圖裏使用類處理請求。
30.答：
當請求一個頁面時，Django會創建一個包含請求元數據的HttpRequest對象。當Django加載對應的視圖的時候，HttpRequest對象將做爲視圖函數的第一個參數。每一個視圖會返回一個HttpResponse對象。
31.答：
#在用戶認證時的一個應用
裝飾器：
FBV：
def auth(func):
def inner(reqeust,*args,**kwargs):
v = reqeust.COOKIES.get('user')
if not v:
return redirect('/login')
return func(reqeust, *args,**kwargs)
return inner
CBV:
from django import views
from django.utils.decorators import method_decorator
@method_decorator(auth, name='dispatch') #也能夠寫到類上, 這樣在get,post請求均可以省略， 也能夠寫在類裏面方法上
class Order(views.View):
#@method_decorator(auth)
#def dispatch(self, request, *args, **kwargs):
#return super(Order, self).dispatch(request, *args, **kwargs)
#@method_decorator(auth): #只對get請求有效
def get(self, request):
v = request.COOKIE.get('username')
return render(request, 'index.html', {'current_user': v })
def post(self, request):
v = request.COOKIE.get('username')
return render(request, 'index.html', {'current_user': v })
32．答：
def orm(request):
orm2添加一條記錄的方法
單表
一、表.objects.create（）
models.Publish.objects.create(name='浙江出版社',addr="浙江.杭州")
models.Classify.objects.create(category='武俠')
models.Author.objects.create(name='金庸',sex='男',age=89,university='東吳大學')
二、類實例化：obj=類（屬性=XX） obj.save()
obj=models.Author(name='吳承恩',age=518,sex='男',university='龍溪學院')
obj.save()
1對多
一、表.objects.create()
models.Book.objects.create(title='笑傲江湖',price=200,date=1968,classify_id=6, publish_id=6)
二、類實例化：obj=類（屬性=X,外鍵=obj）obj.save()
classify_obj=models.Classify.objects.get(category='武俠')
publish_obj=models.Publish.objects.get(name='河北出版社')
注意以上獲取得是和 book對象 向關聯的（外鍵）的對象
book_obj=models.Book(title='西遊記',price=234,date=1556,classify=classify_obj,publish=publish_obj)
book_obj.save()
多對多
若是兩表之間存在雙向1對N關係，就沒法使用外鍵來描述其關係了；
只能使用多對多的方式，新增第三張表關係描述表；
book=models.Book.objects.get(title='笑傲江湖')
author1=models.Author.objects.get(name='金庸')
author2=models.Author.objects.get(name='張根')
book.author.add(author1,author2)
書籍和做者是多對多關係，
切記：若是兩表之間存在多對多關係，例如書籍相關的全部做者對象集合，做者也關聯的全部書籍對象集合
book=models.Book.objects.get(title='西遊記')
author=models.Author.objects.get(name='吳承恩')
author2 = models.Author.objects.get(name='張根')
book.author.add(author,author2)
#add() 添加
#clear() 清空
#remove() 刪除某個對象
return HttpResponse('OK')
改：
# 修改方式1 update()
models.Book.objects.filter(id=1).update(price=3)
#修改方式2 obj.save()
book_obj=models.Book.objects.get(id=1)
book_obj.price=5
book_obj.save()
查：def ormquery(request):
books=models.Book.objects.all() #------query_set對象集合 [對象一、對象二、.... ]
books=models.Book.objects.filter(id__gt=2,price__lt=100)
book=models.Book.objects.get(title__endswith='金') #---------單個對象，沒有找到會報錯
book1 = models.Book.objects.filter(title__endswith='金').first()
book2 = models.Book.objects.filter(title__icontains='瓶').last()
books=models.Book.objects.values('title','price', #-------query_set字典集合 [{一條記錄},{一條記錄} ]
'publish__name',
'date',
'classify__category', #切記 正向連表:外鍵字段___對應表字段
'author__name', #反向連表： 小寫表名__對應表字段
'author__sex', #區別：正向 外鍵字段__，反向 小寫表名__
'author__age',
'author__university')
books=models.Book.objects.values('title','publish__name').distinct()
#exclude 按條件排除。。。
#distinct()去重, exits()查看數據是否存在？ 返回 true 和false
a=models.Book.objects.filter(title__icontains='金').
return HttpResponse('OK')
反向連表查詢：
一、經過object的形式反向連表， obj.小寫表名_set.all()
publish=models.Publish.objects.filter(name__contains='湖南').first()
books=publish.book_set.all()
for book in books:
print(book.title)
經過object的形式反向綁定外鍵關係
authorobj = models.Author.objects.filter(id=1).first()
objects = models.Book.objects.all()
authorobj.book_set.add(*objects)
authorobj.save()
二、經過values雙下滑線的形式，objs.values("小寫表名__字段")
注意對象集合調用values（），正向查詢是外鍵字段__XX,而反向是小寫表名__YY看起來比較容易混淆；
books=models.Publish.objects.filter(name__contains='湖南').values('name','book__title')
authors=models.Book.objects.filter(title__icontains='個人').values('author__name')
print(authors)
fifter()也支持__小寫表名語法進行連表查詢：在publish標查詢 出版過《笑傲江湖》的出版社
publishs=models.Publish.objects.filter(book__title='笑傲江湖').values('name')
print(publishs)
查詢誰（哪位做者）出版過的書價格大於200元
authors=models.Author.objects.filter(book__price__gt=200).values('name')
print(authors)
經過外鍵字段正向連表查詢，出版自保定的書籍；
city=models.Book.objects.filter(publish__addr__icontains='保定').values('title')
print(city)
etc.
33.答：
暫時阻擋，稍後可再繼續進行。
決定延期至適當日子
34.答：
select_related()的效率要高於prefetch_related()。所以，最好在能用select_related()的地方儘可能使用它，也就是說，對於ForeignKey字段，避免使用prefetch_related()。
1.prefetch_related主要針一對多和多對多關係進行優化。
2.prefetch_related經過分別獲取各個表的內容，而後用Python處理他們之間的關係來進行優化。
3.能夠經過可變長參數指定須要select_related的字段名。指定方式和特徵與select_related是相同的。
4.在Django >= 1.7能夠經過Prefetch對象來實現複雜查詢，但低版本的Django好像只能本身實現。
5.做爲prefetch_related的參數，Prefetch對象和字符串能夠混用。
6.prefetch_related的鏈式調用會將對應的prefetch添加進去，而非替換，彷佛沒有基於不一樣版本上區別。
7.能夠經過傳入None來清空以前的prefetch_related。
select_related主要針一對一和多對一關係進行優化。
2.select_related使用SQL的JOIN語句進行優化，經過減小SQL查詢的次數來進行優化、提升性能。
3.能夠經過可變長參數指定須要select_related的字段名。也能夠經過使用雙下劃線「__」鏈接字段名來實現指定的遞歸查詢。沒有指定的字段不會緩存，沒有指定的深度不會緩存，若是要訪問的話Django會再次進行SQL查詢。
4.也能夠經過depth參數指定遞歸的深度，Django會自動緩存指定深度內全部的字段。若是要訪問指定深度外的字段，Django會再次進行SQL查詢。
5.也接受無參數的調用，Django會盡量深的遞歸查詢全部的字段。但注意有Django遞歸的限制和性能的浪費。
6.Django >= 1.7，鏈式調用的select_related至關於使用可變長參數。Django < 1.7，鏈式調用會致使前邊的select_related失效，只保留最後一個。
35. 略
36.答：
手動讀寫分離
在使用數據庫時，經過.using(db_name)來手動指定要使用的數據庫
自動讀寫分離
經過配置數據庫路由，來自動實現，這樣就不須要每次讀寫都手動指定數據庫了。數據庫路由中提供了四個方法。這裏這裏主要用其中的兩個：def db_for_read()決定讀操做的數據庫，def db_for_write()決定寫操做的數據庫。
37.答：
Orm操做便可
38. 答：
F做用：操做數據表中的某列值，F（）容許Django在未實際連接數據的狀況下具備對數據庫字段值的引用，不用獲取對象放在內存中再對字段進行操做，直接執行原生產sql語句操做。
Q做用：對對象進行復雜查詢，並支持&（and）,|（or），~（not）操做符。
39.答：
values方法能夠獲取number字段的字典列表。
values_list能夠獲取number的元組列表。
values_list方法加個參數flat=True能夠獲取number的值列表。
40.答：
數據模型定義
首先，定義一個實例使用的django數據庫模型Product，只是象徵性地定義了兩個字段name和price。
from django.db import models
class Product(models.Model):
name = models.CharField(max_length=200)
price = models.DecimalField(max_digits=10, decimal_places=2)
批量插入數據
批量插入數據時，只需先生成個一要傳入的Product數據的列表，而後調用bulk_create方法一次性將列表中的數據插入數據庫。
product_list_to_insert = list()
for x in range(10):
product_list_to_insert.append(Product(name='product name ' + str(x), price=x))
Product.objects.bulk_create(product_list_to_insert)
批量更新數據
批量更新數據時，先進行數據過濾，而後再調用update方法進行一次性地更新。下面的語句將生成相似update...where...的SQL語句。
Product.objects.filter(name__contains='name').update(name='new name')
批量刪除數據
批量更新數據時，先是進行數據過濾，而後再調用delete方法進行一次性地刪除。下面的語句將生成相似delete from...where...的SQL語句。
Product.objects.filter(name__contains='name query').delete()
41.答：
Django中Model負責操做數據庫，而且具備簡單的數據庫驗證功能（基本不用）；Form用於用戶請求的驗證，具備強悍的數據庫驗證功能；ModelForm是將兩者合二爲一，便可用於數據庫操做（部分），也可用於用戶請求的驗證（部分）！但因爲ModelForm的耦合性太強，其做用通常用做於結構簡單的小站點或者重寫Django Admin
42.答：略
43.答：
對於外鍵，刪除是是默認爲級聯刪除，當刪除一個，對應相關數據也會被刪除，因此，咱們有時候須要修改這一性質，在建立外鍵是使用on_delete便可
44.答：
目標：防止用戶直接向服務端發起POST請求。
方案：先發送GET請求時，將token保存到：cookie、Form表單中（隱藏的input標籤），之後再發送請求時只要攜帶過來便可。
問題：若是想後臺發送POST請求？
form表單提交：
<form method="POST">
{% csrf_token %}
<input type='text' name='user' />
<input type='submit' />
</form>
ajax提交：
$.ajax({
url:'/index',
type:'POST',
data:{csrfmiddlewaretoken:'{{ csrf_token }}',name:'alex'}
})
前提：引入jquery + 引入jquery.cookie
$.ajax({
url: 'xx',
type:'POST',
data:{name:'oldboyedu'},
headers:{
X-CSRFToken: $.cookie('csrftoken')
},
dataType:'json', // arg = JSON.parse('{"k1":123}')
success:function(arg){
console.log(arg)
}
})
45.答：Django channels。
46.答：
在視圖中使用 render （而不要使用 render_to_response）
使用 jQuery 的 ajax 或者 post 以前 加入這個 js 代碼
47.答：
一、在models文件中生成類，來生成表
二、在view中導入app01的models文件
三、在urls中創建orm的路由
四、在view中創建orm的視圖函數
五、引用models.UserInfo(表名稱).objects.create（對應的錶行關係）
六、選填給在頁面作出反應
48.答：
Django settings 中 cache 默認爲
| 1 2 3 4 5 |
{ 'default': { 'BACKEND': 'django.core.cache.backends.locmem.LocMemCache', } } |
也就是默認利用本地的內存來當緩存，速度很快
49.答：
from django.conf import settings
from django.core.cache import cache
#read cache user id
def read_from_cache(self, user_name):
key = 'user_id_of_'+user_name
value = cache.get(key)
if value == None:
data = None
else:
data = json.loads(value)
return data
#write cache user id
def write_to_cache(self, user_name):
key = 'user_id_of_'+user_name
cache.set(key, json.dumps(user_name), settings.NEVER_REDIS_TIMEOUT)
50.答：
相似給url取一個別名。
51.答：
Filter能夠在控制語句中使用，而simple_tag不能
52.答：
爲Django提供調試功能。
53.答：
Django的單元測試使用python的unittest模塊，這個模塊使用基於類的方法來定義測試。類名爲django.test.TestCase,繼承於python的unittest.TestCase。
執行目錄下全部的測試(全部的test*.py文件)：運行測試的時候，測試程序會在全部以test開頭的文件中查找全部的test cases(inittest.TestCase的子類),自動創建測試集而後運行測試。
54.答：
Database First是基於已存在的數據庫，利用某些工具（如VS提供的EF設計器）建立實體類，數據庫對象與實體類的匹配關係等，你也能夠手動修改這些自動生成的代碼及匹配文件。也就是從一個數據庫開始，而後生成實體框架和相應代碼。
Code First 這種方式須要先寫一些代碼，如實體對象，數據關係等，而後根據已有的代碼描述，自動建立數據對象。但其實這種方法與Model First是很是相似的。咱們本身寫的代碼，其實就是用代碼表示實體模型，而Model First是用可視化的方式描述了實體模型。
55.答：python manage.py makemigrations
56.答：
1）提升開發效率，下降開發成本
2）使開發更加對象化
3）可移植
4）能夠很方便地引入數據緩存之類的附加功能
缺點：
1）自動化進行關係數據庫的映射須要消耗系統性能。其實這裏的性能消耗還好啦，通常來講均可以忽略之。
2）在處理多表聯查、where條件複雜之類的查詢時，ORM的語法會變得複雜。
57．答：
MVC:Model 表明數據存取層，View 表明的是系統中選擇顯示什麼和怎麼顯示的部分，Controller 指的是系統中根據用戶輸入並視須要訪問模型，以決定使用哪一個視圖的那部分。
如下是 Django 中 M、V 和 C 各自的含義：
M ，數據存取部分，由django數據庫層處理，本章要講述的內容。
V ，選擇顯示哪些數據要顯示以及怎樣顯示的部分，由視圖和模板處理。
C ，根據用戶輸入委派視圖的部分，由 Django 框架根據 URLconf 設置，對給定 URL 調用適當的 Python 函數。
C 是由框架自行處理，而 Django 裏更關注的是模型（Model）、模板(Template)和視圖（Views）， Django 也被稱爲 MTV 框架 。在 MTV 開發模式中：
M 表明模型（Model），即數據存取層。 該層處理與數據相關的全部事務： 如何存取、如何驗證有效
T 表明模板(Template)，即表現層。 該層處理與表現相關的決定： 如何在頁面或其餘類型文檔中進行顯示。
V 表明視圖（View），即業務邏輯層。 該層包含存取模型及調取恰當模板的相關邏輯。 你能夠把它看做模型與模板之間的橋樑。
58.答：
contenttypes 是Django內置的一個應用，能夠追蹤項目中全部app和model的對應關係，並記錄在ContentType表中。、
59.答：
REST（Representational State Transfer）表述性狀態轉換，REST指的是一組架構約束條件和原則。 若是一個架構符合REST的約束條件和原則，咱們就稱它爲RESTful架構。REST自己並無創造新的技術、組件或服務，而隱藏在RESTful背後的理念就是使用Web的現有特徵和能力， 更好地使用現有Web標準中的一些準則和約束。雖然REST自己受Web技術的影響很深， 可是理論上REST架構風格並非綁定在HTTP上，只不過目前HTTP是惟一與REST相關的實例。
60.答：
接口的冪等性實際上就是接口可重複調用，在調用方屢次調用的狀況下，接口最終獲得的結果是一致的。
61.答：
遠程過程調用 (RPC) 是一種協議，程序可以使用這種協議向網絡中的另外一臺計算機上的程序請求服務。因爲使用 RPC 的程序沒必要了解支持通訊的網絡協議的狀況，所以 RPC 提升了程序的互操做性。在 RPC 中，發出請求的程序是客戶程序，而提供服務的程序是服務器。
RPC（遠程過程調用）是一項普遍用於支持分佈式應用程序（不一樣組件分佈在不一樣計算機上的應用程序）的技術。RPC 的主要目的是爲組件提供一種相互通訊的方式，使這些組件之間可以相互發出請求並傳遞這些請求的結果。
62．答：
對傳輸內容加密
端口：
HTTP：80
HTTPS：443
自定義證書
1. 通訊使用明文不加密，內容可能被竊聽
2. 不驗證通訊方身份，可能遭到假裝
3. 沒法驗證報文完整性，可能被篡改
# HTTPS就是HTTP加上加密處理（通常是SSL安全通訊線路）+認證+完整性保護
63.答：
方便開發 RESTful 模式接口的，內部給你分離了 HTTP Verbs，仍是比較方便的默認也有無狀態的訪問權限管理。
64.答：
快速實例，序列化。
65.答：
使用混合類組建視圖。
66.答：
67.答：
http://www.javashuo.com/article/p-qhazsxpt-he.html
68．答：
flask框架中的上下文管理較爲耀眼。第三方組件不少，可擴展性強，還能夠自定義組件
69．答：
設置一個requirements.txt文件
70.答：
一個藍圖定義了可用於單個應用的視圖，模板，靜態文件等等的集合。儘量將代碼儘可能的模塊化，是代碼看起來更加優雅和流暢。
71.答：
- 內置組件
- 配置 - 路由 - 視圖
- 模板 - session - 藍圖
- 閃現 - 裝飾器 - 中間件
- 第三方組件
- Flask-session # 將原來保存在cookie中的session數據，放到Redis/memcache/文件/數據庫中
- Flask-migrate # 作數據庫遷移
- Flask-script #
- Flask-SQLAlchemy # ORM
- blinker
- 公共：
- DButils # 數據庫鏈接池： 兩種模式； 爲每一個參數設置一個鏈接/共享一個鏈接；全局參數
- wtforms # form組件：作表單驗證+生成HTML標籤
- gevent-websocket
- 自定義組件：
- flask-login
72.答：
簡單來講，falsk上下文管理能夠分爲三個階段：
一、請求進來時，將請求相關的數據放入上下文管理中
二、在視圖函數中，要去上下文管理中取值
三、請求響應，要將上下文管理中的數據清除
詳細點來講：
一、請求剛進來，將request，session封裝在RequestContext類中，app，g封裝在AppContext類中，並經過LocalStack將requestcontext和appcontext放入Local類中
二、視圖函數中，經過localproxy--->偏函數--->localstack--->local取值
三、請求相應時，先執行save.session()再各自執行pop(),將local中的數據清除
73.答：
- G 至關於一次請求的全局變量，當請求進來時將 G 和 current_app 封裝爲一個 APPContext 類，在經過 LocalStack 將 Appcontext 放入 Local 中，
取值時經過偏函數，LocalStack、loca 中取值，響應時將 Local 中的 g 數據刪除：
- 應用場景：
befor_request + G = 權限認證系統
74.答：
一、每個線程都會在Local類中建立一條數據
｛
「惟一標識」:{stark:[ctx,]}
「惟一標識」:{stark:[ctx,]}
｝
二、當請求進來以後，將請求相關數據添加到列表裏面[request，]，之後若是使用時，就去讀取
三、列表中的數據，請求完成以後，將request從列表中移除
二、在源碼中分析上下文管理
第一階段：執行__call__--->app.wsgi-->將ctx（request,session）封裝爲RequestContent()在（open_session）, app_ctx(g,app)封裝爲APPContent()經過LocalStack將這兩個類放入Local對象中
第二階段：視圖函數導入：request/session/g/app ,經過偏函數(_lookup_req_object)在經過（LocalProxy()）去LocalStack中的Local類中對其進行增刪改查操做
第三階段：請求處理完畢
- 經過save_session將簽名session保存到cookie
-經過ctx.pop()去LocalStack中的Local類- 將ctx刪除
75.答：
-保存 請求上下文對象和app上下文對象
-localstack的源碼與threading.local（線程處理）做用類似，不一樣之處是Local是經過greenlet（協程）獲取惟一標識，粒度更細
將local對象中的數據維護成一個棧【ctx,ctx】（先進後出）
{
「協程或線程的惟一標識」: { stack:[ctx,ctx,ctx,] }
}
76.答：
請求上下文管理的方式實現的。
77.答：
Flask-socketio模塊。
78.答：
主要用於對用戶請求數據進行驗證
79.答：
當請求進來時，會將 requset 和 session 封裝爲一個 RequestContext 對象，經過 LocalStack 將 RequestContext 放入到Local對象中，
由於請求第一次來 session 是空值，因此執行 open_session,給 session（uuid4()）賦值，再經過視圖函數處理，請求響應時執行save.session,
將簽名 session 寫入 cookie 中，再將 Local 中的數值pop掉。
80.答：
Flask的session默認是徹底保留在客戶端瀏覽器中的，也就是說我往flask的session中寫入數據，最終這些數據將會以json字符串的形式，通過base64編碼寫入到用戶瀏覽器的cookie裏，也就是說無須依賴第三方數據庫保存 session數據，也無需依賴文件來保存
81.答：
業務解耦，經過blinker提供信號支持。
82.答：
而使用scoped_session的目的主要是爲了線程安全。
scoped_session相似單例模式，當咱們調用使用的時候，會先在Registry裏找找以前是否已經建立session了。
要是有，就把這個session返回。
要是沒有，就建立新的session，註冊到Registry中以便下次返回給調用者。
這樣就實現了這樣一個目的：在同一個線程中，call scoped_session 的時候，返回的是同一個對象：
83.答：
方式1, 使用raw sql;
方式2, 使用SqlAlchemy的sql expression;
方式3, 使用ORM.
84.答：
將關係數據庫中的表映射爲對象，從而將對數據庫的操做轉化爲對對象的操做。
85.答：
DBUtils 屬於WebWare項目的數據庫鏈接池實現模塊，用於對數據庫鏈接線程化，使能夠安全和有效的訪問數據庫的模塊
86.答:
不正確。
87.答：
設置引擎編碼方式爲utf-8
設置數據庫編碼發方式爲utf8
88.答：
UniqueConstraint(‘id’, ‘name’,name= ‘uix_id_name)
89.答：
Tornado在設計之初就考慮到了性能因素，旨在解決C10K問題，這樣的設計使得其成爲一個擁有很是高性能的框架。此外，它還擁有處理安全性、用戶驗證、社交網絡以及與外部服務（如數據庫和網站API）進行異步交互的工具。
90.答：
內置的一個回調函數以及建立task。
91.答:
Tornado在websocket模塊中提供了一個WebSocketHandler類。這個類提供了和已鏈接的客戶端通訊的WebSocket事件和方法的鉤子。當一個新的WebSocket鏈接打開時，open方法被調用，而on_message和on_close方法分別在鏈接接收到新的消息和客戶端關閉時被調用。
此外，WebSocketHandler類還提供了write_message方法用於向客戶端發送消息，close方法用於關閉鏈接。
92. 答：
在tornado中，處理靜態文件的類StaticFileHandler，在web.py模塊中，該類不只處理靜態文件的映射也處理了靜態文件的主動式緩存。
處理靜態文件時須要設置settings中關於靜態文件的值」static_ ath「，指明靜態文件的路徑。
93.答：
TornDB是一個輕量級的基於MySQLdb封裝的一個模塊
94.答：
tornado 可用的異步 redis 客戶端，使用很方便。
下面的例子介紹了怎麼使用管道設置值和讀取值的簡單操做
#coding:utf-8
import tornadoredis
import tornado.httpserver
import tornado.web
import tornado.ioloop
import tornado.gen
#設置鏈接池
CONNECTION_POOL = tornadoredis.ConnectionPool(max_connections=500,wait_for_available=True)
# 生成一個客戶端，這裏並無給出host和port，使用的默認的參數，個人redis使用默認的參數也能夠鏈接上
# Client的參數爲
# def __init__(self, host='localhost', port=6379, unix_socket_path=None,
# password=None, selected_db=None, io_loop=None,
# connection_pool=None):
c = tornadoredis.Client(connection_pool=CONNECTION_POOL)
class MainHandler(tornado.web.RequestHandler):
@tornado.web.asynchronous
@tornado.gen.engine
def get(self):
name = yield tornado.gen.Task(c.get,'name')
age = yield tornado.gen.Task(c.get,'age')
height = yield tornado.gen.Task(c.get,'height')
self.finish("name: {0} age: {1} height: {2}".format(name, age, height))
application = tornado.web.Application([
(r'/', MainHandler),
])
@tornado.gen.engine
def create_test_data():
c = tornadoredis.Client()
# 使用管道設置值
with c.pipeline() as pipe:
pipe.set('name', 'zhangsan')
pipe.set('age', '10')
pipe.set('height', '1.8')
yield tornado.gen.Task(pipe.execute)
if __name__ == '__main__':
# Start the data initialization routine
create_test_data()
http_server = tornado.httpserver.HTTPServer(application)
http_server.listen(8888)
print 'Demo is runing at 0.0.0.0:8888\nQuit the demo with CONTROL-C'
tornado.ioloop.IOLoop.instance().start()
95.答：
高併發，異步非阻塞，便是服務器又是框架，性能優越，速度快。
96.答：
git init
在本地新建一個repo,進入一個項目目錄,執行git init,會初始化一個repo,並在當前文件夾下建立一個.git文件夾.
git clone
獲取一個url對應的遠程Git repo, 建立一個local copy.
通常的格式是git clone [url].
clone下來的repo會以url最後一個斜線後面的名稱命名,建立一個文件夾,若是想要指定特定的名稱,能夠git clone [url] newname指定.
git status
查詢repo的狀態.
git status -s: -s表示short, -s的輸出標記會有兩列,第一列是對staging區域而言,第二列是對working目錄而言.
git log
show commit history of a branch.
git log --oneline --number: 每條log只顯示一行,顯示number條.
git log --oneline --graph:能夠圖形化地表示出分支合併歷史.
git log branchname能夠顯示特定分支的log.
git log --oneline branch1 ^branch2,能夠查看在分支1,卻不在分支2中的提交.^表示排除這個分支(Window下可能要給^branch2加上引號).
git log --decorate會顯示出tag信息.
git log --author=[author name] 能夠指定做者的提交歷史.
git log --since --before --until --after 根據提交時間篩選log.
--no-merges能夠將merge的commits排除在外.
git log --grep 根據commit信息過濾log: git log --grep=keywords
默認狀況下, git log --grep --author是OR的關係,即知足一條即被返回,若是你想讓它們是AND的關係,能夠加上--all-match的option.
git log -S: filter by introduced diff.
好比: git log -SmethodName (注意S和後面的詞之間沒有等號分隔).
git log -p: show patch introduced at each commit.
每個提交都是一個快照(snapshot),Git會把每次提交的diff計算出來,做爲一個patch顯示給你看.
另外一種方法是git show [SHA].
git log --stat: show diffstat of changes introduced at each commit.
一樣是用來看改動的相對信息的,--stat比-p的輸出更簡單一些.
git add
在提交以前,Git有一個暫存區(staging area),能夠放入新添加的文件或者加入新的改動. commit時提交的改動是上一次加入到staging area中的改動,而不是咱們disk上的改動.
git add .
會遞歸地添加當前工做目錄中的全部文件.
git diff
不加參數的git diff:
show diff of unstaged changes.
此命令比較的是工做目錄中當前文件和暫存區域快照之間的差別,也就是修改以後尚未暫存起來的變化內容.
若要看已經暫存起來的文件和上次提交時的快照之間的差別,能夠用:
git diff --cached 命令.
show diff of staged changes.
(Git 1.6.1 及更高版本還容許使用 git diff --staged，效果是相同的).
git diff HEAD
show diff of all staged or unstated changes.
也即比較woking directory和上次提交之間全部的改動.
若是想看自從某個版本以後都改動了什麼,能夠用:
git diff [version tag]
跟log命令同樣,diff也能夠加上--stat參數來簡化輸出.
git diff [branchA] [branchB]能夠用來比較兩個分支.
它實際上會返回一個由A到B的patch,不是咱們想要的結果.
通常咱們想要的結果是兩個分支分開之後各自的改動都是什麼,是由命令:
git diff [branchA]…[branchB]給出的.
實際上它是:git diff $(git merge-base [branchA] [branchB]) [branchB]的結果.
git commit
提交已經被add進來的改動.
git commit -m 「the commit message"
git commit -a 會先把全部已經track的文件的改動add進來,而後提交(有點像svn的一次提交,不用先暫存). 對於沒有track的文件,仍是須要git add一下.
git commit --amend 增補提交. 會使用與當前提交節點相同的父節點進行一次新的提交,舊的提交將會被取消.
git reset
undo changes and commits.
這裏的HEAD關鍵字指的是當前分支最末梢最新的一個提交.也就是版本庫中該分支上的最新版本.
git reset HEAD: unstage files from index and reset pointer to HEAD
這個命令用來把不當心add進去的文件從staged狀態取出來,能夠單獨針對某一個文件操做: git reset HEAD - - filename, 這個- - 也能夠不加.
git reset --soft
move HEAD to specific commit reference, index and staging are untouched.
git reset --hard
unstage files AND undo any changes in the working directory since last commit.
使用git reset —hard HEAD進行reset,即上次提交以後,全部staged的改動和工做目錄的改動都會消失,還原到上次提交的狀態.
這裏的HEAD能夠被寫成任何一次提交的SHA-1.
不帶soft和hard參數的git reset,實際上帶的是默認參數mixed.
總結:
git reset --mixed id,是將git的HEAD變了(也就是提交記錄變了),但文件並無改變，(也就是working tree並無改變). 取消了commit和add的內容.
git reset --soft id. 實際上，是git reset –mixed id 後,又作了一次git add.即取消了commit的內容.
git reset --hard id.是將git的HEAD變了,文件也變了.
按改動範圍排序以下:
soft (commit) < mixed (commit + add) < hard (commit + add + local working)
git revert
反轉撤銷提交.只要把出錯的提交(commit)的名字(reference)做爲參數傳給命令就能夠了.
git revert HEAD: 撤銷最近的一個提交.
git revert會建立一個反向的新提交,能夠經過參數-n來告訴Git先不要提交.
git rm
git rm file: 從staging區移除文件,同時也移除出工做目錄.
git rm --cached: 從staging區移除文件,但留在工做目錄中.
git rm --cached從功能上等同於git reset HEAD,清除了緩存區,但不動工做目錄樹.
git clean
git clean是從工做目錄中移除沒有track的文件.
一般的參數是git clean -df:
-d表示同時移除目錄,-f表示force,由於在git的配置文件中, clean.requireForce=true,若是不加-f,clean將會拒絕執行.
git mv
git rm - - cached orig; mv orig new; git add new
git stash
把當前的改動壓入一個棧.
git stash將會把當前目錄和index中的全部改動(但不包括未track的文件)壓入一個棧,而後留給你一個clean的工做狀態,即處於上一次最新提交處.
git stash list會顯示這個棧的list.
git stash apply:取出stash中的上一個項目(stash@{0}),而且應用於當前的工做目錄.
也能夠指定別的項目,好比git stash apply stash@{1}.
若是你在應用stash中項目的同時想要刪除它,能夠用git stash pop
刪除stash中的項目:
git stash drop: 刪除上一個,也可指定參數刪除指定的一個項目.
git stash clear: 刪除全部項目.
git branch
git branch能夠用來列出分支,建立分支和刪除分支.
git branch -v能夠看見每個分支的最後一次提交.
git branch: 列出本地全部分支,當前分支會被星號標示出.
git branch (branchname): 建立一個新的分支(當你用這種方式建立分支的時候,分支是基於你的上一次提交創建的).
git branch -d (branchname): 刪除一個分支.
刪除remote的分支:
git push (remote-name) :(branch-name): delete a remote branch.
這個是由於完整的命令形式是:
git push remote-name local-branch:remote-branch
而這裏local-branch的部分爲空,就意味着刪除了remote-branch
git checkout
git checkout (branchname)
切換到一個分支.
git checkout -b (branchname): 建立並切換到新的分支.
這個命令是將git branch newbranch和git checkout newbranch合在一塊兒的結果.
checkout還有另外一個做用:替換本地改動:
git checkout --<filename>
此命令會使用HEAD中的最新內容替換掉你的工做目錄中的文件.已添加到暫存區的改動以及新文件都不會受到影響.
注意:git checkout filename會刪除該文件中全部沒有暫存和提交的改動,這個操做是不可逆的.
git merge
把一個分支merge進當前的分支.
git merge [alias]/[branch]
把遠程分支merge到當前分支.
若是出現衝突,須要手動修改,能夠用git mergetool.
解決衝突的時候能夠用到git diff,解決完以後用git add添加,即表示衝突已經被resolved.
git tag
tag a point in history as import.
會在一個提交上創建永久性的書籤,一般是發佈一個release版本或者ship了什麼東西以後加tag.
好比: git tag v1.0
git tag -a v1.0, -a參數會容許你添加一些信息,即make an annotated tag.
當你運行git tag -a命令的時候,Git會打開一個編輯器讓你輸入tag信息.
咱們能夠利用commit SHA來給一個過去的提交打tag:
git tag -a v0.9 XXXX
push的時候是不包含tag的,若是想包含,能夠在push時加上--tags參數.
fetch的時候,branch HEAD能夠reach的tags是自動被fetch下來的, tags that aren’t reachable from branch heads will be skipped.若是想確保全部的tags都被包含進來,須要加上--tags選項.
git remote
list, add and delete remote repository aliases.
由於不須要每次都用完整的url,因此Git爲每個remote repo的url都創建一個別名,而後用git remote來管理這個list.
git remote: 列出remote aliases.
若是你clone一個project,Git會自動將原來的url添加進來,別名就叫作:origin.
git remote -v:能夠看見每個別名對應的實際url.
git remote add [alias] [url]: 添加一個新的remote repo.
git remote rm [alias]: 刪除一個存在的remote alias.
git remote rename [old-alias] [new-alias]: 重命名.
git remote set-url [alias] [url]:更新url. 能夠加上—push和fetch參數,爲同一個別名set不一樣的存取地址.
git fetch
download new branches and data from a remote repository.
能夠git fetch [alias]取某一個遠程repo,也能夠git fetch --all取到所有repo
fetch將會取到全部你本地沒有的數據,全部取下來的分支能夠被叫作remote branches,它們和本地分支同樣(能夠看diff,log等,也能夠merge到其餘分支),可是Git不容許你checkout到它們.
git pull
fetch from a remote repo and try to merge into the current branch.
pull == fetch + merge FETCH_HEAD
git pull會首先執行git fetch,而後執行git merge,把取來的分支的head merge到當前分支.這個merge操做會產生一個新的commit.
若是使用--rebase參數,它會執行git rebase來取代原來的git merge.
git rebase
--rebase不會產生合併的提交,它會將本地的全部提交臨時保存爲補丁(patch),放在」.git/rebase」目錄中,而後將當前分支更新到最新的分支尖端,最後把保存的補丁應用到分支上.
rebase的過程當中,也許會出現衝突,Git會中止rebase並讓你解決衝突,在解決完衝突以後,用git add去更新這些內容,而後無需執行commit,只須要:
git rebase --continue就會繼續打餘下的補丁.
git rebase --abort將會終止rebase,當前分支將會回到rebase以前的狀態.
git push
push your new branches and data to a remote repository.
git push [alias] [branch]
將會把當前分支merge到alias上的[branch]分支.若是分支已經存在,將會更新,若是不存在,將會添加這個分支.
若是有多我的向同一個remote repo push代碼, Git會首先在你試圖push的分支上運行git log,檢查它的歷史中是否能看到server上的branch如今的tip,若是本地歷史中不能看到server的tip,說明本地的代碼不是最新的,Git會拒絕你的push,讓你先fetch,merge,以後再push,這樣就保證了全部人的改動都會被考慮進來.
git reflog
git reflog是對reflog進行管理的命令,reflog是git用來記錄引用變化的一種機制,好比記錄分支的變化或者是HEAD引用的變化.
當git reflog不指定引用的時候,默認列出HEAD的reflog.
HEAD@{0}表明HEAD當前的值,HEAD@{3}表明HEAD在3次變化以前的值.
git會將變化記錄到HEAD對應的reflog文件中,其路徑爲.git/logs/HEAD, 分支的reflog文件都放在.git/logs/refs目錄下的子目錄中.
特殊符號:
^表明父提交,當一個提交有多個父提交時,能夠經過在^後面跟上一個數字,表示第幾個父提交: ^至關於^1.
~<n>至關於連續的<n>個^.
97，98上同。
99.答：
分爲以下幾個步驟：
1.建立一個git裸服務器 （git init --bare）
2.從裸服務器將版本庫克隆至本地（git clone ）
3.本地常規操做
4.推送版本至服務器 （git remote + git push origin master）
5.從遠程服務器拉取版本（git pull）
100.答：見96
101．答：
版本管理
分佈式系統中，像 Git，Mercurial，Bazaar 以及 Darcs 等，客戶端並不僅提取最新版本的文件快照，而是把代碼倉庫完整地鏡像下來。這麼一來，任何一處協同工做用的服務器發生故障，過後均可以用任何一個鏡像出來的本地倉庫恢復。
102.答：
GitLab 是一個用於倉庫管理系統的開源項目，使用Git做爲代碼管理工具，並在此基礎上搭建起來的web服務
103．答：
GitLab解決了這個問題，你能夠在上面建立私人的免費倉庫。
GitLab讓開發團隊對他們的代碼倉庫擁有更多的控制，相比於GitHub，它有很多的特點：
容許免費設置倉庫權限；容許用戶選擇分享一個project的部分代碼；容許用戶設置project的獲取權限，進一步的提高安全性；能夠設置獲取到團隊總體的改進進度；經過innersourcing讓不在權限範圍內的人訪問不到該資源。
104.答：
構建完本身想要的代碼，git命令 git push origin master(這表明 push 到咱們本身的github上面),回到本身的github主頁能夠發現本地修改的已經push 上去了,而後點擊 new pull request 。如圖片順序,而後寫上本身 pull request 的理由,等待對方的迴應
105.答：
通常來講每一個Git項目中都須要一個「.gitignore」文件，這個文件的做用就是告訴Git哪些文件不須要添加到版本管理中。
106.答：
敏捷開發以用戶的需求進化爲核心，採用迭代、按部就班的方法進行軟件開發。在敏捷開發中，軟件項目在構建初期被切分紅多個子項目，各個子項目的成果都通過測試，具有可視、可集成和可運行使用的特徵。換言之，就是把一個大項目分爲多個相互聯繫，但也可獨立運行的小項目，並分別完成，在此過程當中軟件一直處於可以使用狀態。
107.答：
Jenkins 是一個可擴展的持續集成引擎。
主要用於：
l 持續、自動地構建/測試軟件項目。
l 監控一些定時執行的任務。
108.答:碼雲
109.答：
rabbitmq 基於amqp 協議實現，能夠保證消息的點對點，topic 傳遞，而且有消息確認機制保證消息的可靠傳輸,消息能夠持久化存儲
RabbitMQ既支持內存隊列也支持持久化隊列，消費端爲推模型，消費狀態和訂閱關係由服務端負責維護，消息消費完後當即刪除，不保留歷史消息。
缺點，保證了一致性和可靠性的同時，吞吐率和性能有所降低。
能夠用於 對數據一致性、穩定性和可靠性要求很高的場景
zeromq自己不是一個獨立進程，他是創建 在socket 之上 的一條通道，因此他能夠作消息的轉發，可是不能解耦服務，其餘的均可覺得服務解耦合。
kafka 自己 側重點在於消息的吞吐量上，處理速度上，不側重消息的可靠性傳遞，沒有消息確認機制，因此適合一些不重要的消息存儲,
Kafka只支持消息持久化，消費端爲拉模型，消費狀態和訂閱關係由客戶端端負責維護，消息消費完後不會當即刪除，會保留歷史消息。
所以支持多訂閱時，消息只會存儲一份就能夠了。可是可能產生重複消費的狀況。
不支持事務，適合產生大量數據的互聯網服務的數據收集業務。
110.答：
持久化信息
把它的投遞默認選項設置爲持久化
2. 發送到持久化的交換機
3. 到達持久化的隊列
111.答：
爲了保證RabbitMQ在退出或者crash等異常狀況下數據沒有丟失，須要將queue，exchange和Message都持久化。
queue的持久化
queue的持久化是經過durable=true來實現的。
如過將queue的持久化標識durable設置爲true,則表明是一個持久的隊列，那麼在服務重啓以後，也會存在，由於服務會把持久化的queue存放在硬盤上，當服務重啓的時候，會從新什麼以前被持久化的queue。隊列是能夠被持久化，可是裏面的消息是否爲持久化那還要看消息的持久化設置。也就是說，重啓以前那個queue裏面尚未發出去的消息的話，重啓以後那隊列裏面是否是還存在原來的消息，這個就要取決於發生着在發送消息時對消息的設置了。
若是要在重啓後保持消息的持久化必須設置消息是持久化的標識。
112.答：
消息的TTL就是消息的存活時間。RabbitMQ能夠對隊列和消息分別設置TTL。對隊列設置就是隊列沒有消費者連着的保留時間，也能夠對每個單獨的消息作單獨的設置。超過了這個時間，咱們認爲這個消息就死了，稱之爲死信。若是隊列設置了，消息也設置了，那麼會取小的。因此一個消息若是被路由到不一樣的隊列中，這個消息死亡的時間有可能不同（不一樣的隊列設置）。這裏單講單個消息的TTL，由於它纔是實現延遲任務的關鍵。
113.答：
direct型的Exchange，一般是將同一個message以一種循環的方式分發到不一樣的Queue，即不一樣的消費者手中，使用這種方式，值得注意的是message在消費者之間作了一個均衡，而不是說message在Queues之間作了均衡。
Fanout
使用這種類型的Exchange，會忽略routing key的存在，直接將message廣播到全部的Queue中。、
Topic
Topic Exchange是根據routing key和Exchange的類型將message發送到一個或者多個Queue中，咱們常常拿他來實現各類publish/subscribe，即發佈訂閱，這也是咱們常用到的ExchangeType。
114.答：
Celery是專一實時處理和任務調度的分佈式任務隊列。
主要應用場景：
1，web應用，當須要觸發事件須要較長時間處理完成，能夠交給celery進行異步執行，執行完後返回結果，這段時間不用等待，提升系統的吞吐量和響應時間。
2，完成任務時，須要額外的事件處理，如發送郵件等。
3，後臺定時任務處理，celery能夠幫助咱們在不一樣服務器進行定時任務管理。
115.答:
116.答：
（1）在配置文件中指定；（2）在程序中指定。
117.答：
/root/test/proj/celery
├── celeryconfig.py
├── celery.py
├── __init__.py
└── tasks.py
118.答：
@shared_task 裝飾器能讓你在沒有具體的 Celery 實例時建立任務：
119.答：作網絡請求模塊，模擬瀏覽器發送網絡請求行爲。
120．答：
BeautifulSoup是一個很是優秀的Python擴展庫，它能夠從HTML或XML文件中提取咱們感興趣的數據。它不但能夠標籤進行查找，還能夠經過標籤屬性來查找。
BeautifulSoup對象是一個複雜的樹形結構，它的每個節點都是一個Python對象，獲取網頁內容就是一個提取對象內容的過程，其提取對象的方法能夠分爲：遍歷文檔樹、搜索文檔樹、CSS選擇器。
全部的對象能夠分爲4種：
<1> Tag：Tag對象與XML或HTML原生文檔中的tag相同。它有不少方法和屬性，其中最重要的是：name和attributes。BeautifulSoup對象經過find()和find_all()方法，或者直接調用子標籤獲取一列對象或單個對象。
<2> NavigableString：用來表示標籤裏的文字，不是標籤。
<3> Comment：這是一個特殊類型的NavigableString對象，用來查找HTML文檔中的註釋。
<4> BeautifulSoup：這個對象表示文檔的所有內容。大部分時候能夠把它看成Tag對象，它支持遍歷文檔樹和搜索文檔樹的大部分方法。
121．答：
爬取動態頁面。
from selenium import webdriver
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC
from selenium.webdriver.common.by import By
122.答:
ENGINE : 引擎, 框架的核心, 其餘全部組件在其控制下協同工做
SCHEDULER: 調度器, 負責對SPIDER提交的下載請求進行調度
DOWNLOADER: 下載器, 負責下載頁面, (發送HTTP請求/接收HTTP響應)
SPIDER: 爬蟲, 負責提取頁面中的數據, 併產生對新頁面的下載請求
MIDDLEWARE: 中間件, 負責對Request對象和Response對象進行處理
ITEM PIPELINE: 數據管道, 負責對爬取到的數據進行處理
當SPIDER要爬取某URL地址的頁面時, 須要使用該URL構建一個Request對象, 提交給Engine
Request對象隨後進入SCHEDULER按照某種算法進行排隊, 以後的某一個時刻SHCEDULER將其送出隊,送往DOWNLOADER
DOWNLOADER根據Request對象中的URL地址發送一次HTTP請求到網站服務器, 以後用服務器返回的HTTP響應構造出一個Response對象,其中包含頁面的HTML文本
Response對象最終會被遞送給SPIDER的頁面解析函數(構造Request對象時指定)進行處理,頁面解析函數從頁面中提取數據, 封裝成Item後提交給ENGINE,Item以後被送往ITEM PIPELINES進行處理,最終可能由EXPROTER以某種數據格式寫入文件;另外一方面, 頁面解析函數還從頁面中提取URL, 構造出新的Request對象提交給ENGINE
123.答：
一．使用中間件DownLoaderMiddleware進行配置
二．直接在爬蟲程序中設置proxy字段。
124.答：
使用FilesPipeline下載大文件。
125.答：
算法根據如下規則調整下載延遲及併發數:
spider永遠以1併發請求數及 AUTOTHROTTLE_START_DELAY 中指定的下載延遲啓動。
當接收到回覆時，下載延遲會調整到該回復的延遲與以前下載延遲之間的平均值。
126.答：
直接使用Timer類
使用標準庫的sched模塊
127.答:
在settings.py文件裏設置COMMANDS_MODULE = 'properties.hi' ，就能夠在Scrapy的幫助中看到這個命令，運行時用scrapy hi。自定義命令的默認設置default_settings會和工程的設置合併到 一塊兒，可是相比在settings.py文件裏和命令行定義的設置優先級要低。
若是須要自定義多個命令，則能夠在工程的根目錄下創建一個文件夾，又如commands，裏面放一些相似上面hi.py文件的命令，而後設置COMMANDS_MODULE = 'properties.commands便可。
128.答：
1.經過Response對象的地址序列和Request對象的請求處理完成深度採集
2.經過CrawlSpider類型中的請求連接提取規則自動進行深度數據採集處理
129.答：
當Item在Spider中被收集以後，它將會被傳遞到Item Pipeline，一些組件會按照必定的順序執行對Item進行處理。
每一個Item Pipeline都是實現了簡單方法的Python類，好比決定此Item是丟棄而存儲。如下是Item Pipeline的典型應用：
- 驗證爬取的數據（檢查爬取的數據是否包含某些字段，數據清洗）
- 查重（重複的數據丟棄）
- 將爬取的結果保存到文件或數據庫
130．答：
from scrapy.exceptions import DropItem
class DuplicatesPipeline(object):
def __init__(self):
self.ids_seen = set()
def process_item(self, item, spider):
if item['id'] in self.ids_seen:
raise DropItem("Duplicate item found: %s" % item)
else:
self.ids_seen.add(item['id'])
return item
131.答：
見前面。
132.答：
- scheduler - 調度器
- dupefilter - URL去重規則（被調度器使用）
- pipeline - 數據持久化
133.答：
1. 對Doc進行關鍵詞抽取(分詞和計算TF-IDF權重)，抽出n個關鍵詞[(wod1, weight1), (word2, weight2), …,(wordn, weightn)]
2. 對每一個word，計算哈希值 hash_weight_pairs = [(hash(word1), weight), (hash(word2), weight2),…, (hash(wordn), weightn)]，每一個單詞被hash成默認64位的二進制比特。
3. 對hash_weight_pairs進行縱向加權求和，若是該位是1，則+weight,若是是0，則-weight，最後生成長度位64的數組
4.遍歷這64位的數組，若是該位爲正，則轉換成1，不然位0
134．答：
深度優先
是從左到右深度進行爬取的，以深度爲準則從左到右的執行（遞歸方式實現）Scrapy默認是深度優先的
' v:shapes="_x0000_i1027">
' v:shapes="_x0000_i1028">
廣度優先
是以層級來執行的，（列隊方式實現）
v:shapes="_x0000_i1029">
135.答：
在python開發中，咱們可能會遇到一種狀況，就是當前的項目依賴的是某一個版本，可是另外一個項目依賴的是另外一個版本，這樣就會形成依賴衝突，而virtualenv就是解決這種狀況的，virtualenv經過建立一個虛擬化的python運行環境，將咱們所需的依賴安裝進去的，不一樣項目之間相互不干擾。
136.答：
pipreqs，能夠自動根據源碼生成 requirements.txt .
137.答：Pychecker，Pylint。
138.答：
運維管理工具的對比。
139-155，簡要回答
B樹和B+樹其實都是平衡搜索樹。這裏要腦補一下平衡搜索樹的概念：這個詞劃分一下就是平衡+搜索+樹。也就是說，他首先是一棵樹，其次能搜索，再次他是平衡的。你們耳熟能詳的一個概念：二叉平衡搜索樹。
冒泡，插入，選擇，希爾，堆排序，快速排序，歸併排序。
順序查找，二分查找，哈希表。
工廠模式，單例模式，建造者模式，原型模式，適配器模式，橋接模式，過濾器模式。
Sudo apt
Pv page view 頁面訪問量
Uv Unique Visitor 獨立訪客訪問數
每秒查詢率QPS是對一個特定的查詢服務器在規定時間內所處理流量多少的衡量標準。
1 WSGI是一種通訊協議
2 uwsgi是一種線路協議而不是通訊協議，在此經常使用於在uWSGI服務器與其餘網絡服務器的數據通訊。
3 而uWSGI是實現了uwsgi和WSGI兩種協議的Web服務器。
supervisor管理進程，是經過fork/exec的方式將這些被管理的進程看成supervisor的子進程來啓動，因此咱們只須要將要管理進程的可執行文件的路徑添加到supervisor的配置文件中就行了。此時被管理進程被視爲supervisor的子進程，若該子進程異常中斷，則父進程能夠準確的獲取子進程異常中斷的信息，經過在配置文件中設置autostart=ture，能夠實現對異常中斷的子進程的自動重啓。
反向代理（Reverse Proxy）方式是指以代理服務器來接受internet上的鏈接請求，而後將請求轉發給內部網絡上的服務器，並將從服務器上獲得的結果返回給internet上請求鏈接的客戶端，此時代理服務器對外就表現爲一個反向代理服務器。
明文：須要祕密傳送的消息。
密文：明文通過密碼變換後的消息。
加密：由明文到密文的變換。
解密：從密文恢復出明文的過程。
破解：非法接收者試圖從密文分析出明文的過程。
加密算法：對明文進行加密時採用的一組規則。
解密算法：對密文進行解密時採用的一組規則。
密鑰：加密和解密時使用的一組密碼信息。
對稱加密：是採用單鑰密碼系統的加密方法，使用同一密鑰對信息進行加密和解密的加密方法。
非對稱加密：須要兩個密鑰：公共密鑰和私有密鑰，它們成對出現，公鑰加密的數據有且只有私鑰能解密，私鑰加密的數據有且只有公鑰解密，相對於「對稱加密」，「非對稱加密」加密方法加密和解密使用不一樣的密鑰，因此叫「非對稱加密」加密方法。
對稱加密和非對稱加密的區別：在於加密和解密是否使用的同一個密鑰。
加密、身份認證、數字簽名認證：
加密：將數據資料加密，使得非法用戶即使獲取加密後的資料，也沒法獲取正確的資料內容，因此數據加密能夠保證數據防止監聽攻擊；其重點在於數據的安全性。
身份認證：判斷某身份的真實性，確認身份後，系統才能夠依不一樣的身份賦予不一樣的權限；其重點在於用戶的真實性。
數字簽名認證：首先"數字簽名"就是附加在數據單元上的一些數據，或是對數據單元所做的密碼變換。這種數據或變換容許接收者判斷數據的來源和數據的完整性，防止被僞造篡改。數字簽名認證側重於把保證數據的完整性，防止被僞造和篡改。
認證原理: