面試過部分童鞋,遇到的一些技術問題總結

爲什麼要用三層或者多層結構(包括MVC結構)?

好多人說自己寫過三層結構的網站,或者多層結構,結構基本上模仿的petshop。但是問問他們爲什麼要做成三層結構,有什麼好處呢?爲什麼不寫在一起呢?個人認爲有幾個好處
1. 三層結構降低耦合,方便大型系統的分工。(大多數人會回答這個)
2. 提供代碼的重用度。
3. 封裝變化,減少因爲變化帶來的代碼變動。這個原則是建立在普遍認爲UI的變動會強於底層業務邏輯的變動頻率,否則的話,就難以封裝變化。
4. 方便單元測試。如果代碼糅合在一起,就不好單元測試了,有了問題不好找,只能慢慢調試。
5. 代碼更加健壯和便於維護。

多層結構和單一的糅合在一起哪個運算會快一些?

很多人回答多層結構會提高運行的效率,個人認爲這個是不對的,同等的邏輯和算法,分層會帶來效率的損失。但是了代碼的健壯,可以犧牲一些性能。

如何解決高併發的問題?

初級的高併發
1. 提高算法的性能,特別是訪問頻率比較高的部分的執行效率。
2. 系統中合理的使用資源的分配,儘可能介紹鎖的使用,包括代碼中的鎖,共享資源的鎖和數據庫鎖。
3. 算法中儘可能減少對數據庫和磁盤的使用,合理的使用內存。
4. 針對實時性不太強的數據,使用服務器端的緩存,減少對數據庫的訪問。
5. 針對靜態的資源,圖片、css、js等資源使用客戶端緩存。
6. 把一些變化不太大的內容做成靜態頁面
7. 使用ajax異步加載的技術
8. 提高硬件水平。
中級的高併發
1. 把數據庫和服務器放在不同的服務器上。來分擔服務器壓力。
2. 使用單例模式或者其他的內存來緩存一些動態的數據,而不是每次從數據庫中去讀取。
3. 合理的使用數據庫的索引和視圖的方式來提高數據的查詢效率
高級的高併發
1. 針對應用服務器,考慮分佈式和負載均衡的方式來架構,讓系統可以水平的去擴展。
2. 對業務進行分解。
2. 使用單獨的緩存服務器,常見的是redis和memcache。
3. 使用CDN的方式來緩存靜態內容,提高靜態CND的擊中率。
4. 數據庫分庫和分表
5. 業務策略,合理的去分攤高峯期的出現。
6. 針對需要統一使用的資源建立單獨的分佈式結構,比如建立會話(session)服務器。
初級和中級的以提高單臺服務器的處理能力爲目標,高級的以業務可以分佈式橫向擴展爲目標。

常見的安全問題和解決方式

sql注入
過濾SQL的敏感字符,可以結合一些過濾類庫和敏感過濾的方式進行處理。使用EF一類的orm框架可以避免常見的SQL注入攻擊。

cc攻擊
1. 對於一些耗費資源的訪問進行緩存,比如檢索等等。
2. 對一些耗費資源的訪問進行次數上的限制過濾。
3. 使用CC防火牆進行過濾

DDOS攻擊
沒別的辦法,使用防火牆,隱匿真實的源IP

css跨站攻擊
1. 過濾掉一些js或者其他的腳本敏感字符,比如把一些敏感的script把半角過濾成全角等等。
2. 一些後臺的操作,儘可能用post的方式來操作,比如刪除,而不是通過鏈接的方式來操作,防止鏈接攻擊。

服務器漏洞
1. 及時的打補丁
2. 合理的使用服務器的防火牆,把非必要的端口全部關閉。
3. 不在服務器上進行過多的其他操作。
4. 卸載所有沒必要的軟件

弱口令攻擊
1. 限制口令測試測試
2. 使用粘連的圖形驗證碼
3. 對於一些非常嚴重的權限,可以限制口令登錄的IP
4. 定時提醒客戶更換口令

上傳漏洞
1. 上傳的內容以字節的方式保存在數據庫。
2. 嚴格檢查上傳的擴展名和mine頭
3. 把上傳的內容限制在獨立的服務器上
4. 取消上傳目錄的運行和其他的權限
5. 使用類似阿里雲的OSS存儲對象來保存上傳的內容。

發佈了125 篇原創文章 · 獲贊 324 · 訪問量 92萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章