為啥用redis解決會話呢？

什么是會話？

會話可簡單理解為：用戶開一個(gè)瀏覽器，點(diǎn)擊多個(gè)超鏈接，訪問服務(wù)器多個(gè)web資源，然后關(guān)閉瀏覽器，整個(gè)過程稱之為一個(gè)會話。

?會話過程中要解決的一些問題？

–每個(gè)用戶不可避免各自會產(chǎn)生一些數(shù)據(jù)，程序要想辦法為每個(gè)用戶保存這些數(shù)據(jù)。

–例如：用戶點(diǎn)擊超鏈接通過一個(gè)servlet購買了一個(gè)商品，程序應(yīng)該想辦法保存用戶購買的商品，以便于用戶點(diǎn)結(jié)帳servlet時(shí)，結(jié)帳servlet可以得到用戶購買的商品為用戶結(jié)帳。

?Cookie

–Cookie是客戶端技術(shù)，程序把每個(gè)用戶的數(shù)據(jù)以cookie的形式寫給用戶各自的瀏覽器。當(dāng)用戶使用瀏覽器再去訪問服務(wù)器中的web資源時(shí)，就會帶著各自的數(shù)據(jù)去。這樣，web資源處理的就是用戶各自的數(shù)據(jù)了。

?HttpSession

–Session是服務(wù)器端技術(shù)，利用這個(gè)技術(shù)，服務(wù)器在運(yùn)行時(shí)可以為每一個(gè)用戶的瀏覽器創(chuàng)建一個(gè)其獨(dú)享的HttpSession對象，由于session為用戶瀏覽器獨(dú)享，所以用戶在訪問服務(wù)器的web資源時(shí)，可以把各自的數(shù)據(jù)放在各自的session中，當(dāng)用戶再去訪問服務(wù)器中的其它web資源時(shí)，其它web資源再從用戶各自的session中取出數(shù)據(jù)為用戶服務(wù)。

總結(jié)：cookie存在客戶端，session存在服務(wù)器端

通常結(jié)合使用。

我們先用sprintboot演示一下cookie和session操作

@RequestMapping(path = "/cookie/set",method = RequestMethod.GET)

@ResponseBody

public String setCookie(HttpServletResponse httpServletResponse){

Cookie cookie=new Cookie("code", CommunityUtil.generateUUID());

cookie.setPath("/Community/alpha");

cookie.setMaxAge(60*10);

httpServletResponse.addCookie(cookie);

return "set cookie";

}

@RequestMapping(path = "/cookie/get",method = RequestMethod.GET)

@ResponseBody

public String getCookie(@CookieValue("code") String code){

System.out.println(code);

return "get cookie";

}

@RequestMapping(path = "/session/set", method = RequestMethod.GET)

@ResponseBody

public String setSession(HttpSession session){

session.setAttribute("id",1);

session.setAttribute("name","Test");

return "set session";

}

@RequestMapping(path = "/session/get", method = RequestMethod.GET)

@ResponseBody

public String getSession(HttpSession session) {

System.out.println(session.getAttribute("id"));

System.out.println(session.getAttribute("name"));

return "get session";

}

隨著服務(wù)器要處理的請求越來越多，我們不得不分布式部署，減小服務(wù)器壓力。

為了負(fù)載均衡，我們一般采用nginx來分發(fā)請求給各個(gè)服務(wù)器處理

但是這樣session是無法共享的。

（粘性session）

你可以設(shè)置nginx的分配策略，下次同一個(gè)還讓同一個(gè)服務(wù)器來處理

但是很顯然，這就和分布式和nginx初衷違背了：負(fù)載很難保證均衡。

（同步session）

一臺服務(wù)器的session給所有服務(wù)器復(fù)制一份

第一，性能不好。第二，產(chǎn)生了一定的耦合

（專門session）

專門一臺服務(wù)器來解決，存session，其它服務(wù)器來這個(gè)服務(wù)器取session再用。

但是也有問題：你這個(gè)服務(wù)器掛了怎么辦？別的服務(wù)器都是依賴這個(gè)服務(wù)器工作的。我們分布式部署本來就是為了解決性能的瓶頸啊。

很容易想到，我們把那個(gè)處理session的服務(wù)器搞個(gè)集群：

更不行，想想就知道，本來就是為了解決分布式部署的問題，你把單獨(dú)解決session的服務(wù)器又搞集群，和之前有什么區(qū)別呢？還不如一個(gè)服務(wù)器存一份簡單呢。

（存數(shù)據(jù)庫）

可以，但是傳統(tǒng)的關(guān)系數(shù)據(jù)庫是存到硬盤里，速度太慢。

（nosql）

最終，我們的主流辦法使用nosql數(shù)據(jù)庫，比如redis，來解決這個(gè)問題的。

Redis 數(shù)據(jù)庫

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。