1. 程式人生 > >Session和Cookie的應用場景和區別

Session和Cookie的應用場景和區別

一、cookie機制和session機制的區別
*************************************************************************************
具體來說cookie機制採用的是在客戶端保持狀態的方案,而session機制採用的是在伺服器端保持狀態的方案。
同時我們也看到,由於才伺服器端保持狀態的方案在客戶端也需要儲存一個標識,所以session機制可能需要藉助於cookie機制來達到儲存標識的目的,
但實際上還有其他選擇,比如說重寫 URL和隱藏表單域。


*************************************************************************************
二、會話cookie和持久cookie的區別
*************************************************************************************


如果不設定過期時間,則表示這個cookie生命週期為瀏覽器會話期間,只要關閉瀏覽器視窗,cookie就消失了。
這種生命期為瀏覽會話期的cookie被稱為會話cookie。會話cookie一般不儲存在硬碟上而是儲存在記憶體裡。


如果設定了過期時間(setMaxAge(60*60*24)),瀏覽器就會把cookie儲存到硬碟上,關閉後再次開啟瀏覽器,這些cookie依然有效直到超過設定的過期時間。
儲存在硬碟上的cookie可以在不同的瀏覽器程序間共享,比如兩個IE視窗。而對於儲存在記憶體的cookie,不同的瀏覽器有不同的處理方式。(在IE下測試通過)


*************************************************************************************
三、如何利用Cookie實現自動登入
*************************************************************************************


當用戶在某個網站註冊後,就會收到一個惟一使用者ID的cookie。客戶後來重新連線時,這個使用者ID會自動返回,
伺服器對它進行檢查,確定它是否為註冊使用者且選擇了自動登入,從而使使用者務需給出明確的使用者名稱和密碼,就可以訪問伺服器上的資源。


*************************************************************************************
四、如何根據使用者的愛好定製站點
*************************************************************************************


網站可以使用cookie記錄使用者的意願。對於簡單的設定,網站可以直接將頁面的設定儲存在cookie中完成定製。
然而對於更復雜的定製,網站只需僅將一個惟一的識別符號傳送給使用者,由伺服器端的資料庫儲存每個識別符號對應的頁面設定。


*************************************************************************************
五、cookie的傳送
*************************************************************************************


1.建立Cookie物件
2.設定最大時效
3.將Cookie放入到HTTP響應報頭


如果你建立了一個cookie,並將他傳送到瀏覽器,
預設情況下它是一個會話級別的cookie:儲存在瀏覽器的記憶體中(伺服器自動建立一個cookie並將jsessionId作為key,sessionId的值作為value傳送到客戶端瀏覽器記憶體中),
使用者退出瀏覽器之後被刪除。如果你希望瀏覽器將該cookie儲存在磁碟上,則需要使用maxAge,並給出一個以秒為單位的時間。將最大時效設為0則是命令瀏覽器刪除該cookie。
傳送cookie需要使用HttpServletResponse的addCookie方法,將cookie插入到一個Set-Cookie HTTP請求報頭中。
由於這個方法並不修改任何之前指定的Set-Cookie報頭,而是建立新的報頭,因此我們將這個方法稱為是addCookie,而非 setCookie。
同樣要記住響應報頭必須在任何文件內容傳送到客戶端之前設定。


*************************************************************************************
六、cookie的讀取
*************************************************************************************


1.呼叫request.getCookie
要獲取有瀏覽器傳送來的cookie,需要呼叫HttpServletRequest的getCookies方法,這個呼叫返回Cookie物件的陣列,對應由HTTP請求中Cookie報頭輸入的值。


2. 對陣列進行迴圈,呼叫每個cookie的getName方法,直到找到感興趣的cookie為止,cookie與你的主機(域)相關,
而非你的 servlet或JSP頁面。因而,儘管你的servlet可能只發送了單個cookie,你也可能會得到許多不相關的cookie。
例如:(login.jsp頁面cookie實現使用者名稱userName填寫)
login.jsp:


<%
String username = "";
        //從客戶端讀取硬碟中的cookie檔案
         Cookie[] cookies = request.getCookies();
       if(cookies == null){
           username = "";
        }
       else{
          for (int i = 0; i < cookies.length; i++){
                 if ("USERNAME".equalsIgnoreCase(cookies[i].getName())){
                   username = cookies[i].getValue();
               }
       }
%>
  
<form name="login" method="post" action="login.do">
      <td width="100%" bgcolor="#CCCCCC" colspan="2">
   <p align="left">使用者名稱<br>
              <input type="text" name="username" value= "<%=username%>">
      </p>
      <p align="left">密 碼 <br>
              <input type="password" name="password">
      </p>
       <p align="left">
         <input type="submit" name="Submit" value="確定">
         <input name="reset" type="reset" value="取消">
       </p>
</form>


LoginAction:
              //將正確userName放入c1物件,並用"USERNAME"做key標識
             Cookie c1= new Cookie("USERNAME",logindto.getUsername());
               //如果不設定時間,則cookie為會話cookie,不寫入客戶端硬碟
               c1.setMaxAge(60*60*24);   
                response.addCookie(c1);


*************************************************************************************
七、如何使用cookie檢測初訪者
*************************************************************************************


A.呼叫HttpServletRequest.getCookies()獲取Cookie陣列
B.在迴圈中檢索指定名字的cookie是否存在以及對應的值是否正確
C.如果是則退出迴圈並設定區別標識
D.根據區別標識判斷使用者是否為初訪者從而進行不同的操作


*************************************************************************************
八、使用cookie檢測初訪者的常見錯誤
*************************************************************************************


不能僅僅因為cookie陣列中不存在在特定的資料項就認為使用者是個初訪者。如果cookie陣列為null,客戶可能是一個初訪者,
也可能是由於使用者將 cookie刪除或禁用造成的結果。但是,如果陣列非null,也不過是顯示客戶曾經到過你的網站或域,並不能說明他們曾經訪問過你的servlet。
其它servlet、JSP頁面以及非Java Web應用都可以設定cookie,依據路徑的設定,其中的任何cookie都有可能返回給使用者的瀏覽器。


正確的做法是判斷cookie陣列是否為空且是否存在指定的Cookie物件且值正確。


*************************************************************************************
九、使用cookie屬性的注意問題
*************************************************************************************


屬性是從伺服器傳送到瀏覽器的報頭的一部分;但它們不屬於由瀏覽器返回給伺服器的報頭。


因此除了名稱和值之外,cookie屬性只適用於從伺服器輸出到客戶端的cookie;伺服器端來自於瀏覽器的cookie並沒有設定這些屬性。
因而不要期望通過request.getCookies得到的cookie中可以使用這個屬性。
這意味著,你不能僅僅通過設定cookie的最大時效,發出它,在隨後的輸入陣列中查詢適當的cookie,讀取它的值,修改它並將它存Cookie,從而實現不斷改變的cookie值。


*************************************************************************************
十、如何使用cookie記錄各個使用者的訪問計數
*************************************************************************************


1.獲取cookie陣列中專門用於統計使用者訪問次數的cookie的值
2.將值轉換成int型
3.將值加1並用原來的名稱重新建立一個Cookie物件
4.重新設定最大時效
5.將新的cookie輸出


*************************************************************************************
十一、session在不同環境下的不同含義
*************************************************************************************


session,中文經常翻譯為會話,其本來的含義是指有始有終的一系列動作/訊息,比如打電話是從拿起電話撥號到結束通話電話這中間的一系列過程可以稱之為一個 session。
然而當session一詞與網路協議相關聯時,它又往往隱含了“面向連線”和/或“保持狀態”這樣兩個含義。


session在Web開發環境下的語義又有了新的擴充套件,它的含義是指一類用來在客戶端與伺服器端之間保持狀態的解決方案。有時候Session也用來指這種解決方案的儲存結構。


*************************************************************************************
十二、session的機制
*************************************************************************************


session機制是一種伺服器端的機制,伺服器使用一種類似於散列表的結構(也可能就是使用散列表)來儲存息。


但程式需要為某個客戶端的請求建立一個session的時候,伺服器首先檢查這個客戶端的請求裡是否包含了一個session標識-稱為session id,
如果已經包含一個session id則說明以前已經為此客戶建立過session,
伺服器就按照session id把這個session檢索出來使用(如果檢索不到,可能會新建一個,這種情況可能出現在服務端已經刪除了該使用者對應的session物件,
但使用者人為地在請求的URL後面附加上一個JSESSION的引數)。如果客戶請求不包含session id,
則為此客戶建立一個session並且同時生成一個與此session相關聯的session id,這個session id將在本次響應中返回給客戶端儲存。


*************************************************************************************
十三、儲存session id的幾種方式
*************************************************************************************


A.儲存session id的方式可以採用cookie,這樣在互動過程中瀏覽器可以自動的按照規則把這個標識傳送給伺服器。
B.由於cookie可以被人為的禁止,必須有其它的機制以便在cookie被禁止時仍然能夠把session id傳遞迴伺服器,經常採用的一種技術叫做URL重寫,
就是把session id附加在URL路徑的後面,附加的方式也有兩種,一種是作為URL路徑的附加資訊,另一種是作為查詢字串附加在URL後面。
網路在整個互動過程中始終保持狀態,就必須在每個客戶端可能請求的路徑後面都包含這個session id。
C.另一種技術叫做表單隱藏欄位。就是伺服器會自動修改表單,新增一個隱藏欄位,以便在表單提交時能夠把session id傳遞迴伺服器。


*************************************************************************************
十四、session什麼時候被建立
*************************************************************************************


一個常見的誤解是以為session在有客戶端訪問時就被建立,然而事實是直到某server端程式呼叫HttpServletRequest.getSession(true)這樣的語句時才被建立。


注意如果JSP沒有顯示的使用 <% @page session="false"%> 關閉session,
則JSP檔案在編譯成Servlet時將會自動加上這樣一條語句 HttpSession session = HttpServletRequest.getSession(true);這也是JSP中隱含的session物件的來歷。


由於session會消耗記憶體資源,因此,如果不打算使用session,應該在所有的JSP中關閉它。


*************************************************************************************
十五、session何時被刪除
*************************************************************************************


session在下列情況下被刪除:
A.程式呼叫HttpSession.invalidate()
B.距離上一次收到客戶端傳送的session id時間間隔超過了session的最大有效時間
C.伺服器程序被停止


再次注意關閉瀏覽器只會使儲存在客戶端瀏覽器記憶體中的session cookie失效,不會使伺服器端的session物件失效,除非此時Server端剛好session失效時間到了。


*************************************************************************************
十六、URL重寫有什麼缺點
*************************************************************************************


對所有的URL使用URL重寫,包括超連結,form的action,和重定向的URL。每個引用你的站點的URL,
以及那些返回給使用者的URL(即使通過間接手段,比如伺服器重定向中的Location欄位)都要新增額外的資訊。


這意味著在你的站點上不能有任何靜態的HTML頁面(至少靜態頁面中不能有任何連結到站點動態頁面的連結)。
因此,每個頁面都必須使用servlet或 JSP動態生成。即使所有的頁面都動態生成,如果使用者離開了會話並通過書籤或連結再次回來,會話的資訊都會丟失,
因為儲存下來的連結含有錯誤的標識資訊-該URL後面的SESSION ID已經過期了。


*************************************************************************************
十七、使用隱藏的表單域有什麼缺點
*************************************************************************************


     僅當每個頁面都是有表單提交而動態生成時,才能使用這種方法。單擊常規的<A HREF..>超文字連結並不產生表單提交,
因此隱藏的表單域不能支援通常的會話跟蹤,只能用於一系列特定的操作中,比如線上商店的結賬過程。


*************************************************************************************
十八、會話跟蹤的基本步驟
*************************************************************************************


1.訪問與當前請求相關的會話物件
2.查詢與會話相關的資訊
3.儲存會話資訊
4.廢棄會話資料


*************************************************************************************
十九、getSession()/getSession(true)、getSession(false)的區別
*************************************************************************************


getSession()/getSession(true):當session存在時返回該session,否則新建一個session並返回該物件
getSession(false):當session存在時返回該session,否則不會新建session,返回null。


*************************************************************************************
二十、如何將資訊於會話關聯起來
*************************************************************************************


setAttribute方法會替換上次setAttribute中設定的值;如果想要在不提供任何代替的情況下移除某個值,
則應使用 removeAttribute。這個方法會觸發所有實現了HttpSessionBindingListener介面的值的valueUnbound方法。


*************************************************************************************
二十一、會話屬性的型別有什麼限制嗎
*************************************************************************************


通常會話屬性的型別只要是Object就可以了。除了null或基本型別,如int,double,boolean。
如果要使用基本型別的值作為屬性,必須將其轉換為相應的封裝類物件。


*************************************************************************************
二十二、如何廢棄會話資料
*************************************************************************************
A.只移除自己編寫的servlet建立的資料:
    呼叫removeAttribute(“key”)將指定鍵關聯的值廢棄
B.刪除整個會話(在當前Web應用中):
    呼叫invalidate,將整個會話廢棄掉。這樣做會丟失該使用者的所有會話資料,而非僅僅由我們servlet或JSP頁面建立的會話資料
C.將使用者從系統中登出並刪除所有屬於他(或她)的會話
    呼叫logOut,將客戶從Web伺服器中登出,同時廢棄所有與該使用者相關聯的會話(每個Web應用至多一個)。這個操作有可能影響到伺服器上多個不同的Web應用。


*************************************************************************************
二十三、使用isNew來判斷使用者是否為新舊使用者的錯誤做法
*************************************************************************************


public boolean isNew()方法如果會話尚未和客戶程式(瀏覽器)發生任何聯絡,即伺服器端程式還沒有返回客戶端時,
則這個方法返回true,這一般是因為會話是新建的,不是由輸入的客戶請求所引起的。但如果isNew返回false,
只不過是說明他之前曾經訪問Web應用,並不代表他們曾訪問過我們的servlet或JSP頁面。


因為session是與使用者相關的,在使用者之前訪問的每一個頁面都有可能建立了會話。因此isNew為false只能說使用者之前訪問過該Web應用,
session可以是當前頁面建立,也可能是由使用者之前訪問過的頁面建立的。正確的做法是判斷某個session中是否存在某個特定的key且其value是否正確。(待測試)


*************************************************************************************
二十四、Cookie的過期和Session的超時有什麼區別
*************************************************************************************


會話的超時由伺服器來維護,它不同於Cookie的失效日期。


首先,會話一般基於駐留記憶體的cookie不是持續性的cookie,因而也就沒有截至日期。即使擷取到JSESSIONID cookie,併為它設定一個失效日期傳送出去。
瀏覽器會話和伺服器會話也會截然不同。


*************************************************************************************
二十五、session cookie和session物件的生命週期是一樣的嗎
*************************************************************************************


當用戶關閉了瀏覽器雖然session cookie已經消失,但session物件仍然儲存在伺服器端,直到其失效時間。


*************************************************************************************
二十六、是否只要關閉瀏覽器,session就消失了
*************************************************************************************


程式一般都是在使用者做log off的時候發個指令去刪除session,然而瀏覽器從來不會主動在關閉之前通知伺服器它將要被關閉,
因此伺服器根本不會有機會知道瀏覽器已經關閉。伺服器會一直保留這個會話物件直到它處於非活動狀態超過設定的間隔為止。


之 所以會有這種錯誤的認識,是因為大部分session機制都使用會話cookie來儲存session id,而關閉瀏覽器後這個session id就消失了,
再次連線到伺服器時也就無法找到原來的session。如果伺服器設定的cookie被儲存到硬碟上,或者使用某種手段改寫瀏覽器發出的 HTTP請求報頭,
把原來的session id傳送到伺服器,則再次開啟瀏覽器仍然能夠找到原來的session。恰恰是由於關閉瀏覽器不會導致session被刪除,迫使伺服器為session 設定了一個失效時間,
當距離客戶上一次使用session的時間超過了這個失效時間時,伺服器就可以認為客戶端已經停止了活動,才會把session刪除以節省儲存空間。


由此我們可以得出如下結論:
關閉瀏覽器,只會是瀏覽器端記憶體裡的session cookie消失,但不會使儲存在伺服器端的session物件消失,同樣也不會使已經儲存到硬碟上的持久化cookie消失。




補充:那如何做到在瀏覽器關閉時刪除session呢 ?


嚴格的講,做不到這一點。可以做一點努力的辦法是在所有的客戶端頁面裡使用javascript程式碼window.oncolose來監視瀏覽器的關閉動作,
然後向伺服器傳送一個請求來刪除session。但是對於瀏覽器崩潰或者強行殺死程序這些非常規手段仍然無能為力。


*************************************************************************************
二十七、開啟兩個瀏覽器視窗訪問應用程式會使用同一個session還是不同的session
*************************************************************************************


通常session cookie是不能跨視窗使用的,當你新開了一個新的瀏覽器視窗進入相同頁面時,系統會賦予你一個新的session id,這樣我們資訊共享的目的就達不到了。
對session來說是隻認id不認人,因此不同的瀏覽器,不同的視窗開啟方式以及不同的cookie儲存方式(如會話cookie和持久cookie)都會對這個問題的答案有影響。


(在IE下測試,開啟兩個瀏覽器(不是新建視窗,是直接啟動兩次瀏覽器),得到的SessionID也是不一樣)


要 實現跨視窗的會話跟蹤,我們可以先把session id儲存在persistent cookie中(通過設定session的最大有效時間),然後在新視窗中讀出來,
就可以得到上一個視窗的session id了,這樣通過session cookie和persistent cookie的結合我們就可以實現了跨視窗的會話跟蹤。(待測試)


*************************************************************************************
二十八、如何使用會話顯示每個客戶的訪問次數
*************************************************************************************


由於客戶的訪問次數是一個整型的變數,但session的屬性型別中不能使用int,double,boolean等基本型別的變數,
所以我們要用到這些基本型別的封裝型別物件作為session物件中屬性的值.


但像Integer是一種不可修改(Immutable)的資料結構:構建後就不能更改。這意味著每個請求都必須建立新的Integer物件,之後使用setAttribute來覆蓋之前存在的老的屬性的值。例如:


Integer value = (Integer)request.getSession().getAttribute("cout");
if (value == null){
     value = new CountClass(…); // 新建立一個不可更改物件
}else{
     value = new CountClass(calculated(value)); // 對value重新計算後建立新的物件
}
request.getSession().setAttribute("cout",value);// 使用新建立的物件覆蓋原來的老的物件


*************************************************************************************
二十九、如何使用會話累計使用者的資料
*************************************************************************************


使用可變的資料結構,比如陣列、List、Map或含有可寫欄位的應用程式專有的資料結構。通過這種方式,除非首次分配物件,否則不需要呼叫setAttribute。例如:


List list_check = (List) request.getSession().getAttribute("ids_go");
if(list_check = = null){
     list_check = new List(...);
     request.getSession().setAttribute(("ids_go",list_check );
}else{
      list_check .clear();// 如果已經存在該物件則更新其屬性而不需重新設定屬性
}
List list_check1 = (List) request.getSession().getAttribute("ids_go");
System.out.println(list_check1.size());//此時size為0


*************************************************************************************
三十、不可更改物件和可更改物件在會話資料更新時的不同處理
*************************************************************************************


不可更改物件因為一旦建立之後就不能更改,所以每次要修改會話中屬性的值的時候,都需要呼叫setAttribute(“someIdentifier”,newValue)來代替原有的屬性的值,
否則屬性的值不會被更新。


可更改物件因為其自身一般提供了修改自身屬性的方法,所以每次要修改會話中屬性的值的時候,只要呼叫該可更改物件的相關修改自身屬性的方法就可以了,
這意味著我們就不需要呼叫setAttribute方法了。













相關推薦

SessionCookie應用場景區別

一、cookie機制和session機制的區別 ************************************************************************************* 具體來說cookie機制採用的是在客戶端保持狀態的方案

php中sessioncookie的使用及區別

網上商城 標識 禁止 bsp 身份驗證 main str 什麽 ets 1.cookie的使用 什麽是 Cookie? cookie 常用於識別用戶。cookie 是服務器留在用戶計算機中的小文件。每當相同的計算機通過瀏覽器請求頁面時,它同時會發送 cookie。通過

什麽是cookie?什麽是sessionsessioncookie有什麽區別

篡改 設置 般的 red 詞語 怎麽 很好 愛好 清除 在技術面試中,經常被問到“說說Cookie和Session的區別”,大家都知道,Session是存儲在服務器端的,Cookie是存儲在客戶端的,然而如果讓你更詳細地說明,你能說出幾點?今天個推君

session對象cookie對象的區別

安全 欺騙 cookie對象 data- src 就是 其他 時間 訪問 1、cookie數據存放在客戶的瀏覽器上,session數據放在服務器上2、cookie不是很安全,別人可以分析存放在本地的COOKIE並進行COOKIE欺騙考慮到安全應當使用session3、ses

python3:set frozenset的應用場景區別

set 是集合,frozenset 是凍結的集合,顧名思義是不可變集合。 set 最大的特性是不重合,在去重的時候用的最多。 1.接受一個可迭代的型別 先簡單的看下class 的說明如下: class set(object): """ set() ->

springcloud中zuulfeign的應用場景區別

1、zuul作為整個應用的流量入口,接收所有的請求,如app、網頁等,並且將不同的請求轉發至不同的處理微服務模組,其作用可視為nginx。 2、feign則是將當前微服務的部分服務介面暴露出來,並且主要用於各個微服務之間的服務呼叫。 兩者的應用層次以及原理均不相同。 3.zuul也含有hys

Java開發中SessionCookie都有哪些區別?

1.背景介紹 什麼是CookieCookie 是在HTTP協議下,伺服器或指令碼可以維護客戶工作站上資訊的一種方式。Cookie 是由 Web伺服器儲存在使用者瀏覽器(客戶端)上的小文字檔案(內容通常經過加密),它可以包含有關使用者的資訊。無論何時使用者連結到伺服器,Web站點都可以訪問

PHP中sessioncookie的用法及區別

一,session 1.session 是啥? 2.怎麼儲存的? 3.如何執行? 4.有生命週期嗎? 5.關閉瀏覽器會過期嗎? 6.Redis代替檔案儲存session 7.分散式session的同步問題     session是啥?

SessionCookie的聯絡與區別

這裡有一篇資料:https://pan.baidu.com/s/1tjUyL7DwY2ganIfKnz_AJQ 在講session和coookie之前,要先知道會話跟蹤的概念。 在常見的Java Web開發中,我們經常會使用會話跟蹤技術,來記錄某一時段使用者的行為。

MySQL中InnoDB引擎MyISAM引擎的應用場景區別

InnoDB和MyISAM是在使用MySQL最常用的兩個表型別,各有優缺點,視具體應用而定。   下面是已知的兩者之間的差別,僅供參考。      innodb   InnoDB 給 MySQL 提供了具有事務(commit)、回滾(rollback)和

sessionCookie的介紹應用

丟失 服務器和客戶端 null 查看 ges 問控制 用戶 lose 到你 Session:在計算機中,尤其是在網絡應用中,稱為“會話控制”。Session 對象存儲特定用戶會話所需的屬性及配置信息。這樣,當用戶在應用程序的 Web 頁之間跳轉時

SessionCookie的用法及區別

1. Session、Cookie是什麼 1.1 概念理解 要了解session和cookie是什麼,先要了解以下幾個概念。 1.1.1 無狀態的HTTP協議 協議:是指計算機通訊網路中兩臺計算機之間進行通訊所必須共同遵守的規定或規則。 超文字傳輸協議(HTTP):是一種通訊協議,它允許將超文字標記語言(HT

TCPUDP應用場景

通信 socket 客戶端 區別 階段 log 大量 一次 三次 tcp是一種面向連接的、可靠的、基於字節流的傳輸層通信協議。是專門為了在不可靠的互聯網絡上提供一個可靠的端到端字節流而設計的,面向字節流。 udp(用戶數據報協議)是iso參考模型中一種無連接的傳輸層協

Docker五種存儲驅動原理及應用場景性能測試對比

Docker 存儲驅動 Docker最開始采用AUFS作為文件系統,也得益於AUFS分層的概念,實現了多個Container可以共享同一個image。但由於AUFS未並入Linux內核,且只支持Ubuntu,考慮到兼容性問題,在Docker 0.7版本中引入了存儲驅動, 目前,Docker支持AUFS

視覺slam領域經典綜述具體應用場景

此外 一致性 固定 三維重建 之一 攝像 cad 左右 nsa 一、經典綜述文章 1. Durrant-Whyte H, Bailey T. Simultaneous localization and mapping: part I[J]. IEEE robotics &

zookeeper的應用場景相關理論

zk的應用場景 用監聽機制監聽自身的znode的變化 1)命名服務: 全域性統一命名服務 同一個檔案3個副本 修改檔名 怎麼保證3個副本檔名一樣 將全域性統一的命名放在zk的znode的節點的儲存內容上 哪一個客戶端對這個感興趣就可以新增監聽 2)配置檔案管理 安裝hadoop叢集的時候 叢

jsp中sessioncookie的存取的操作

存session //將username放到session中 HttpSession session = request.getSession(true); session.setAttribute("username",username);  

Vue SSR的應用場景開發中遇到的一些問題

https://blog.csdn.net/P6P7qsW6ua47A2Sb/article/details/81256748   https://blog.csdn.net/qq_26744901/article/details/78617209   根據專案需要,如有需要用到n

nosql資料庫:mongodb,redis,memcached,其優缺點使用應用場景

1.mongodb (1)是文件型的非關係型資料庫,使用bson結構。其優勢在於查詢功能比較強大,能儲存海量資料,缺點是比較消耗記憶體。 (2)一般可以用來存放評論等半結構化資料,支援二級索引。 適合儲存json型別資料,不經常變化。 (3)舉例: a.網站資料:非常適合實時的插

訊息佇列的應用場景常見的訊息佇列之間的比較

From: http://blog.csdn.net/cws1214/article/details/52922267 訊息佇列使用的四種場景介紹 訊息佇列中介軟體是分散式系統中重要的元件,主要解決應用耦合,非同步訊息,流量削鋒等問題 實現高效能,高