問題
說一下爬蟲反爬的思路
從數(shù)據的爬取和使用這兩個角度進行反爬蟲：
增大數(shù)據的爬取成本
- 數(shù)據訪問過于頻繁時，增加驗證碼等校驗機制
- 檢測到爬蟲時，對相關IP進行封禁、黑名單處理
- 限制一定時間內的訪問次數(shù)
增大數(shù)據的使用成本
- 對于文本類數(shù)據，在前端網頁對數(shù)據展示時，使用特殊的字體文件，在爬蟲
- 爬取到的數(shù)據（或部分數(shù)據）變成無法直接識別的亂碼
- 對于圖片類數(shù)據，可以圖片中添加水印
UserAgent中有哪些信息
以自己的瀏覽器的User-Agent為例：
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.90 Safari/537.36
主要包括了操作系統(tǒng)、瀏覽器名稱以及版本、渲染引擎。
使用IP進行爬蟲的判斷一定準確嗎
不一定。
對爬蟲程序進行識別，主要通過數(shù)據訪問頻率、User-Agent等請求標識符等進行識別。
對于爬蟲程序，可以通過使用IP池，并模仿正常的頻率，達到大量爬取數(shù)據的目的，此時IP難以識別出爬蟲。
對于正常用戶，在網絡不佳不斷請求數(shù)據或者打開多個頁面時，或者在某個使用公網IP的局域網內有多用戶同時訪問時，也可能出現(xiàn)類似爬蟲的行為，此時IP容易被誤判為爬蟲。
Python中如何獲取IP
socket.gethostbyname(socket_name)
Django的默認端口
8000
數(shù)據庫中如何部分模糊查詢
使用like關鍵字或者基于全文索引的查詢
like的效率如何
較低。
對于有索引的數(shù)據列，左模糊查詢會進行全表掃描（如：like ‘%java%’），效率較低；右模糊查詢會使用索引（如：like ‘java%’），效率相對較高。
全文索引的實現(xiàn)
相關數(shù)據結構
倒排索引（反向索引）。
在指定的列中（可以是多個），對每個單詞都保存這個單詞所在的文檔、在文檔中的位置。如果對多個列創(chuàng)建了全文索引，則會將這些列全部拼接成一個字符串，然后進行索引。使用輔助表information_schema.INNODB_FT_INDEX_TABLE來進行保存。
輔助表information_schema.INNODB_FT_INDEX_TABLE中的數(shù)據字段
| 字段名 | 作用 |
|---|---|
| WORD | 索引列中提取出的具體單詞 |
| FIRST_DOC_ID | 首次出現(xiàn)的文檔id |
| LAST_DOC_ID | 最后出現(xiàn)的文檔id |
| DOC_COUNT | 此單詞出現(xiàn)在 FULLTEXT 索引中的行數(shù) |
| DOC_ID | 包含單詞的行的文檔ID |
| POSITION | 該單詞在DOC_ID所標示的文檔中的位置 |
單詞的一些提取過濾的規(guī)則
-
不會使用在停用詞列表中的單詞。
停用詞列表：默認根據通用英語的使用來設置，也可以通過
ft_stopword_file來指定外部文件。 不使用長度不在指定的長度范圍內的單詞：
。
非英文字段的全文索引
對于英文的字段，可以通過空格來進行分詞。對于非英文的字段，如中文、日文等，則無法直接通過特殊字符進行分詞，需要依靠其他插件實現(xiàn)。
5.7.6之前，全文索引只支持英文全文索引，不支持中文全文索引，需要利用分詞器把中文段落預處理拆分成單詞，然后存入數(shù)據庫。5.7.6開始，MySQL內置了ngram全文解析器，用來支持中文、日文、韓文分詞。
對于非英文的字段，通過設置分詞的長度（單詞的粒度）來進行分詞。如設置粒度為2，則會把每2個字分成一個詞進行索引。
相關參考:
MySql 5.7 中文文檔- 24.32.12 INFORMATION_SCHEMA INNODB_FT_INDEX_TABLE表
高性能MySQL 第三版： 7.10 全文索引
介紹一下MySQL的不同引擎特點
| 引擎 | 特點 |
|---|---|
| InnoDB | 支持事務、支持行級鎖、聚集索引、采用MVCC支持高并發(fā) |
| MyISAM | 不支持事務、只支持表級鎖、支持全文索引、不支持并發(fā) |
為什么要使用事務，不使用的話會有什么后果
保證數(shù)據的一致性和操作的有效性，并方便數(shù)據的版本控制。具體可以聯(lián)系事務的ACID特性和隔離級別進行回答。
在并發(fā)的情況下，如果不使用事務，則非常容易出現(xiàn)各種諸如“不可重復讀”、“讀臟數(shù)據”等問題，難以保證操作的有效性。
在發(fā)生錯誤時，使用事務的話，能方便的進行RollBack操作，將進行到一半出錯的操作回退到操作前的狀態(tài)，不會將錯誤的數(shù)據寫入，導致數(shù)據的不一致。如A給B轉賬，如果在A的賬戶扣完錢以后出現(xiàn)錯誤，未能在B的賬戶中加上對應金額，不用事務的話，則需要手動撤銷掉錯誤前的操作。
需要退回到某個數(shù)據庫版本時，使用事務能方便地根據這一段時間內的操作進行UnDo回滾，在備份和恢復時較為方便。
項目中如何使用事務的
數(shù)據操作的時候都會使用，try{……} catch(){……} finally{……}，正常操作時在try中提交，出錯時在finally中回滾。
介紹一下Nginx的作用
反向代理、負載均衡
安卓端在與服務器通信時如何校驗權限
OAuth（開放授權）標準，如：Spring-auth2。
或者基于Token實現(xiàn)一套校驗機制。
Servlet自帶Session嗎
Servlet不自帶Session。
-
Session的創(chuàng)建Session的創(chuàng)建是在調用Request對象的getSession(true)方法時創(chuàng)建的，一般在第一次獲取Session對象時創(chuàng)建。getSession(boolean create)：在當前會話沒有Session時，如果create值為true，則會創(chuàng)建一個Session對象，如果為false則會返回null。當前會話已有對應的Session的話就直接返回這個Session。 -
Session在服務器端的存儲Session保存于內存中。 -
Session在客戶端的存儲在
Cookie中保存Session的id。
不同用戶會話的Session是如何區(qū)分的
Session之間通過jsessionid作為其id（用于唯一標識的主鍵），通過jsessionid區(qū)分不同的Session。
客戶端在首次請求服務器時，服務器會創(chuàng)建本次會話的Session，并返回一個保存了jsessionid的Cookie。在本次會話之后的請求中，都會帶上這個Cookie以標識本次會話的Session。
如果客戶端禁用了Cookie，則可以將jsessionid以url參數(shù)的形式發(fā)送給服務器。
在服務器中，Session默認的過期時間是30分鐘，但是保存其id的Cookie的默認生命周期就是會在瀏覽器關閉以后被銷毀。所以，更多的情況下表現(xiàn)為關閉瀏覽器后再次訪問時Session就”沒了“，其實是因為再次訪問時沒有攜帶上一次會話的jsessionid，所以無法找到這個Session。
Token的數(shù)據格式
本質是由服務器生成的一串字符串。
JWT：JSON Web Token
JWT是目前應用較廣的一種Token解決方案。主要由三部分組成：Header 頭部、Payload 有效載荷、Signature 簽名。
Header
- typ：type，token的類型，一般為
JWT - alg：algorithm，加密的算法
Payload
- iss：Issuer，發(fā)行者
- sub：Subject，主題
- aud：Audience，受眾
- exp：Expiration Time，過期時間
- nbf：Not Before，最早的生效時間
- iat：Issued At，發(fā)布時間
- jti：JWT ID，JWT的唯一標識符
- 自定義數(shù)據
Signature
加密后的Header和Payload數(shù)據，用于校驗。
參考：
總結
雖然面的是Java開發(fā)的崗，但是也問到了python，一是自己簡歷中的項目有python相關，二是面試官所在部門的技術棧中除了Java外也包含了python，所以面試官可能也比較感興趣。
整體面試的題目來說，范圍較廣，深度一般。涉及的知識面較廣，除了Java外還涉及到了python相關的很多內容，但在每一個知識領域內問的都不算很深，基本上也是結合簡歷中的項目稍微做了一下拓展深入。
就個人而言，一是很多底層的機制還需要加強理解，像Servlet和Session、全文索引的實現(xiàn)這些問題當時都回答的不是很準確。其次便是要加強應用方面的認識，對于項目中的一些技術和解決方案，不僅要會用還要從“為什么要用這個”、“不用會怎么樣”、“其他的方案如何”等角度去思考、去拓展，所幸爬蟲那塊之前項目中稍有了解，也算回答的上來。
