python後端面試
面試題如下
筆者在7月份遇到的面試題如下
1. 二分查詢/演算法原理/資料結構
二分查詢法
key_num
list
def binary_search(key_num,list)
mid=len(list)/2
if list[mid] > key_num:
binary_search(key_mun,list[:mid])
elif list[mid] < key_num:
binary_search(key_mun,list[:mid])
else:
print(binary_search[mid])
2. mongodb 面試題
mongo 是非關係行的資料庫(nosql)
1.mongo 無複雜性的鎖以及事物出理方面的操作
2. 在collection中,資料庫名+集合名叫做名字空間。也就是一個集合的完整名
3.mongodb的結構介紹
資料庫中儲存的物件設計bson,一種類似json的二進位制檔案,由鍵值對組成
4 .資料庫的整體結構
鍵值對–》文件–》集合–》資料庫
5. 分析器在MongoDB中的作用是什麼?
MongoDB中包括了一個可以顯示資料庫中每個操作效能特點的資料庫分析器。通過這個分析器你可以找到比預期慢的查詢(或寫操作);利用這一資訊,比如,可以確定是否需要新增索引。
6. MongoDB支援儲存過程嗎?如果支援的話,怎麼用?
MongoDB支援儲存過程,它是javascript寫的,儲存在db.system.js表中。
7.MongoDB在A:{B,C}上建立索引,查詢A:{B,C}和A:{C,B}都會使用索引嗎?
不會,只會在A:{B,C}上使用索引。
10.如果一個分片(Shard)停止或很慢的時候,發起一個查詢會怎樣?
如果一個分片停止了,除非查詢設定了“Partial”選項,否則查詢會返回一個錯誤。如果一個分片響應很慢,MongoDB會等待它的響應。
適用場合:
網站資料:Mongo非常適合實時的插入,更新與查詢,並具備網站實時資料儲存所需的複製及高度伸縮性。
快取:由於效能很高,Mongo也適合作為資訊基礎設施的快取層。在系統重啟之後,由Mongo搭建的持久化快取層可以避免下層的資料來源 過載。
大尺寸,低價值的資料:使用傳統的關係型資料庫儲存一些資料時可能會比較昂貴,在此之前,很多時候程式設計師往往會選擇傳統的檔案進行儲存。
高伸縮性的場景:Mongo非常適合由數十或數百臺伺服器組成的資料庫。Mongo的路線圖中已經包含對MapReduce引擎的內建支援。
用於物件及JSON資料的儲存:Mongo的BSON資料格式非常適合文件化格式的儲存及查詢。
3. redis面試題
- 用處(快取/佇列 包括Pub、Sub/計數器/排行榜等)
- 基本操作與資料型別
- 訊息佇列 且與其它訊息佇列的區別
- 主從備份
- 當機如何處理
- 持久化及原理(原生持久化 & 結合Mysql等資料庫持久化)
- 是否可以作為資料庫?作為資料庫有哪些問題?
- 叢集化
- 資料超過記憶體如何處理
- 事務與分散式鎖機制
- 快取失效策略
- 其它
redis 一般用來做快取 讀寫性好且能做讀寫分離同時支援多種型別 如 list dict sootedset(可做實時的排序 如遊戲的實時分數更新) hash
redis 支援事務性的操作
1.redis常見效能問題和解決方案:
1).Master寫記憶體快照,save命令排程rdbSave函式,會阻塞主執行緒的工作,當快照比較大時對效能影響是非常大的,會間斷性暫停服務,所以Master最好不要寫記憶體快照。
2).Master AOF持久化,如果不重寫AOF檔案,這個持久化方式對效能的影響是最小的,但是AOF檔案會不斷增大,AOF檔案過大會影響Master重啟的恢復速度。Master最好不要做任何持久化工作,包括記憶體快照和AOF日誌檔案,特別是不要啟用記憶體快照做持久
化,如果資料比較關鍵,某個Slave開啟AOF備份資料,策略為每秒同步一次。
3).Master呼叫BGREWRITEAOF重寫AOF檔案,AOF在重寫的時候會佔大量的CPU和記憶體資源,導致服務load過高,出現短暫服務暫停現象。
4). Redis主從複製的效能問題,為了主從複製的速度和連線的穩定性,Slave和Master最好在同一個區域網內
2. mySQL裡有2000w資料,redis中只存20w的資料,如何保證redis中的資料都是熱點資料
- redis 記憶體資料集大小上升到一定大小的時候,就會施行資料淘汰策略(回收策略)。redis 提供 6種資料淘汰策略:
- volatile-lru:從已設定過期時間的資料集(server.db[i].expires)中挑選最近最少使用的資料淘汰
- volatile-ttl:從已設定過期時間的資料集(server.db[i].expires)中挑選將要過期的資料淘汰
- volatile-random:從已設定過期時間的資料集(server.db[i].expires)中任意選擇資料淘汰
- allkeys-lru:從資料集(server.db[i].dict)中挑選最近最少使用的資料淘汰
- allkeys-random:從資料集(server.db[i].dict)中任意選擇資料淘汰
- no-enviction(驅逐):禁止驅逐資料
3.Redis是單程式單執行緒的
- redis利用佇列技術將併發訪問變為序列訪問,消除了傳統資料庫序列控制的開銷
4.redis 最適合的場景
- (1)會話快取(Session Cache)
- (2)全頁快取(FPC)
token
(3)佇列
list
(4)排行榜/計數器
sorted set
(5)釋出/訂閱
抖音的釋出 點贊等
最後(但肯定不是最不重要的)是Redis的釋出/訂閱功能。釋出/訂閱的使用場景確實非常多。我已看見人們在社交網路連線中使用,還可作為基於釋出/訂閱的指令碼觸發器,甚至用Redis的釋出/訂閱功能來建立聊天系統!(不,這是真的,你可以去核實)。
5.redis 持久化
做快照
6.redis 主從哨兵設定
設定主從 以防資料丟失
4. 大資料併發處理
找出 重複次數最多的電話號碼
思路:1.將電話列表進行桶排序
2.拿到桶 [0,1,0,0,5,3]
list= [1,4,3,5,2]
buket=[0]*(max(list)+1)
for i in list:
buket[i]+=1
new_list=[]
for k in range(len(buket)):
if buket[k] != 0:
for j in range(buket[k]):
new_list.append(k)
啟用numpy 進行資料比較
import numpy as np
a=np.array([buket])
b=np.argsort(a)
print (b) [0 4 2 1 3] 說明 a[3]是最大的 a[0] 是最小值
迭代器的引入,readlines 程式池 多執行緒及攜程
4. 交換,路由 閘道器 內外網
交換&路由
- 交換機主要是用於組建區域網,而路由器則是負責讓主機連線外網
- 最初的交換機工作在OSI開放式系統互聯模型的資料鏈路層,也就是第二層,而路由器則工作在OSI模型的網路層。
- 交換機是根據MAC地址轉發資料幀,而路由器則是根據IP地址來轉發IP資料包/分組
為了簡單地說明路由器的工作原理,現在我們假設有這樣一個簡單的網路。如圖所示,A、B、C、D四個網路通過路由器連線在一起。
現在我們來看一下在如圖所示網路環境下路由器又是如何發揮其路由、資料轉發作用的。現假設網路A中一個使用者A1要向C網路中的C3使用者傳送一個請求訊號時,訊號傳遞的步驟如下:
第1步:使用者A1將目的使用者C3的地址C3,連同資料資訊以資料幀的形式通過集線器或交換機以廣播的形式傳送給同一網路中的所有節點,當路由器A5埠偵聽到這個地址後,分析得知所發目的節點不是本網段的,需要路由轉發,就把資料幀接收下來。
第2步:路由器A5埠接收到使用者A1的資料幀後,先從報頭中取出目的使用者C3的IP地址,並根據路由表計算出發往使用者C3的最佳路徑。因為從分析得知到 C3的網路ID號與路由器的C5網路ID號相同,所以由路由器的A5埠直接發向路由器的C5埠應是訊號傳遞的最佳途經。
第3步:路由器的C5埠再次取出目的使用者C3的IP地址,找出C3的IP地址中的主機ID號,如果在網路中有交換機則可先發給交換機,由交換機根據 MAC地址表找出具體的網路節點位置;如果沒有交換機裝置則根據其IP地址中的主機ID直接把資料幀傳送給使用者C3,這樣一個完整的資料通訊轉發過程也完成了。
閘道器
- 閘道器(Gateway)就是一個網路連線到另一個網路的“關口”。
按照不同的分類標準,閘道器也有很多種。TCP/IP協議裡的閘道器是最常用的,在這裡我們所講的“閘道器”均指TCP/IP協議下的閘道器。
大家都知道,從一個房間走到另一個房間,必然要經過一扇門。同樣,從一個網路向另一個網路傳送資訊,也必須經過一道“關口”,這道關口就是閘道器。顧名思義,閘道器(Gateway)就是一個網路連線到另一個網路的“關口”。
所以說,只有設定好閘道器的IP地址,TCP/IP協議才能實現不同網路之間的相互通訊
5. liunx 的抓包?
tcpdump -i ens33 port 25 -w msg.pcap
6. 網路程式設計
7. 慢查詢的作用
慢查詢的開啟 是為了分析sql語句 如:查詢過慢的語句 分析sql語句 以及優化mysql的索引等等
分析MySQL語句查詢效能的方法除了使用 EXPLAIN 輸出執行計劃,還可以讓MySQL記錄下查詢超過指定時間的語句,我們將超過指定時間的SQL語句查詢稱為“慢查詢”。
8. nginx
nginx 負載均衡:
upstream myapp1 {
ip_hash;
server localhost:18080;
server localhost:18081;
server localhost:18082;
}
server {
listen 8000;
location / {
proxy_pass http://myapp1;
}
}
(1)【客戶端層】到【反向代理層】的負載均衡,是通過“DNS輪詢”實現的;
(2)【反向代理層】到【站點層】的負載均衡,是通過“nginx”實現的;
(3)【站點層】到【服務層】的負載均衡,是通過“服務連線池”實現的;
(4)【資料層】的負載均衡,要考慮“資料的均衡”與“請求的均衡”兩個點,常見的方式有“按照範圍水平切分”與“hash水平切分”。
nginx是如何實現高併發的
一個主程式,多個工作程式,每個工作程式可以處理多個請求
每進來一個request,會有一個worker程式去處理。但不是全程的處理,處理到可能發生阻塞的地方,比如向上遊(後端)伺服器轉發request,並等待請求返回。那麼,這個處理的worker繼續處理其他請求,而一旦上游伺服器返回了,就會觸發這個事件,worker才會來接手,這個request才會接著往下走。
由於web server的工作性質決定了每個request的大部份生命都是在網路傳輸中,實際上花費在server機器上的時間片不多。這是幾個程式就解決高併發的祕密所在。即@skoo所說的webserver剛好屬於網路io密集型應用,不算是計算密集型。
9. 分散式系統
分散式系統:多個能獨立執行的計算機(稱為結點)組成。各個結點利用計算機網路進行資訊傳遞,從而實現共同的“目標或者任務”。
在分散式系統中:
1、應用可以按業務型別拆分成多個應用,再按結構分成介面層、服務層;我們也可以按訪問入口分,如移動端、PC端等定義不同的介面應用;
2、資料庫可以按業務型別拆分成多個例項,還可以對單表進行分庫分表;
3、增加分散式快取、搜尋、檔案、訊息佇列、非關係型資料庫等中介軟體;
很明顯,分散式系統可以解決集中式不便擴充套件的弊端,我們可以很方便的在任何一個環節擴充套件應用,就算一個應用出現問題也不會影響到別的應用。
隨著微服務Spring Cloud & Docker的大熱,及國內開源分散式Dubbo框架的重生,分散式技術發展非常迅速。
分散式系統雖好,也帶來了系統的複雜性,如分散式事務、分散式鎖、分散式session、資料一致性等都是現在分散式系統中需要解決的難題,雖然已經有很多成熟的方案,但都不完美。分散式系統也增加了開發測試運維成本,工作量增加,分散式系統管理不好反而會變成一種負擔。
10. mysql 優化 左查詢 右查詢的意義
mysql優化
1. Mysql中主要的兩種儲存引擎: MyISAM 和 InnoDB
2. 分庫分表
3. 索引
4. (1)普通索引(Index):最基本的索引,它沒有任何限制。
4. (2)唯一索引(UniqueIndex):它與前面的普通索引類似,不同的就是:索引列的值必須唯一,但允許有空值。如果是組合索引,則列值的組合必須唯一。
4. (3)主鍵索引(PrimaryIndex):它是一種特殊的唯一索引,不允許有空值(唯一索引允許)。主鍵索引可以作為外來鍵,唯一索引不可以,並且每個表只能由一個主鍵索引。
4. (4)全文索引(FullTextIndex):在生成這種型別的索引時,MySQL將把在文字中出現的所有單詞建立為一份清單,查詢操作將根據這份清單去檢索有關的資料記錄,全文索引只可建立在BLOB、TEXT、VARCHAR、CHAR等特殊型別上。
4. (5)組合索引(聯合索引、複合索引):多個列組合成一個索引,組織索引遵循最左字首原則,即組合索引中最先出現的列要出現在查詢語句中,索引才會生效。
組合索引是先對第一列進行排序,第一列相同時再對第二列排序……
組合索引的不嚴謹檢索過程就是先根據第一個索引找到對應的資料,再根據第二個索引找,一直這樣下去
4. 快取
左查詢 以左側為基準點
右查詢 以右側為基準點
11. mvc mvvm
mvc
12. docker
名詞 | 描述 |
Docker 映象 | Docker映象是用於建立Docker容器的模板 |
Docker 容器 | 容器是獨立執行的一個或一組應用 。 |
Docker 客戶端 | Docker客戶端通過命令列或者其他工具使用Docker API 與 Docker的守護程式進行通訊 |
Docker主機 | 一個物理或者虛擬的機器用於執行Docker守護程式和容器 |
Docker倉庫 | Docker倉庫用來儲存映象 , 可以理解為程式碼控制中的程式碼倉庫 |
Docker Machine | Docker Machine 是一個簡化的Docker安裝的命令列工具 , 通過一個簡單的命令列即可在相應的平臺上安裝Docker |
13. 二叉樹
14. https http的區別 xss攻擊
15. 非同步同步
非同步的使用場景:
1、不涉及共享資源,或對共享資源只讀,即非互斥操作
2、沒有時序上的嚴格關係
3、不需要原子操作,或可以通過其他方式控制原子性
4、常用於IO操作等耗時操作,因為比較影響客戶體驗和使用效能
5、不影響主執行緒邏輯
同步:一直等任務完成後才會進行下一步的操作,故不適用於需要使用者一直等待的操作,如郵件傳送等
同步的好處:
1、同步流程對結果處理通常更為簡單,可以就近處理。
2、同步流程對結果的處理始終和前文保持在一個上下文內。
3、同步流程可以很容易捕獲、處理異常。
4、同步流程是最天然的控制過程順序執行的方式。
16. 樂觀鎖悲觀鎖 死鎖,以及死鎖的條件
17. 資料庫面試題
18.微服務
19.多程式多執行緒 協程
程式 中可以有多個執行緒 執行緒中可以又多個協程
程式:對系統而言,一個任務就是一個程式,多程式會產生多個任務,有各自不同的程式號。
執行緒為核心態的
協程是使用者態的 故切換時消耗代價少
部分參考轉載他人的csdn
…未完待續。。。。。。
相關文章
- python後端面試題Python後端面試題
- python後端面試題答案(僅參考)Python後端面試題
- JAVA後端面試《Spring》Java後端面試Spring
- PHP後端面試85問PHP後端面試
- 2018春節後前端面試小記前端面試
- 大小廠必問Java後端面試題(含答案)Java後端面試題
- 三年半Java後端面試經歷Java後端面試
- 前端面試前端面試
- 前端面試(4)之zoom一面沒後續前端面試OOM
- 【面試】前端面試題前端面試題
- 前端面試題前端面試題
- 前端面試集合前端面試
- 前端面試大全前端面試
- 前端面試自查前端面試
- 前端面試系列前端面試
- JAVA後端面試100 Q&A之第一篇Java後端面試
- java後端面試八股文,42歲程式設計師面試Java後端面試程式設計師
- 前端面試錦囊前端面試
- 前端面試百問前端面試
- 前端面試題一前端面試題
- 前端面試題整理前端面試題
- 前端面試之HTML前端面試HTML
- 前端面試題目前端面試題
- 前端面試彙總前端面試
- 前端面試二(CSS)前端面試CSS
- 前端面試之JS前端面試JS
- 前端面試9:HTTP前端面試HTTP
- 前端面試4:DOM前端面試
- 前端面試手記前端面試
- 前端面試(css部分)前端面試CSS
- ## 前端面試之websocket前端面試Web
- 前端面試之BFC前端面試
- 【前端面試】instanceof原理前端面試
- 【前端面試題】2023年前端面試真題之Vue篇前端面試題Vue
- Java面經 面試經驗 網際網路公司面試經驗 後端面試經驗Java面試後端
- 前端面試題-display篇前端面試題
- 前端面試-模板編譯前端面試編譯
- 荔枝FM前端面試題前端面試題