傳統的 session 流程
瀏覽器發起請求登陸
服務端驗證身份，生成身份驗證資訊，儲存在服務端，並且告訴瀏覽器寫入 cookie
瀏覽器發起請求獲取使用者資料，此時 cookie 內容也跟隨這傳送到伺服器
伺服器發現 cookie 中有身份資訊，驗明正身
伺服器返回該使用者的使用者資料
jwt 流程
瀏覽器發起請求登陸
服務端驗證身份，根據演算法，將使用者識別符號打包生成 token, 並且返回給瀏覽器
瀏覽器發起請求獲取使用者資料，把剛剛拿到的 token 一起傳送給伺服器
伺服器發現資料中有 token，驗明正身
伺服器返回該使用者的使用者資料
你發現了嗎？好些並沒有什麼區別，除了 session 需要服務端儲存乙份，而 jwt 不需要
但實際上區別大了去了
session 儲存在服務端占用伺服器資源，而 jwt 儲存在客戶端
session 儲存在 cookie 中，存在偽造跨站請求偽造攻擊的風險
session 只存在一台伺服器上，那麼下次請求就必須請求這台伺服器，不利於分布式應用
儲存在客戶端的 jwt 比儲存在服務端的 session 更具有擴充套件性
…1.與其他使用者狀態儲存方案比較
一般開發中使用者狀態使用session或者cookie，兩種方式各種利弊。
session:在inproc模式下容易丟失，並且引起併發問題。如果使用sqlserver或者sqlserver模式又消耗了效能
cookie則容易將一些使用者資訊暴露，加解密同樣也消耗了效能。
redis採用這樣的方案解決了幾個問題，
1.redis訪問速度快。
2.使用者資料不容易丟失。
3.使用者多的情況下容易支援集群。
5.能夠實現使用者一處登入。（通過**實現，後續介紹）
6.支援持久化。（當然可能沒什麼用）
備忘錄系統 需求篇
設計資料庫 表結構 設計前後端互動介面 實現伺服器端和客戶端的邏輯 1.只支援單個使用者 2.實現針對文章的增刪查改 3.實現針對標籤的增刪查改 客戶端 網頁的形式 伺服器端 http協議 資料庫 mysql 展現備忘錄列表頁面 展現備忘錄詳情頁面 管理備忘錄頁面 例如 當使用者在客戶端 網頁 執行...
備忘錄模式
備忘錄模式 memento 在不破壞封裝性的前提下，捕獲乙個物件的內部狀態，並在該物件之外儲存這個狀態。這樣以後就可將該物件恢復到原先儲存的狀態。originator 發起人 負責建立乙個備忘錄memento，用以記錄當前時刻它的內部狀態，並可以使用備忘錄恢復內部狀態。originator可根據需要...
備忘錄模式
先從物件導向的三大特徵之一封裝說起。物件導向的封裝簡單點說就是把狀態 資料 和行為 操作這些資料的方法 放到一起，構成乙個單元，通常叫做類。乙個物件的行為是事先確定好的 靜態 一些指令碼，如果物件的狀態相同，物件看起來就是一樣的。所以當我們需要把乙個物件的某一時刻儲存起來，那麼只需要儲存它在那個時刻...