收錄一些印象比較深刻的問題
1.不用session和cookie 怎麼實現半小時內自動登錄
JS端的localStorage:HTML5提供的本地存儲方式（可以稱爲“鍵值對”數據庫）
https://www.jb51.net/article/96092.htm
或者更好的選擇-token
Token
解決問題：服務器上存儲所有用戶的seesion id 導致服務器壓力大 和 集中存儲session id 可能導致丟失單點失敗 的問題
Header + userID + 加密算法（SHA-256）+服務器自己的密鑰——簽名——附在信息上
服務器接收到請求時 用算法和密鑰 再對Header 和 userID 進行 加密 和 密鑰
看服務器生成的 簽名 和 發送過來信息中的簽名是否一樣，一樣則爲已經登陸過
https://www.cnblogs.com/moyand/p/9047978.html
tokens 是多用戶下處理認證的最佳方式。
tokens特性：
1.無狀態、可擴展
2.支持移動設備
3.跨程序調用
4.安全
基於Token的身份驗證的過程如下:
1.用戶通過用戶名和密碼發送請求。
2.程序驗證。
3.程序返回一個簽名的token 給客戶端。
4.客戶端儲存token,並且每次用於每次發送請求。
5.服務端利用過濾器驗證token並返回數據。
2.分角色登陸
我的回答是：登陸判斷用戶權限，在Controller 中按權限跳轉到相應的頁面，並且頁面放在WEB-INF中，不允許別人直接訪問
其實可以用spring-security
https://blog.csdn.net/liushangzaibeijing/article/details/81220610
https://blog.csdn.net/larger5/article/details/81047869
——依賴着一系列servlet filter來提供不同的安全特性
——基於Spring的企業應用系統提供聲明式的安全訪問控制解決方式的安全框架
3.攔截器和過濾器的區別
都體現了AOP思想，都能實現權限檢查、日誌記錄
| 攔截器 | 過濾器 |
| 依賴於spring容器 | 依賴於servlet容器 |
| Web application swing程序中都可以 | 只能用在Web程序中 |
| 實現上基於Java的反射機制，屬於面向切面編程（AOP）的一種運用 | 基於函數回調，可以對幾乎所有請求進行過濾 |
| 一個攔截器實例在一個controller生命週期之內可以多次調用，但只能對controller請求進行攔截 | 一個過濾器實例只能在容器初始化時調用一次 |
| 可以深入到方法前後、異常拋出前後 | 只在Servlet前後 |
| 可以訪問action上下文、值棧裏的對象 | 不可以 |
| 可以獲取IOC容器中的各個bean | 不可以 |
https://blog.csdn.net/xiaoyaotan_111/article/details/53817918
https://blog.csdn.net/chenleixing/article/details/44573495
4.分佈式鎖
分佈式，多臺計算機合作，處理不同的部分
（對應，集羣就是多臺做同樣的事情；部署在不同服務器上的同一個子系統應做負載均衡）
https://blog.csdn.net/jiangyu1013/article/details/80417961
在分佈式系統中，大家不是在一個JVM裏了，不可能用synchronized來在多個子系統之間實現鎖
（線程間對資源進行鎖——synchronized/lock，而分佈式系統中是屬於進程之間共享的資源）
分佈式鎖，是指在分佈式的部署環境下，通過鎖機制來讓多客戶端互斥的對共享資源進行訪問
分佈式鎖實現：Memcached、Redis、Zookeeper
樂觀鎖——引入版本號來實現
悲觀鎖——排它鎖——InnoDB引擎 + 有索引的字段——行級鎖
5.WebSocket
https://www.runoob.com/html/html5-websocket.html
WebSocket 是 HTML5 開始提供的一種在單個 TCP 連接上進行全雙工通訊的應用層協議。
因此寫在js上
瀏覽器和服務器只需要完成一次握手，兩者之間就直接可以創建持久性的連接，並進行雙向數據傳輸。
——HTTP請求可能包含較長的頭部，其中真正有效的數據可能只是很小的一部分
——能更好的節省服務器資源和帶寬，並且能夠更實時地進行通訊
請求頭部：Upgrade: websocket——升級到websocket協議
服務器返回101——協議升級完成，後續的數據交互都按照新的協議來
數據以幀形式傳送
https://www.jianshu.com/p/a5aee2cfe6d4
6.前後端分離
核心思想是前端HTML頁面通過AJAX調用後端的RESTFUL API接口並使用JSON數據進行交互。
未分離時代（各種耦合）：
MVC框架（我直接就答了MVC框架....），JSP+Servlet形式
——前端不可避免遇到後端的代碼——例如<% java代碼%>的形式
——JSP中嵌入了java後端的代碼
問題：
開發過程的前後端互相矛盾
（可以理解爲學校項目大多都是這種——所有學校的項目大多都是學生負責某一模塊的前端後端
——而不是前後端分離這樣的形式進行小組合作）
半分離時代：
前端負責開發頁面，通過接口（Ajax）獲取數據，採用Dom操作對頁面進行數據綁定，最終是由前端把頁面渲染出來。
這也就是Ajax與SPA應用（單頁應用）結合的方式。
步驟如下：
（1）瀏覽器請求，CDN返回HTML頁面；
（2）HTML中的JS代碼以Ajax方式請求後臺的Restful接口；
（3）接口返回Json數據，頁面解析Json數據，通過Dom操作渲染頁面；
【Restful接口：
每個資源都有一個唯一的資源標識符 & 對資源的各種操作不會改變資源標識符
——http://127.0.0.1/user 同一個url 但是可以對應 增刪改查操作
區別在於http方式——GET POST PUT DELETE
spring-mvc 中 @RequestMapping(method = RequestMethod.POST)
https://www.jianshu.com/p/7893169a7c93
】
半分離原因：
前後端需要協商ajax的數據——同步輸出 or 異步json渲染
特點：
前端不會嵌入任何後臺代碼，前端專注於HTML、CSS、JS的開發，不依賴於後端，自己還能夠模擬Json數據來渲染頁面，發現Bug。
缺點：
js冗餘，頁面渲染複雜且緩慢，甚至卡頓
業務複雜的話，一個頁面可能需要多次請求才能完成頁面的渲染——PC端可以，但移動端可以嗎？
——需要前後端分離
分離：
上面提到的SPA可以算是分離——但SPA實際中很少見
我們需要
- 前端負責view和controller層
- 後端只負責model層，業務處理與數據持久化等
問題來了——前端咋懂Controller層呀——node.js
node.js適合運用在高併發、I/O密集、少量業務邏輯的場景。
——NodeJs的作用在MVC中相當於C（控制器）
爲什麼用將nodejs當做是前後端的橋樑？
後端的數據，前端不能直接使用；前端因爲排序、篩選和頁面展示的需求 要對數據進行二次處理。
處理放在前端的話 會浪費瀏覽器性能——因此交給nodejs 這個中間層
因此瀏覽器不再直接請求JSP的API，而是：
1）瀏覽器請求服務器端的NodeJS；
2）NodeJS再發起HTTP去請求JSP；
3）JSP依然原樣API輸出JSON給NodeJS；
4）NodeJS收到JSON後再渲染出HTML頁面；
5）NodeJS直接將HTML頁面flush到瀏覽器；
這樣，瀏覽器得到的就是普通的HTML頁面，而不用再發Ajax去請求服務器了。
nodejs優勢：
適配性up —— 界面展示邏輯由node層自己維護 不同端即不同nodejs
響應速度up —— 不需要瀏覽器對數據進行處理 而是由 nodejs 中間層去做
（前端發出多個異步請求，nodejs中間層做這些請求的代理，統一給後端；
同樣，後端的數據 在nodejs中間層 統一裝好 一起給前端）
性能up —— 單一職責原則
異步與模板統一
—— 頁面整體是有 幾十個HTML 片段拼裝而成
PHP 是同步include 這些片段，而node可以同步 ，讀文件可以並行
https://blog.csdn.net/fuzhongmin05/article/details/81591072
6.