1.COOKIE使用和優缺點

1.1 cookie原理： 使用者名稱+密碼

　　。cookie是儲存在使用者瀏覽器端，使用者名稱和密碼等明文資訊

1.2 session使用原理

　　。session是儲存在伺服器端的一段字串,相當於字典的key

1.使用者向伺服器傳送使用者名稱和密碼。 2.驗證伺服器後，相關資料（如使用者角色，登入時間等）將儲存在當前會話中。 3.伺服器向用戶返回session_id，session資訊都會寫入到使用者的Cookie。 4.使用者的每個後續請求都將通過在Cookie中取出session_id傳給伺服器。 5.伺服器收到session_id並對比之前儲存的資料，確認使用者的身份。

1.3 session使用缺點

CPU
 主機板
顯示卡
記憶體條（把硬碟中的程式讀取到記憶體中，就變成了程序） 
硬碟（1T， 500G）（可執行的程式碼儲存在硬碟中，就是程式） 
IO操作（把硬碟中或者網路中的資料讀取到記憶體中就是IO操作）

session預設儲存在登入的那臺伺服器的記憶體中。 1.這種模式最大的問題是，沒有分散式架構，無法支援橫向擴充套件。 2.如果使用一個伺服器，該模式完全沒有問題。 3.但是，如果它是伺服器群集或面向服務的跨域體系結構的話，則需要一個統一的session資料庫庫 來儲存會話資料實現共享， 4.這樣負載均衡下的每個伺服器才可以正確的驗證使用者身份。

1.4 常用解決session方法

1.一種解決方案是通過持久化session資料，寫入資料庫或檔案持久層等。 2.收到請求後，驗證服務從持久層請求資料。 3.依賴於持久層的資料庫或者問題系統，會有單點風險，如果持久層失敗，整個認證體系都會掛掉。

第一種：沒有session持久化 　　沒有分散式架構，無法支援橫向擴充套件 　　session預設儲存在記憶體中，如果把程式碼部署在多臺機器上，session儲存到了其中某一臺機器的記憶體中 　　使用者如果在A機器上登入，只有A機器的記憶體中存了這個session的key，如果請求nginx路由到B 　　機器，B機器記憶體中沒有這個session資料，就需要從新登入 第二種：寫入資料庫或檔案持久層（ session+redis ） 　　解決了橫向擴充套件問題 　　資料庫持久層出現問題，所有叢集都沒辦法登入， 單點故障 　　如果資料放到mysql中，使用者量過大，查詢很慢，效率很低