1、所謂可變類型與不可變類型是指：數據能夠直接進行修改，如果能直接修改那么就是可變，否則是不可變
不可變對象：該對象所指向的內存中的值不能被改變。當改變某個變量時候，由於其所指的值不能被改變，相當於把原來的值復制一份后再改變，這會開辟一個新的地址，變量再指向這個新的地址。
可變對象：該對象所指向的內存中的值可以被改變。變量（准確的說是引用）改變后，實際上是其所指的值直接發生改變，並沒有發生復制行為，也沒有開辟新的地址，通俗點說就是原地改變。
可變類型有： 列表、字典、集合
不可變類型有： 數字、字符串、元組
2、傳參順序：位置參數，元祖不定長參數，缺省參數，字典不定長參數
def sum_nums_3(a, *args, b=22, c=33, **kwargs):
3、linux系統下安裝與卸載
離線安裝(deb文件格式安裝)與卸載：
sudo dpkg -i 安裝包名 sudo dpkg –r 安裝包名
在線安裝(apt-get方式安裝)與卸載：
sudo apt-get install 安裝包 sudo apt-get remove 安裝包名
4、並發與並行
並發：可使用的CPU核心數少於任務數，在一段時間內交替去執行任務。
並行：可使用的cpu核心數大於任務數時，任務同時進行
線程是並發，進程是並行。
5、進程和線程以及協程
多進程模塊：multiprocessing 多線程模塊：threading
多進程適合CPU密集任務（求π圓周率、科學計算、機器學習、通過大量計算才能接到結果的程序）
多線程適合IO（輸入輸出）密集型任務（文件操作、數據庫操作、網絡編程、爬蟲程序）
區別對比：
①進程之間不共享全局變量
②線程之間共享全局變量，但是要注意資源競爭的問題，解決辦法: 互斥鎖或者線程同步
③創建進程的資源開銷要比創建線程的資源開銷要大
④進程是操作系統資源分配的基本單位，線程是CPU調度的基本單位
⑤線程不能夠獨立執行，必須依存在進程中
小結：
多進程要比多線程消耗的資源多，但是多進程開發比單進程多線程開發穩定性要強，某個進程掛掉不會影響其它進程。
多進程可以使用cpu的多核運行，多線程可以共享全局變量。
線程不能單獨執行必須依附在進程里面
多進程開發比單進程多線程開發穩定性要強
協程：
最大的優勢就是協程極高的執行效率。因為子程序切換不是線程切換，而是由程序自身控制，因此，沒有線程切換的開銷，和多線程比，線程數量越多，協程的性能優勢就越明顯。
第二大優勢就是不需要多線程的鎖機制，因為只有一個線程，也不存在同時寫變量沖突，在協程中控制共享資源不加鎖，只需要判斷狀態就好了，所以執行效率比多線程高很多。
因為協程是一個線程執行，那怎么利用多核CPU呢？最簡單的方法是多進程+協程，既充分利用多核，又充分發揮協程的高效率，可獲得極高的性能。
這個問題被問的概率相當之大，其實多線程，多進程，在實際開發中用到的很少，除非是那些對項目性能要求特別高的，有的開發工作幾年了，也確實沒用過，你可以這么回答，
給他扯扯什么是進程，線程（cpython 中是偽多線程）的概念就行，實在不行你就說你之前寫過下載文件時，用過多線程技術，或者業余時間用過多線程寫爬蟲，提升效率。
進程：一個運行的程序（代碼）就是一個進程，沒有運行的代碼叫程序，進程是系統資源分配的最小單位，進程擁有自己獨立的內存空間，所以進程間數據不共享，開銷大。
線程： 調度執行的最小單位，也叫執行路徑，不能獨立存在，依賴進程存在一個進程至少有一個線程，叫主線程，而多個線程共享內存(數據共享，共享全局變量)，從而極大地
提高了程序的運行效率。
協程：是一種用戶態的輕量級線程，協程的調度完全由用戶控制。協程擁有自己的寄存器上下文和棧。 協程調度切換時，將寄存器上下文和棧保存到其他地方，在切回來的時候，
恢復先前保存的寄存器上下文和棧，直接操作棧則基本沒有內核切換的開銷，可以不加鎖的訪問全局變量，所以上下文的切換非常快。
6、互斥鎖
互斥鎖的作用就是保證同一時刻只能有一個線程去操作共享數據，保證共享數據不會出現錯誤問題
使用互斥鎖的好處確保某段關鍵代碼只能由一個線程從頭到尾完整地去執行
使用互斥鎖會影響代碼的執行效率，多任務改成了單任務執行
互斥鎖如果沒有使用好容易出現死鎖的情況
# 創建鎖
mutex = threading.Lock()
# 上鎖
mutex.acquire()
...這里編寫代碼能保證同一時刻只能有一個線程去操作, 對共享數據進行鎖定...
# 釋放鎖
mutex.release()
7、死鎖
死鎖: 一直等待對方釋放鎖的情景就是死鎖 死鎖的結果：會造成應用程序的停止響應，不能再處理其它任務了。
原因：系統資源不足、資源分配不當又相互競爭資源、請求資源順序不當
避免死鎖的方法：
因為互斥是不可改變的，所以只能破壞其他三個條件中的一個來解除死鎖，方法：剝奪資源、殺死其中一個線程。
避免死鎖最簡單的方法就是阻止循環等待條件，將系統中所有的資源設置標志位、排序，規定所有的進程申請資源必須以一定的順序做操作來避免死鎖
8、、TCP和UDP協議
TCP協議（可靠的，但是速度要略慢於UDP協議）是可靠傳輸協議，主要用於數據傳輸、文件上傳下載、網絡通信等等
UDP協議（速度要高於TCP協議，但是沒有辦法保證數據的安全性）是不可靠傳輸協議，主要用於視頻通話等應用場景
TCP 的英文全拼(Transmission Control Protocol)簡稱傳輸控制協議，它是一種面向連接的、可靠的、基於字節流的傳輸層通信協議。
面向連接的：基於點對點連接的
TCP傳輸是一種可靠傳輸協議：給小伙伴發送5MB數據，小伙伴接收到的數據也應該是5MB
基於字節流的傳輸層通信協議：所有的數據傳輸都是基於字節流（二進制形式）
TCP是面向連接的，udp是面向非連接的。
tcp要求的資源更多。udp要求的資源更少。
tcp是可靠的。udp是非可靠的。
tcp速度慢，udp速度快。
tcp傳輸大文件，udp小文件。
tcp的可靠傳輸(記住)：
① TCP 采用發送應答機制
② 超時重傳
③ 錯誤校驗
④ 流量控制和阻塞管理
9、HTTP：
HTTP協議是一個超文本傳輸協議
HTTP協議是一個基於TCP傳輸協議傳輸數據的
HTTP協議規定了瀏覽器和 Web 服務器通信數據的格式
http請求報文：
get請求報文：請求行、請求頭、空行
post請求報文：請求行、請求頭、空行、請求體（post請求可以允許沒有請求體）
請求行：1、請求方式，2、請求資源路徑，3、HTTP協議版本
響應報文：
1、響應行/狀態行 2、響應頭 3、空行 4、響應體
響應行：HTTP協議版本 狀態碼 狀態描述
http和https的區別
http是無狀態的，對傳輸數據未加密的傳輸協議，https協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，要比http協議安全。http要更快一些，端口也不一樣http是80，https是443.
HTTP協議傳輸的數據都是未加密的，也就是明文的，因此使用HTTP協議傳輸隱私信息非常不安全，為了保證這些隱私數據能加密傳輸，
於是網景公司設計了SSL（Secure Sockets Layer）協議用於對HTTP協議傳輸的數據進行加密，從而就誕生了HTTPS。簡單來說，
HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，要比http協議安全。
HTTPS和HTTP的區別主要如下：
1、https協議需要到ca申請證書，一般免費證書較少，因而需要一定費用。
2、http是超文本傳輸協議，信息是明文傳輸，https則是具有安全性的ssl加密傳輸協議。
3、http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。
4、http的連接很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全
10、URL：
URL就是網絡資源的地址，簡稱網址，通過URL能夠找到網絡中對應的資源數據
組成部分：協議部分、域名部分、資源路徑部分、查詢參數部分 [可選]
開發者工具（比如谷歌瀏覽器）的Headers選項總共有三部分組成：1、General主要信息，2、Response Headers響應頭，3、Request Headers請求頭
11、深淺拷貝：
淺拷貝有三種形式:切片操作、工廠函數、copy 模塊中的 copy 函數
深拷貝只有一種形式，copy 模塊中的 deepcopy()函數
淺拷貝最多拷貝對象的一層，深拷貝可能拷貝對象的多層
copy.copy函數是淺拷貝，只對可變類型的第一層對象進行拷貝，對拷貝的對象開辟新的內存空間進行存儲，不會拷貝對象內部的子對象。
不可變類型進行淺拷貝不會給拷貝的對象開辟新的內存空間，而只是拷貝了這個對象的引用。
copy.deepcopy函數 深拷貝：
可變類型進行深拷貝會對該對象到最后一個可變類型的每一層對象就行拷貝, 對每一層拷貝的對象都會開辟新的內存空間進行存儲。
不可變類型進行深拷貝如果子對象沒有可變類型則不會進行拷貝，而只是拷貝了這個對象的引用，否則會對該對象到最后一個可變類型的每一層對象就行拷貝,
對每一層拷貝的對象都會開辟新的內存空間進行存儲。
12、正則表達式（看兩眼就行）：
可讀性差，但通用性強，能在適用於很多種編程語言
. 表示匹配任意1個字符（除了\n）
[ ] 表示匹配[ ]中列舉的1個字符
\d 表示匹配一個數字，即0-9
\D 表示匹配一個非數字，即不是數字
\s 表示匹配一個空白字符，即 空格，tab鍵
\S 表示匹配一個非空白字符
\w 表示匹配一個非特殊字符，即a-z、A-Z、0-9、_、漢字
\W 表示匹配一個特殊字符，即非字母、非數字、非漢字
* 表示匹配前一個字符出現0次或者無限次，即可有可無
+ 表示匹配前一個字符出現1次或者無限次，即至少有1次
? 表示匹配前一個字符出現1次或者0次，即要么有1次，要么沒有
{m} 表示匹配前一個字符出現m次
{m,n} 表示匹配前一個字符出現從m到n次
13、進程間的通信方式（看兩眼就行）
①匿名管道( pipe )：管道是一種半雙工的通信方式，數據只能單向流動，而且只能在具有親緣關系的進程間使用。進程的親緣關系通常是指父子進程關系。
②高級管道(popen)：將另一個程序當做一個新的進程在當前程序進程中啟動，則它算是當前程序的子進程，這種方式我們成為高級管道方式。
③有名管道 (named pipe) ： 有名管道也是半雙工的通信方式，但是它允許無親緣關系進程間的通信。
④消息隊列( message queue ) ： 消息隊列是由消息的鏈表，存放在內核中並由消息隊列標識符標識。消息隊列克服了信號傳遞信息少、管道只能承載無格式字節流以及緩沖區大小受限等缺點。
⑤信號量( semophore ) ： 信號量是一個計數器，可以用來控制多個進程對共享資源的訪問。它常作為一種鎖機制，防止某進程正在訪問共享資源時，其他進程也訪問該資源。因此，主要作為進程間以及同一進程內不同線程之間的同步手段。
⑥信號 ( sinal ) ： 信號是一種比較復雜的通信方式，用於通知接收進程某個事件已經發生。
⑦共享內存( shared memory ) ：共享內存就是映射一段能被其他進程所訪問的內存，這段共享內存由一個進程創建，但多個進程都可以訪問。共享內存是最快的 IPC 方式，它是針對其他進程間通信方式運行效率低而專門設計的。它往往與其他通信機制，如信號兩，配合使用，來實現進程間的同步和通信。
⑧套接字( socket ) ： 套接口也是一種進程間通信機制，與其他通信機制不同的是，它可用於不同機器間的進程通信。
14、Django中間件
Django在中間件中預設了六個方法，分別在不同階段運行，對輸入和輸出進行干預。
①初始化：在服務器響應第一個請求時調用一次，判斷是否啟用當前中間件。
def init():
②處理請求前：在每個請求上調用，request對象產生之后，URL匹配之前調用，返回None或者httpResponse對象。
def process_request(request):
③處理視圖前：在每個請求上調用，url匹配之后，視圖函數調用之前調用，返回None或者httpResponse對象。
def process_view(request, view_func, view_args, view_kwargs):
④處理模板響應前：在每個請求上調用，返回實現了render方法的響應對象。
def process_template_response(request, response):
⑤處理響應后：所有響應返回瀏覽器之前被調用，在每個請求上調用，返回httpResponse對象
def process_response(request, response):
⑥異常處理：當視圖拋出異常時調用，在每個請求上調用，返回一個httpResponse對象
def process_exception(request,exception):
補充：返回值可以是一個NONE，或者HttpResponse對象，如果是none，將繼續處理這個請求，執行響應的視圖，如果返回是Httpresponse對象，則直接將該對象返回給用戶（如果返回httpResponse對象，django不會調用視圖函數，將執行中間件的process_response方法並將應用到該httpResponse並返回結果）。
自定義中間件示例：
from django.utils.deprecation import MiddlewareMixin
class MD1(MiddlewareMixin):
def process_request(self, request):
print("MD1里面的 process_request")
def process_response(self, request, response):
print("MD1里面的 process_response")
return response
# 在settings.py的MIDDLEWARE配置項中注冊上述兩個自定義中間件：
MIDDLEWARE = [
'django.middleware.security.SecurityMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.common.CommonMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'django.middleware.clickjacking.XFrameOptionsMiddleware',
'middlewares.MD1', # 自定義中間件MD1
'middlewares.MD2' # 自定義中間件MD2
]
15、Nginx
一款開源的高性能http服務器和反向代理。
1、作為web服務器，處理靜態文件和搜索文件的效率非常高。
2、最大支持五萬個並發，但只占用很少的內存空間
3、穩定性高，配置簡潔
4、強大的反向代理和負載均衡功能，平衡集群中的負載壓力應用。
16、WSGI
WSGI是一種web服務器網關接口。他是一個web服務器（如Nginx，uWSGI等服務器）與web應用（如用FLASK框架寫的程序）通信的一種規范。
17、uwsgi
uwsgi是一種線路協議（不是通信協議），常用於在與uWSGI服務器與其他網絡服務器的數據通信。
18、uWSGI
uWSGI是一個web服務器，實現了WSGI、uwsgi，http等協議。Nginx中HttpUwsgiModule的作用就是與uWSGI服務器進行交換
19、Nginx和uWSGI服務器之間如何配合工作的
首先瀏覽器發送http請求到Nginx服務器，Nginx根據接收到的請求包，進行url分析，判斷訪問的資源類型，如果是靜態資源，直接讀取靜態資源返回給瀏覽器，如果請求的是動態資源就轉交給uWSGI服務器，uWSGI服務器根據自身的uwsgi和WSGI協議，找到對應的Django框架，Django框架下的應用進行邏輯處理后，將返回值發送到uWSGI服務器，然后uWSGI服務器再返回給Nginx，最后Nginx將返回值返回給瀏覽器進行渲染顯示給用戶。
20、對數據庫的基本優化操作
對於強調快速讀取的操作，對事物沒有要求的，可以考慮使用MyISAM數據庫引擎
①為了提高查詢效率，可以做冗余字段設計，以空間換時間
②對搜索頻率高的字段可以設置索引，唯一性太差的字段不適合單獨創建索引，即使頻繁作為查詢條件；更新非常頻繁的字段不適合創建索引；
③字段類型的選擇。選擇占用字節少的，能用一個字節的就不用兩個字節的，能用varchar確定字段長度時，就不要用text。
④盡量將字段設置為not null
⑤如果一個頁面需要多次連接數據庫，最好一次性取出所有需要的數據，減少對數據庫的查詢次數
⑥使用緩存減少與數據庫的交互
⑦Django框架下的Querysets本來就有緩存。
敲代碼時注意點：
能使用關聯查詢解決的盡量不要使用子查詢
⑧使用外鍵來聯系表與表之間的查詢
⑨sql語句在使用時盡量大寫（數據庫在解析語句時會先轉換成大寫再執行）
使用慢查詢工具找出效率低下的SQL語句進行優化；
⑩盡量避免在 where 子句中使用!=或<>操作符， MySQL只有對以下操作符才使用索引：<，<=，=，>，>=，BETWEEN，IN，以及某些時候的LIKE
用戶請求量大，單庫太大，單表太大就需要分庫分表。(分庫分表的順序應該是先垂直分，后水平分，因為垂直分更簡單）
垂直分表：針對表內字段多而數據多，使用垂直切分。大表拆小表，將不常用的、數據量大的字段拆到拓展表
水平分表：因為單張表的數據量太大，使用水平切分，把表的數據按某種規則（RANGE，HASH取模等）切分成多張表，甚至多個庫上的多張表，如user表拆分為user_0和user_1表。
垂直分庫：單個庫數據量大時，則使用垂直切分，根據業務切分成不同的庫，並分別部署到不同主機上（單個主機資源有限）。
水平分庫：將單張表的的數據切分到多個服務器上，每個服務器具有相應的庫與表，只是表中數據集合不同。
水平分庫分表切分規則：
RANGE：0到一萬是一張表，一萬零一到兩萬是一張表。
HASH取模，離散化：一個商場系統，一般都是將用戶，訂單作為主表，然后將和它們相關的作為附表，這樣不會造成跨庫事
務之類的問題。 取用戶id，然后hash取模，分配到不同的數據庫上。
還有地理區域和時間（如一年前的數據切到另外的表中）規則。
21、Django如何提升性能（高並發）
提升性能主要是兩個指標，一個高並發，一個響應時間
1、盡量一次性取出所需要的數據，減少與數據庫交互
2、當需要比較少字段數據時，可以使用qeryset.values和values_list
3、使用redis緩存數據
4、使用celery將耗時任務比如手機驗證碼、郵件等扔到隊列中，異步執行
5、對數據庫進行優化
6、如果要求很高的話，需要將框架二次開發，將框架拆掉，自己寫socket實現http通信，底層用純c，c++寫提升效率。把orm框架干掉，自己編寫封裝與數據庫交互的框架，因為orm效率比較低。
前端措施
1、減少http請求，比如使用雪碧圖
2、充分利用瀏覽器緩存，將常用的css、js圖標等靜態資源緩存到瀏覽器本地。通過設置http頭中的cache—control和expriress屬性設置瀏覽器緩存
運維措施：
搭建集群，分庫分表，分散壓力，多花錢升級硬件就行了
22、redis持久化（redis默認開啟RDB，AOF未開啟）
1、RDB快照持久化
將內存中的數據寫入磁盤進行持久化。在進行持久化時，redis會創建子進程來執行。執行BGSAVE命令，手動觸發RDB持久化。
2、AOF追加文件持久化
redis可將執行的所有指令追加記錄到文件中持久化存儲
注意：（redis集群）
redis cluster 不支持事務
redis cluster 不支持多鍵操作，如mset
# 使用默認的就可以
# appendfsync always # 每個操作都寫到磁盤中
appendfsync everysec # 每秒寫一次磁盤，默認
# appendfsync no # 由操作系統決定寫入磁盤的時機
https://www.cnblogs.com/jian0110/p/10205945.html
https://baijiahao.baidu.com/s?id=1654694618189745916&wfr=spider&for=pc
23、TPS
事務/秒。一個事務是指一個客戶機向服務器發送請求然后服務器做出反應的過程。
24、redis的watch就是一個樂觀鎖
25、事務隔離級別
① Serializable (串行化)：可避免臟讀、不可重復讀、幻讀的發生。
② Repeatable read (可重復讀)：可避免臟讀、不可重復讀的發生。
③ Read committed (讀已提交)：可避免臟讀的發生。
④ Read uncommitted (讀未提交)：最低級別，任何情況都無法保證。
數據庫事務的四大特性以及事務的隔離級別 https://www.cnblogs.com/kopok/p/15212528.html
補充：innodb和myisam引擎區別：
innodb支持事務，myisam不支持事務。
InnoDB支持外鍵，而MyISAM不支持。對一個包含外鍵的InnoDB表轉為MYISAM會失敗；
InnoDB表必須有唯一索引（如主鍵）（用戶沒有指定的話會自己找/生產一個隱藏列Row_id來充當默認主鍵），而Myisam可以沒有
Innodb存儲文件有frm、ibd，而Myisam是frm、MYD、MYI
Innodb：frm是表定義文件，ibd是數據文件
Myisam：frm是表定義文件，myd是數據文件，myi是索引文件
InnoDB支持表級鎖、行(默認)級鎖，而MyISAM支持表級鎖。（在執行不能確定掃描范圍的sql語句時，innodb同樣會鎖全表。）
myisam使用非聚集索引，索引和數據分開，只緩存索引；innodb使用聚集索引，索引和數據存在一個文件。
myisam保存表具體行數；innodb不保存。
https://blog.csdn.net/qq_41706670/article/details/92836395
https://blog.csdn.net/qq_35642036/article/details/82820178?utm_medium=distribute.pc_relevant_t0.none-task-blog-2defaultBlogCommendFromMachineLearnPai2default-1.essearch_pc_relevant&depth_1-utm_source=distribute.pc_relevant_t0.none-task-blog-2defaultBlogCommendFromMachineLearnPai2default-1.essearch_pc_relevant
26、MySQL三范式
1、原子性，列不可拆分，表中的所有字段值都是不可分解的原子值
2、有主鍵，且其他字段必須完全依賴主鍵
3、非主鍵列必須直接依賴於主鍵，不能存在傳遞依賴，即不能存在：非主鍵列 A 依賴於非主鍵列 B，非主鍵列 B 依賴於主鍵的情況
27、緩存雪崩
緩存雪崩是指緩存不可用或者大量緩存由於超時時間相同在同一時間段失效，大量請求直接訪問數據庫，數據庫壓力過大導致系統雪崩。
解決方案：
1、給緩存加上一定區間內的隨機生效時間，不同的key設置不同的失效時間，避免同一時間集體失效。比如以前是設置10分鍾的超時時間，那每個Key都可以隨機8-13分鍾過期，盡量讓不同Key的過期時間不同。
2、采用多級緩存，不同級別緩存設置的超時時間不同，及時某個級別緩存都過期，也有其他級別緩存兜底。
3、利用加鎖或者隊列方式避免過多請求同時對服務器進行讀寫操作。
28、緩存穿透
緩存和數據庫中都沒有的數據，而用戶不斷發起請求，如發起為id為“-1”的數據或id為特別大不存在的數據。這時的用戶很可能是攻擊者，攻擊會導致數據庫壓力過大。
解決方案：（1、緩存空對象，2、過濾請求 布隆過濾器）
- 約定:對於返回為NULL的依然緩存，對於拋出異常的返回不進行緩存,注意不要把拋異常的也給緩存了。采用這種手段的會增加我們緩存的維護成本，需要在插入緩存的時候刪除這個空緩存，當然我們可以通過設置較短的超時時間來解決這個問題。
- 制定一些規則過濾一些不可能存在的數據，小數據用BitMap，大數據可以用布隆過濾器，比如你的訂單ID 明顯是在一個范圍1-1000，如果不是1-1000之內的數據那其實可以直接給過濾掉。
布隆過濾器容量有限且不支持刪除，隨着里面內容的增加，誤判率就會隨之上升。請問，這個問題你們是怎么解決的？
首先，不支持刪除的話，就換一個支持刪除的布隆過濾器的輪子咯。
比如我前面的文章中提到的布谷鳥過濾器。
或者就是提前重構布隆過濾器。
比如在容量達到 50% 的時候，就申請一個新的更大的布隆過濾器來替換掉之前的過濾器。
只是需要注意的是，重建你得知道有那些數據需要進行重建的，所以你得有個地方來記錄。
比如就是 Redis、數據庫，甚至內存緩存都可以。
沒落地過沒關系，你底氣十足的回答就行了。
你要相信，面試官八成也沒落地過，你們看的說不定都是同一份資料呢。
注:布隆過濾器說存在的有可能存在，說不存在那肯定不存在
29、緩存擊穿
緩存擊穿是指緩存中沒有但數據庫中有的數據（一般是緩存時間到期），這時由於並發用戶特別多，同時讀緩存沒讀到數據，又同時去數據庫去取數據，引起數據庫壓力瞬間增大，造成過大壓力
對於大熱點數據，可以在后台開啟定時任務，專門更新某些快過期的數據。比如設置熱點過期時間是十分鍾，在第八分鍾或第九分鍾的時候主動更新。或者永不過期
30、面向對象
面向對象是相對於面向過程而言的。面向過程語言是一種基於功能分析的、以算法為中心的程序設計方法；而面
向對象是一種基於結構分析的、以數據為中心的程序設計思想。在面向對象語言中有一個有很重要東西，叫做類。
面向對象有三大特性：封裝、繼承、多態。
31、redis過期策略
①定時過期
每個設置過期時間的key都需要創建一個定時器，到過期時間就會立即清除。該策略可以立即清除過期的數據，對內存很友好；但是會占用大量的CPU資源去處理過期的數據，從而影響緩存的響應時間和吞吐量。
②惰性過期
只有當訪問一個key時，才會判斷該key是否已過期，過期則清除。該策略可以最大化地節省CPU資源，卻對內存非常不友好。極端情況可能出現大量的過期key沒有再次被訪問，從而不會被清除，占用大量內存
③定期過期
每隔一定的時間，會掃描一定數量的數據庫的expires字典中一定數量的key，並清除其中已過期的key。該策略是前兩者的一個折中方案。通過調整定時掃描的時間間隔和每次掃描的限定耗時，可以在不同情況下使得CPU和內存資源達到最優的平衡效果。
redis同時使用了惰性過期和定期過期：
Redis過期刪除采用的是定期刪除，默認是每100ms檢測一次，遇到過期的key則進行刪除，這里的檢測並不是順序檢測，而是隨機檢測。那這樣會不會有漏網之魚？顯然Redis也考慮到了這一點，當我們去讀/寫一個已經過期的key時，會觸發Redis的惰性刪除策略，直接回干掉過期的key。
如果定期刪除沒刪除key。然后你也沒即時去請求key，也就是說惰性刪除也沒生效。這樣，redis的內存會越來越高。那么就應該采用內存淘汰機制。
32、redis緩存淘汰機制
volatile-lru：當內存不足以容納新寫入數據時，在設置了過期時間的鍵空間中，移除最近最少使用的key。（在實際應用中都設置了過期時間，設置volatile-lru策略）
33、mysql數據庫和redis緩存操作順序
先更新MySQL數據庫，再刪除redis緩存。
34、迭代器、生成器、裝飾器、yield
35、如果因為一些原因，線上Redis掛了，然后所有請求打到數據庫層導致數據庫也掛了，這時該怎么進行恢復？
先把 Redis 和數據庫服務重新啟動起來。但是啟動之前得先做個小操作，把流量摘掉，可以先把流量攔截在入口的地方，比如簡單粗暴的通過 Nginx 的配置把請求都轉到一個精心設計的錯誤頁面，就是說這么一個意思。這樣做的目的是為了防止流量過大，直接把新啟動的服務，啟動一個打掛一個的情況出現。
要是啟動起來又扛不住了，三大利器：緩存、拆分、加錢。就是當 Redis 服務重新啟動后，通過程序先放點已知的熱點 key 進去后，系統再對外提供服務，防止緩存擊穿的場景。
而且上面這一系列操作其實和開發人員的關系不大，主要是運維同學干的事兒。開發同學最多就是在設計服務的時候做到服務無狀態，以達到快速水平擴容的目的。
然后回答預防方案：緩存雪崩、擊穿和穿透
36、pipeline
可以一次性發送多條命令並在執行完后一次性將結果返回。
pipeline 通過減少客戶端與Redis的通信次數來實現降低往返延時時間。
原理：
實現的原理是隊列。
Client 可以將三個命令放到一個 tcp 報文一起發送。Server 則可以將三條命令的處理結果放到一個 tcp 報文返回。隊列是先進先出，這樣就保證數據的順序性。
37、celery
Celery的架構由三部分組成，消息中間件（message broker），任務執行單元（worker）和任務執行結果存儲（task result store）組成。
broker可以使用RabbitMQ (消息隊列)或者Redis（緩存數據庫）
celery充當生產者發布任務，然后任務緩存到中間人（或者說消息隊列，redis充當）暫時存儲，worker（celery充當）檢測到消息隊列中有任務后執行任務
celery 是一個簡單、靈活且可靠、處理大量消息的分布式系統，可以在一台或者多台機器上運行.
特點:
單個 Celery 進程每分鍾可處理數以百萬計的任務.
通過消息進行通信，使用消息隊列（ 中間人或broker ）在生產者和消費者之間進行協調。
Celery 核心模塊
Celery有一下5個核心角色
Task
就是任務，有異步任務和定時任務
Broker
中間人，接收生產者發來的消息即Task，將任務存入隊列。任務的消費者是Worker。Celery本身不提供隊列服務，推薦用Redis或RabbitMQ實現隊列服務。
Worker
執行任務的單元，它實時監控消息隊列，如果有任務就獲取任務並執行它。
Beat
定時任務調度器，根據配置定時將任務發送給Broler。
Backend
用於存儲任務的執行結果。
38、resful規范
39、分布式數據庫主鍵ID的設計
使用UUID或者雪花算法
40、session共享
41、flask請求上下文和應用上下文
current_app、g是應用上下文 request、session是請求上下文
應用上下文：在flask 應用程序運行過程中，保存的一些配置信息，比如程序名、數據庫連接、應用信息等。可以說他是request context中一個對app的代理人，它的作用主要是幫助 request 獲取當前的應用。但它也不是一直存在的，它是伴 request 而生，隨 request 而滅的。
請求上下文：保存了客戶端和服務器交互的數據。flask從客戶端獲取請求后，為了處理請求需要讓視圖訪問一些對象，如果就像請求對象通過參數傳入到視圖，處理過程中訪問很多對象就會弄得有點亂，而請求上下文把對象變成了全局可訪問，隨用隨取，也比較方便。
42、三次握手、四次揮手
43、OSI七層模型與TCP/IP五層模型
OSI（開放式系統互聯）七層模型：物理層、數據鏈路層、網絡層、傳輸層、會話層、表示層、應用層
TCP/IP五層模型：物理層、數據鏈路層、網絡層、傳輸層、應用層
44、瀏覽器訪問Web服務器通信流程
當我們在瀏覽器中輸入http://www.baidu.com/為什么能打開百度的網頁，這段時間到底經歷了什么？
① 輸入網址，然后請求DNS服務器，把域名翻譯為IP地址（這個過程也可以通過ping命令測試）
② 有了百度的IP地址以后，客戶端就會向Web服務器端發起請求（底層是基於TCP的，但是傳輸的數據格式是基於HTTP協議的），通過HTTP協議，發起請求
③ Web服務器接收到剛才瀏覽器端發起的HTTP請求，對請求的數據進行處理（看看你想要哪些數據，如網頁、圖片、音樂、視頻等待），處理完成后，把數據組裝為HTTP協議格式，然后返回給瀏覽器客戶端。
④ 瀏覽器的客戶端，接收到服務器返回的超文本數據以后，通過瀏覽器的內核對數據進行渲染，然后顯示給用戶。
45、url
統一資源定位符，通俗理解就是用於定位網絡中資源地址，也就是我們常說的網址。
URL組成部分
① 協議部分 http://
② 域名部分 www.itheima.com
③ 資源路徑部分 /index.html
④ 查詢參數部分 [可選] /index.html?參數=參數值，如/indexhtml?page=1
46、面向對象
面向對象是相對於面向過程而言的。面向過程語言是一種基於功能分析的、以算法為中心的程序設計方法；而面
向對象是一種基於結構分析的、以數據為中心的程序設計思想。在面向對象語言中有一個有很重要東西，叫做類。
面向對象有三大特性：封裝、繼承、多態。
47. es為什么全文搜索這么快
https://www.cnblogs.com/dreamroute/p/8484457.html
https://www.jianshu.com/p/9c7d4bb3b093
像在mysql中模糊查找是不走索引的，查找速度相當慢
在es中，預先抓取數據，建立索引，通過FST壓縮技術，將索引緩存到內存中，索引查找的操作基本在內存中完成，速度很快。es為字段內容創建了倒排索引，內容直接指向唯一標識，
比如文檔ID，通過Term Index → Term Directionary → Posting List的方式進行查找，可以理解term index是一顆樹，就像字典里的索引頁一樣，A開頭的有哪些term，
分別在哪頁，而且這棵樹不會包含所有的term，它包含的是term的一些前綴。通過term index可以快速地定位到term dictionary的某個offset，然后從這個位置再往后順
序查找。Term Directionary
中將所有的term排序，二分法查找term，logN的查找效率。Posting list就是一個int數組，存儲了所有符合某個term的文檔id（唯一標識）。
像在mysql中模糊查找是不走索引的，查找速度相當慢
在es中，es為字段創建了倒排索引，內容直接指向唯一標識，比如文檔ID，通過Term Index → Term Directionary → Posting List的方式進行查找，
Elasticsearch分別為每個field都建立了一個倒排索引，Kate, John, 24, Female這些叫term，而[1,2]就是Posting List。Posting list就是一個int數組，存儲了所有符合某個term的文檔id（唯一標識）。可以理解term index是一顆樹，就像字典里的索引頁一樣，A開頭的有哪些term，分別在哪頁，而且這棵樹不會包含所有的term，它包含的是term的一些前綴。通過term index可以快速地定位到term dictionary的某個offset，然后從這個位置再往后順序查找。再結合FST的壓縮技術，可以使term index緩存到內存中。從term index查到對應的term dictionary的block位置之后，再去磁盤上找term。
有順序的id查找速度會更快，uuid會稍慢，不需要索引的字段最好指明，因為他是自動建立索引的
可以理解term index是一顆樹，就像字典里的索引頁一樣，A開頭的有哪些term，分別在哪頁，而且這棵樹不會包含所有的term，它包含的是term的一些前綴。通過term index可以快速地定位到term dictionary的某個offset，然后從這個位置再往后順序查找。再結合FST的壓縮技術，可以使term index緩存到內存中。從term index查到對應的term dictionary的block位置之后，再去磁盤上找term，大大減少了磁盤隨機讀的次數。
Elasticsearch為了能快速找到某個term，將所有的term排序，二分法查找term，logN的查找效率，就像通過字典樹查找一樣，這就是Term Dictionary。
48、property裝飾器
http://c.biancheng.net/view/4561.html
@property是python內置的一個裝飾器，作用是將一個方法變成屬性。
1、在使用@property裝飾器之后，可以使用 類.方法名 不帶括號的方式獲取其返回值（必須存在的），但是 @property 裝飾的函數，不能附帶除self之外的其他參數；
2、在使用@prop.setter裝飾器后，可以使用 類.方法名 來進行賦值，但是@prop.setter 裝飾的函數，只能有除了self之外的一個參數。
49、主要用過哪些技術棧
web框架django用的多，也用過flask和drf。一般關系型數據庫使用mysql，非關系型數據庫用過redis、mongodb，在之前的公司redis用的比較多。像耗時任務，一般就是celery+redis或者rabbitmq解耦出來異步執行，搜索功能的通常都是haystack+es。保持登錄狀態cookie、session和jwt里面session和jwt用的多。代碼管理用git。還有一些第三方庫
49、oauth2.0的四種認證模式
授權碼（authorization-code）
隱藏式（implicit）
密碼式（password）
客戶端憑證(client credentials)
https://blog.csdn.net/qq_37457564/article/details/107581986
50、mongodb和redis
都說redis緩存、mongodb數據庫，redis“緩存”的性質遠大於其“數據存儲“的性質，其中數據的增刪改查也只是像變量操作一樣簡單；MongoDB卻是一個“存儲數據”的系統，增刪改查可以添加很多條件，就像SQL數據庫一樣靈活
MongoDB使用JSON的變種BSON作為內部存儲的格式和語法。針對MongoDB的操作都使用JSON風格語法，客戶端提交或接收的數據都使用JSON形式來展現。對於項目的數據處理格式都是采用JSON的形式來處理的話，就很友好。mongodb也更適合大數據量存儲。 redis的tps比mongodb更高一點。在事務這一塊，雖然redis也挺弱，但是優於mongodb。
MongoDB和Redis都是NoSQL，采用結構型數據存儲。二者在使用場景中，存在一定的區別，這也主要由於
二者在內存映射的處理過程，持久化的處理方法不同。MongoDB建議集群部署，更多的考慮到集群方案，Redis
更偏重於進程順序寫入，雖然支持集群，也僅限於主-從模式。
https://www.cnblogs.com/java-spring/p/9488227.html
https://www.cnblogs.com/daofaziran/p/11013469.html
51、TPS和QPS
TPS：Transactions Per Second，意思是每秒事務數；QPS：Queries Per Second，意思是每秒查詢率，是一台服務器每秒能夠響應的查詢次數（數據庫中的每秒執行查詢sql的次數）
一、TPS：Transactions Per Second（每秒傳輸的事物處理個數），即服務器每秒處理的事務數。TPS包括一條消息入和一條消息出，加上一次用戶數據庫訪問。（業務TPS = CAPS × 每個呼叫平均TPS）
TPS是軟件測試結果的測量單位。一個事務是指一個客戶機向服務器發送請求然后服務器做出反應的過程。客戶機在發送請求時開始計時，收到服務器響應后結束計時，以此來計算使用的時間和完成的事務個數。
一般的，評價系統性能均以每秒鍾完成的技術交易的數量來衡量。系統整體處理能力取決於處理能力最低模塊的TPS值。
二、QPS：每秒查詢率QPS是對一個特定的查詢服務器在規定時間內所處理流量多少的衡量標准，在因特網上，作為域名系統服務器的機器的性能經常用每秒查詢率來衡量。
對應fetches/sec，即每秒的響應請求數，也即是最大吞吐能力。
52、跨域
我們使用django-cors-headers擴展來解決后端對跨域訪問的支持。
1、安裝django-cors-headers 2、注冊應用和中間件 3、設置白名單
跨域實現流程：
①瀏覽器會第一次先發送option請求詢問后端是否允許跨域，后端查詢白名單中是否有這兩個域名
②如果域名在白名單中則在相應結果中告知瀏覽器允許跨域
③瀏覽器第二次發送post請求，攜帶用戶登錄數據到后端，完成登錄驗證操作
53、celery
Celery 組件
Celery 扮演生產者和消費者的角色
Producer :
任務生產者. 調用 Celery API , 函數或者裝飾器, 而產生任務並交給任務隊列處理的都是任務生產者。
Celery Beat :
任務調度器. Beat 進程會讀取配置文件的內容, 周期性的將配置中到期需要執行的任務發送給任務隊列。
Broker :
消息代理, 隊列本身. 也稱為消息中間件.。接受任務生產者發送過來的任務消息, 存進隊列再按序分發給任務消費方(通常是消息隊列或者數據庫)。
Celery Worker :
執行任務的消費者, 通常會在多台服務器運行多個消費者, 提高運行效率。
Result Backend :
任務處理完成之后保存狀態信息和結果, 以供查詢。
通過task裝飾器實現任務，通過delay方法調用任務。
54、在前后端分離開發中，一般是前端重定向
55、為什么mongodb需要創建索引
加快查詢速度，進行數據的去重
56、索引的優缺點
優點：提高數據的查詢速度
缺點：犧牲了數據庫的插入和更新速度
mongodb20萬條數據（id,名字，年齡）查找id188888 1毫秒，名字無索引耗費100左右，名字建立索引一兩毫秒，年齡本來也是100毫秒左右，建立索引后比名字快點，也是1、2毫秒
57、mysql的解釋
其實就是explain
查看語句執行情況，會出一個日志信息，查看消耗的時間什么的
58、復合索引（mongodb）
有多個索引都包含查詢字段的時候：①當有若干個索引能適合查詢用到的key時，優化器會同時並行使用索引進行查詢，選擇最快索引。
②優化器會定期或定查詢次數重新進行最優索引的篩選
mysql中最左原則：
首先我們要知道最左匹配原則是什么？
最左匹配原則：最左優先，以最左邊的為起點任何連續的索引都能匹配上， MySQL會一直向右匹配直到遇到范圍查詢（>,<,between,like）就停止匹配。
個人對最左前綴的理解
MySQL中的索引可以以一定順序引用多列，這種索引叫作聯合索引。如User表的name和city加聯合索引就是(name,city)，而最左前綴原則指的是，如果查詢的時候查詢條件精確匹配索引的左邊連續一列或幾列，則此列就可以被用到。如下：
select * from user where name=xx and city=xx ; ／／可以命中索引
select * from user where name=xx ; // 可以命中索引
select * from user where city=xx ; // 無法命中索引
這里需要注意的是，查詢的時候如果兩個條件都用上了，但是順序不同，
如 city= xx and name ＝xx，那么現在的查詢引擎會自動優化為匹配聯合索引的順序，這樣是能夠命中索引的。
由於最左前綴原則，在創建聯合索引時，索引字段的順序需要考慮字段值去重之后的個數，較多的放前面。ORDER BY子句也遵循此規則。
索引index1:(a,b,c)，只會走a、a,b、a,b,c 三種類型的查詢，其實這里說的有一點問題，a,c也走，但是只走a字段索引，不會走c字段。
59、mongodb
a.網站數據：mongo非常適合實時的插入，更新與查詢，並具備網站實時數據存儲所需的復制及高度伸縮性。
b.緩存：由於性能很高，mongo也適合作為信息基礎設施的緩存層。在系統重啟之后，由mongo搭建的持久化緩存可以避免下層的數據源過載。
c.大尺寸、低價值的數據：使用傳統的關系數據庫存儲一些數據時可能會比較貴，在此之前，很多程序員往往會選擇傳統的文件進行存儲。
d.高伸縮性的場景：mongo非常適合由數十或者數百台服務器組成的數據庫。適合集群部署
e.用於對象及JSON數據的存儲：mongo的BSON數據格式非常適合文檔格式化的存儲及查詢。
用在應用服務器的日志記錄，查找起來比文本靈活，導出也很方便；存儲一些監控數據
游戲場景，使用 MongoDB 存儲游戲用戶信息，用戶的裝備、積分等直接以內嵌文檔的形式存儲，方便查詢、更新物流場景，使用 MongoDB 存儲訂單信息，訂單狀態在運送過程中會不斷更新，以 MongoDB 內嵌數組的形式來存儲，一次查詢就能將訂單所有的變更讀取出來。社交場景，使用 MongoDB 存儲存儲用戶信息，以及用戶發表的朋友圈信息，通過地理位置索引實現附近的人、地點等功能物聯網場景，使用 MongoDB 存儲所有接入的智能設備信息，以及設備匯報的日志信息，並對這些信息進行多維度的分析視頻直播，使用 MongoDB 存儲用戶信息、禮物信息
60、session共享問題如何解決
1、.把session加密后存在cookie中,每次session信息被寫在客服端,然后經瀏覽器再次提交到服務器。這個方案的優點無需額外的服務器資源;缺點是由於受http協議頭長度的限制，僅能夠存儲小部分的用戶信息，同時Cookie化的 Session內容需要進行安全加解密(如：采用DES、RSA等進行明文加解密;再由MD5、SHA-1等算法進行防偽認證)，另外它也會占用一定的帶寬資源，因為瀏覽器會在請求當前域名下任何資源時將本地Cookie附加在http頭中傳遞到服務器。我們知道Cookie是有長度限制的，而這也會限制Session數據的長度；Session數據本來都是服務端數據，而這個方案是讓這些服務端數據到了外部網絡及客戶端，因此存在安全性上的問題
2、session服務器，專門存儲session，還需要從服務器備份session，萬一服務器宕機，需要從服務器補充上。
3、redis共享session
61、jwt禁用問題
首先：jwt使用情況是使用兩個jwt，一個token用於登錄，一個refesh_token專門用於刷新token，token和refresh_token載荷中有個isfreshtoken=True/false判斷是哪個token。每次賬號密碼登錄刷新兩個token，前端自動調用接口使用refresh_token刷新token，refresh_token未過期且有user_id則刷新token。
針對修改密碼和禁用用戶賬號。mysql數據庫設置注銷或者刪除字段，對於注銷或者封號的賬號修改字段狀態，在登錄的時候會查詢賬號狀態。
通過白名單黑名單的方式。（將用戶id：新token存到數據庫里，過期時間就是token過期時間。如果用戶舊token登錄成功，先校驗是否在名單內，id沒在名單內，正常訪問視圖。如果id在名單內則校驗是否是存在數據庫中的新token，是則放行，不是則返回403（和修改密碼后的新token不一致，說明這是舊token，需要重新登錄，保證了舊token無法使用））。
將用戶id和更改密碼時間存儲redis，token登錄后，先校驗是否在名單內，然后校驗時間是否大於密碼更改時間，如果大於，說明是更改密碼后的新token，通過。如果小於密碼更改時間，則說明是舊token，返回403。對於refresh_token同樣查看redis的名單中是否有refresh_token的id，如果有，則校驗時間。名單中的各個key過期時間是refresh_token的過期時間，保證舊token和舊refresh_token不能用。注銷或者封號同樣將id和注銷時間存到名單中，保證舊的token不能用，需要登錄，登錄時會查詢mysql字段，無法登錄。
62、緩存
SQLAlchemy起到一定的本地緩存作用（sql奧克梅）
在同一請求中多次相同的查詢只查詢數據庫一次，SQLAlchemy做了本地緩存（類似Django中的Queryset查詢結果集）
視圖的響應結果（JSON），頁面（HTML）在代碼中加上@cache裝飾器，可以緩存
63、redis和mysql應用場景
redis基於內存，讀寫速度非常快，也支持持久化，有兩種持久化方式，但是容易受容量空間限制，雖然redis也有自己的緩存淘汰機制，但是比較受容量制約。
mysql基於磁盤，讀寫速度比redis慢，但是不易受容量空間限制。
應用場景：多數時候mysql為主，redis為輔，mysql做主存儲，redis做緩存，加快訪問速度，可以在需要高性能的部分，訪問量大的數據使用redis，不需要高性能的部分使用mysql。但是redis在使用時注意緩存雪崩、緩存穿透和緩存擊穿。
63、memcached和redis
mem可緩存圖片和視頻，redis支持更多的數據結構，redis可使用虛擬內存，redis可以持久化和災難恢復，redis支持主從數據備份，redis可以做消息隊列。我感覺圖片視頻存redis不划算，可以存mongodb中。（redis的Strings類型:一個String類型的value最大可以存儲512M）
64、31、你常用的Nginx模塊，用來做什么
rewrite模塊，實現重寫功能
access模塊：來源控制
ssl模塊：安全加密
ngx_http_gzip_module：網絡傳輸壓縮模塊
ngx_http_proxy_module 模塊實現代理
ngx_http_upstream_module模塊實現定義后端服務器列表
ngx_cache_purge實現緩存清除功能
65、緩存的使用
你可以緩存特定視圖的輸出、你可以僅僅緩存那些很難生產出來的部分、或者你可以緩存你的整個網站。
在setting文件中配置caches，指明緩存緩存到哪里，ip和端口。如果使用memcached，可以在多台機器上運行memcached服務，緩存共享（這些程序會把這幾個機器當做同一個緩存），在配置的時候location把所有ip、端口列出來就可以。（memcached在宕機時會丟失數據，所以只能是緩存解決方案，不能作為存儲方案，不能完全代替硬盤存儲）
可以做站點級緩存，緩存整個網站。把'django.middleware.cache.UpdateCacheMiddleware' 和 'django.middleware.cache.FetchFromCacheMiddleware' 添加到 MIDDLEWARE_CLASSES 設置里，update在最上面，fetch在最后。
單個view緩存。django.views.decorators.cache 定義了一個自動緩存視圖response（響應）的 cache_page裝飾器，直接將裝飾器掛在視圖上就可以
66、python設計模式
https://www.cnblogs.com/tangkaishou/p/9246353.html
https://www.jianshu.com/p/6a1690f0dd00
單例：目的是保證一個類只有一個實例 實現：基於__new__方法實現（推薦使用，方便），使用模塊，使用裝飾器（django的日志用到了單例）
工廠模式、建造者模式。。。
66、With文件操作，上下文管理器
當with體執行完將自動關閉打開的文件（with open在執行完后會自動關閉打開的文件，open還需要手動寫一行close代碼關閉文件）
實際上，在文件操作時，並不是不需要寫文件的關閉，而是文件的關閉操作在 with 的上下文管理器中的協議方法里已經寫好了。當文件操作執行完成后，
with語句會自動調用上下文管理器里的關閉語句來關閉文件資源。
==艾克sei特==
上下文管理器中有 __enter__ 和 __exit__ 兩個方法，以with為例子，__enter__ 方法會在執行 with 后面的語句時執行，一般用來處理操作前的內容。
比如一些創建對象，初始化等；__exit__ 方法會在 with 內的代碼執行完畢后執行，一般用來處理一些善后收尾工作，比如文件的關閉，數據庫的關閉等。
67、解決跨域問題
# 第一種
安裝django-cors-headers，注冊應用corsheaders，注冊中間件，跨域白名單
# 第二種 方法2:使用JSONP
使用Ajax獲取json數據時，存在跨域的限制。不過，在Web頁面上調用js的script腳本文件時卻不受跨域的影響，
JSONP就是利用這個來實現跨域的傳輸。因此，我們需要將Ajax調用中的dataType從JSON改為JSONP（相應的API也需要支持JSONP）格式。
jsonp只能用於get請求
#方案3.直接修改Django中的views.py文件,原理是修改請求頭
ACAO等於*
68、常見響應狀態碼
服務器向用戶返回的狀態碼和提示信息，常用的有：
1XX 表示請求被接受，並需要處理
100 初始請求已被接受，客戶端應當發送其余部分
101 服務器將遵從客戶的請求轉換到另外一種協議
2XX 請求成功，表示成功處理了請求
200 OK ：服務器成功返回用戶請求的數據
201 CREATED ：用戶新建或修改數據成功。
202 Accepted：表示請求已進入后台排隊。
3XX 重定向
301 （永久移動）請求的網頁已永久移動到新位置。服務器返回此響應（對 GET 或 HEAD 請求的響應）時，會自動將請求者轉到新的位置
302 （臨時移動）服務器目前從不同位置的網頁響應請求，但請求者應繼續使用原有位置來進行以后的請求
4XX 請求錯誤
400 INVALID REQUEST ：用戶發出的請求有錯誤。
401 Unauthorized ：用戶沒有權限。
403 Forbidden ：訪問被禁止。
404 NOT FOUND ：請求針對的是不存在的記錄。
406 Not Acceptable ：用戶請求的的格式不正確。
5XX 服務器錯誤
500 INTERNAL SERVER ERROR ：服務器發生錯誤。
500：（服務器內部錯誤）服務器遇到錯誤，無法完成請求
501：（尚未實施）服務器不具備完成請求的功能。例如，服務器無法識別請求方法時可能會返回此代碼
502：（錯誤網關）服務器作為網關或代理，從上游服務器收到無效響應
503：（服務不可用）服務器目前無法使用（由於超載或停機維護）。通常，這只是暫時狀態
504：（網關超時）服務器作為網關或代理，但是沒有及時從上游服務器收到請求
505：（HTTP 版本不受支持）服務器不支持請求中所用的 HTTP 協議版本