單體應用，使用者登入認證完（前端的賬號密碼加密和庫里的加密做對比），將使用者資訊存session裡面，然後tomcat向客戶端傳送乙個jsessionid 來記錄此次會話，此後每次請求都會將jsessionid 傳送給後台，然後拿到此次會話的session,然後取出使用者資訊，以此來保持登入狀態。
缺點：
1. 單一伺服器，部署多台session不共享
解決方案：通過nginx 的ip_hash策略
每個請求按訪問 ip 的 hash 結果分配，這樣每個訪客固定訪問乙個後端伺服器，可以解決 session 的問題（這樣由於客戶第一次訪問服務端到a服務後，這個客戶以後的請求，nginx都會給他**到a伺服器，就不用考慮session共享的問題）。 例如：
如果 使用者 一開始 就訪問ip 192.168.5.21 埠80 的伺服器 以後請求 都只訪問 ip 192.168.5.21 埠80
分布式架構，前後分離，登入資訊通過session存前置的伺服器，重寫了sessionmanager(session管理器)，使用者認證後，伺服器生成乙個sessionid來記錄此次會話狀態送到前端，此後前端的每個請求都要帶上此次sessionid送到請求體裡面，後端通過sessionmanager來拿到此次會話，然後通過固定使用者key取到使用者資訊。
缺點：前置部署多台，session不共享，由於是前後分離，在後台服務先投產的情況下，當使用者一登入後，此時前置服務重啟，session被清掉，由於沒有session了，就在服務端取不到使用者資訊，所以使用者狀態就為未登入。就算用nginx的ip_hash策略也無法解決此問題。
解決方案：利用redis實現分布式session
將使用者資訊存在redis裡面，服務端頒發的session_id作為key，使用者資訊作為value，存入redis，就算後台服務端重啟後，前端傳送sessionid，後台再從redis 通過key(sessionid)去取出使用者資訊，來維持登入狀態。
由於redis一般要做集群，先有機房a和機房b 2個哨兵集群，2個哨兵之間得redis資料不共享怎麼辦
跨機房session共享解決方案：
暫時略過
微服務架構，單獨的統一認證服務，校驗完使用者資訊後，頒發令牌token 送給前端，前端每次請求帶上token ,然後在閘道器處進行認證，取出使用者資訊，再進行base64加密，將加密後的使用者資訊塞入request裡面，**到相應的服務,然後每個服務利用springboot的handlerinterceptor進行解密，反序列化成物件後在存入request 這樣寫業務**時直接從request裡面去取使用者物件就行了。
深入理解Android Binder機制的幾點
android系統binder機制中的四個元件 client，server，service manager和binder驅動程式。1.client server和service manager實現在使用者空間中，binder驅動程式實現在核心空間中 2.binder驅動程式和service mana...
深入理解共享記憶體機制
共享記憶體可以說是最有用的程序間通訊方式，也是最快的ipc形式。是針對其他通訊機制執行效率較低而設計的。兩個不同程序a b共享記憶體的意思是，同一塊物理記憶體被對映到程序a b各自的程序位址空間。程序a可以即時看到程序b對共享記憶體中資料的更新，反之亦然。由於多個程序共享同一塊記憶體區域，必然需要某...
深入理解Java多型機制
目錄 1，多型的概念？2，存在的條件？3，案列解析？4，應用場景？1，多型的概念 父類引用指向子類物件，通俗點就是，在編譯時不繫結是什麼方法，根據你傳進來的值，是什麼就會執行什麼。2.存在條件 第一，要有繼承 第二，要有方法的重寫 第三，父類引用指向子類物件 3，案列解析 好好體會以下這個案例，通過...