COOKIE使用以及sessions使用和優缺點

https://www.cnblogs.com/xiaonq/p/11094480.html
1.1 cookie原理： 使用者名稱+密碼
coo0kie是儲存在使用者瀏覽器端，使用者名稱和密碼等明文

第一種：沒有session持久化
1.沒有分散式架構，無法支援橫向擴充套件
2.session預設儲存在記憶體中，如果把程式碼部署在多臺機器上，session儲存到了其中某一臺機器的記憶體中
3.使用者如果在A機器上登入，只有A機器的記憶體中存了這session的key，如果請求nginx路由到B機器，B機器記憶體中沒有這個session資料，就需要從新登入

1.2 session使用原理
session是儲存在伺服器端的一段字串,相當於字典的key

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

1.3 session使用缺點

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

1.4 常用解決session方法

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

第一種：沒有session持久化
1.沒有分散式架構，無法支援橫向擴充套件
2.session預設儲存在記憶體中，如果把程式碼部署在多臺機器上，session儲存到了其中某一臺機器的記憶體中
3.使用者如果在A機器上登入，只有A機器的記憶體中存了這session的key，如果請求nginx路由到B機器，B機器記憶體中沒有這個session資料，就需要從新登入

第二種：寫入資料庫或檔案持久層
1.解決了橫向擴充套件問題
2.資料庫持久層出現問題，所有叢集都沒辦法登入， 單點故障
3.如果資料放到mysql中，使用者量過大，查詢很慢，效率很低