一.redis的適用場景?
1、緩存——熱數(shù)據(jù)
select 數(shù)據(jù)庫前查詢redis，有的話使?redis數(shù)據(jù)，放棄select 數(shù)據(jù)庫，沒有的話，
select 數(shù)據(jù)庫，然后將數(shù)據(jù)插?redis
update或者delete數(shù)據(jù)庫錢，查詢redis是否存在該數(shù)據(jù)，存在的話先刪除redis中數(shù)據(jù)，
然后再update或者delete數(shù)據(jù)庫中的數(shù)據(jù)
2、計數(shù)器
3、隊列
4、位操作（?數(shù)據(jù)處理）
5、分布式鎖與單線程機制
6、最新列表
7、排?榜
什么是分布式鎖?
分布式鎖是控制分布式系統(tǒng)之間同步訪問共享資源的一種方式。
在分布式系統(tǒng)中，常常需要協(xié)調(diào)他們的動作。
如果不同的系統(tǒng)或是同一個系統(tǒng)的不同主機之間共享了一個或一組資源
，那么訪問這些資源的時候，
往往需要互斥來防止彼此干擾來保證一致性
在這種情況下，便需要使用到分布式鎖。
實現(xiàn)分布式鎖的方式
1.基于數(shù)據(jù)庫實現(xiàn)分布式鎖
2.基于緩存（redis，memcached，tair）實現(xiàn)分布式鎖
3.基于Zookeeper實現(xiàn)分布式鎖
二.反爬有哪些策略，你是如何克服的？
1. 限制IP地址單位時間的訪問次數(shù)
減少單位時間的訪問次數(shù)，減低采集效率
2. 屏蔽ip
使?代理ip
3. ?戶登錄才能訪問?站內(nèi)容
模擬?戶提交登錄表單
4. header User-Agent 檢查?戶所?客戶端的種類和版本
設(shè)置User-Agent
5. Referer 是檢查此請求由哪?來，通?？梢宰鰣D?的盜鏈判斷
?定義Referer字段
6. Cookies
?站可能會檢測 Cookie 中 session_id 的使?次數(shù)，如果超過限制，
就觸發(fā)反爬策略
定時向?標?站發(fā)送不帶 Cookies 的請求，提取響應(yīng)中 Set-cookie
字段信息并保存。爬取??時，把存儲起來的 Cookies 帶?
Headers 中
7. 動態(tài)加載
?站使? ajax 動態(tài)加載內(nèi)容
可以先截取 ajax 請求分析?下，有可能根據(jù) ajax 請求構(gòu)造出相應(yīng)
的 API 請求的 URL 就可以直接獲取想要的內(nèi)容，通常是 json 格式，
反?還不?去解析 HTML。
然?，很多時候 ajax 請求都會經(jīng)過后端鑒權(quán)，不能直接構(gòu)造 URL
獲取。這時就可以通過 PhantomJS+Selenium 模擬瀏覽器?為，抓
取經(jīng)過 js 渲染后的??
三.集群與分布式的區(qū)別 ？
集群是個物理形態(tài)，分布式是個?作?式
分布式是指將不同的業(yè)務(wù)分布在不同的地?。 ?集群指的是將?臺服務(wù)器集中
在?起，實現(xiàn)同?業(yè)務(wù)。
四.鑒權(quán)
是指驗證?戶是否擁有訪問系統(tǒng)的權(quán)利
常?的鑒權(quán)有四種：
HTTP Basic Authentication
session-cookie
Token 驗證
OAuth(開放授權(quán))
詳情鏈接url:
https://blog.csdn.net/wang839305939/article/details/78713124/
五. Mongodb與Mysql的區(qū)別
Mysql是關(guān)系型數(shù)據(jù)庫，Mongodb是?關(guān)系型（nosql)數(shù)據(jù)庫
Mongodb的適?范圍
1.更?的寫?負載
默認情況下，MongoDB更側(cè)重?數(shù)據(jù)寫?性能，??事務(wù)安全，MongoDB很適合業(yè)務(wù)系
統(tǒng)中有?量“低價值”數(shù)據(jù)的場景。但是應(yīng)當避免在?事務(wù)安全性的系統(tǒng)中使?MongoDB，
除?能從架構(gòu)設(shè)計上保證事務(wù)安全。
2.?可?性
MongoDB的復(fù)副集(Master-Slave)配置?常簡潔?便，此外，MongoDB可以快速響應(yīng)的
處理單節(jié)點故障，?動、安全的完成故障轉(zhuǎn)移。這些特性使得MongoDB能在?個相對不穩(wěn)
定（如云主機）的環(huán)境中，保持?可?性。
3.數(shù)據(jù)量很?或者未來會變得很?
依賴數(shù)據(jù)庫(MySQL)?身的特性，完成數(shù)據(jù)的擴展是較困難的事，在MySQL中，當?個單
達表到5-10GB時會出現(xiàn)明顯的性能降級，此時需要通過數(shù)據(jù)的?平和垂直拆分、庫的拆分
完成擴展，使?MySQL通常需要借助驅(qū)動層或代理層完成這類需求。?MongoDB內(nèi)建了
多種數(shù)據(jù)分?的特性，可以很好的適應(yīng)?數(shù)據(jù)量的需求。
4.基于位置的數(shù)據(jù)查詢
MongoDB?持?維空間索引，因此可以快速及精確的從指定位置獲取數(shù)據(jù)。
5.表結(jié)構(gòu)不明確，且數(shù)據(jù)在不斷變?
在?些傳統(tǒng)RDBMS中，增加?個字段會鎖住整個數(shù)據(jù)庫/表，或者在執(zhí)??個重負載的請求
時會明顯造成其它請求的性能降級。通常發(fā)?在數(shù)據(jù)表?于1G的時候（當?于1TB時更
甚）。 因MongoDB是?檔型數(shù)據(jù)庫，為?結(jié)構(gòu)貨的?檔增加?個新字段是很快速的操作，
并且不會影響到已有數(shù)據(jù)。另外?個好處當業(yè)務(wù)數(shù)據(jù)發(fā)?變化時，是將不在需要由DBA修改
表結(jié)構(gòu)
