在逛各大電商網(wǎng)站的時(shí)候寓盗，總會有將商品加入購物車辣垒，然后合并付款望侈，這個(gè)大大的提高了用戶的體驗(yàn)，某東更是任性勋桶，在未登錄的情況下都可以將商品加入購物車脱衙，但是任性總是有代價(jià)的，后面我會說一下這個(gè)小bug例驹【韬可能不算是個(gè)bug，但是體驗(yàn)上也有不爽的地方鹃锈。

還是談?wù)勝徫镘囀侨绾螌?shí)現(xiàn)的吧荤胁，購物車首先標(biāo)識要唯一，因?yàn)槊總€(gè)賬號要對應(yīng)一個(gè)購物車屎债，在登錄狀態(tài)下仅政，我們可以直接將數(shù)據(jù)保存到數(shù)據(jù)庫中，使用用戶的id表示自己購買的商品盆驹，但是如果在未登錄狀態(tài)下呢圆丹，或者對購車訪問量大的時(shí)候，這個(gè)就存在弊端躯喇，因?yàn)檫@樣高速的讀寫數(shù)據(jù)庫辫封，會對數(shù)據(jù)庫的壓力比較大，在這里我們就看看如何用Redis和RabbitMQ解決這個(gè)問題廉丽。

第一章：登錄狀態(tài)下添加商品到購物車

此時(shí)購物車是對應(yīng)一個(gè)用戶倦微，很簡單，就是將商品的數(shù)據(jù)插入數(shù)據(jù)庫中即可正压，但是如果讀寫頻繁的時(shí)候欣福，就存在壓力問題，此時(shí)我們可以使用Redis擔(dān)任讀的部分功能蔑匣。

在向數(shù)據(jù)庫中插入數(shù)據(jù)的時(shí)候劣欢，使用RabbitMQ發(fā)送消息棕诵，然后有一個(gè)消息系統(tǒng)監(jiān)聽消息裁良，將RabbitMQ中消息內(nèi)容(插入數(shù)據(jù)庫中的商品數(shù)據(jù))保存到Redis中凿将，但是此時(shí)Redis中我們該用什么存儲結(jié)構(gòu)，在Redis中存儲結(jié)構(gòu)有很多種.

從上面的圖我們可以看的出來价脾，這個(gè)圖有兩個(gè)鍵牧抵，一個(gè)是外部鍵，一個(gè)是內(nèi)部鍵侨把，這個(gè)就體現(xiàn)了購物車的好處犀变，這里外部鍵可以標(biāo)記一個(gè)唯一的購物車，內(nèi)部鍵就可以標(biāo)記購物車上的一個(gè)商品秋柄，一個(gè)外部鍵可以對應(yīng)多個(gè)內(nèi)部鍵获枝，這個(gè)和一個(gè)購物車?yán)镉卸鄠€(gè)商品是相符合的，在用戶查詢自己的購物車數(shù)據(jù)的時(shí)候骇笔，就不要到數(shù)據(jù)庫中查詢省店，而是直接從redis中將數(shù)據(jù)拿出來即可，這樣數(shù)據(jù)庫的讀壓力就被Redis分擔(dān)出去了笨触。

就這樣把登錄狀態(tài)下購物車問題解決了懦傍。

第二章：未登錄下加入購物車，登錄下合并購物車

在未登錄狀態(tài)下芦劣，沒有指定的用戶粗俱，此時(shí)購物車應(yīng)該怎么分配，數(shù)據(jù)把偶才能在什么位置虚吟，這個(gè)其實(shí)也不難系吩，我們可以將數(shù)據(jù)臨時(shí)保存到Redis中，并不插入數(shù)據(jù)庫中间唉，因?yàn)榇藭r(shí)沒有對應(yīng)的用戶灶似，Redis生成一個(gè)唯一的outerKey，保存到cookie中模庐，每次添加商品烛愧，帶上這個(gè)cookie，這樣就保證每次加入同一個(gè)購物車掂碱，這個(gè)數(shù)據(jù)會被保存一段時(shí)間怜姿，當(dāng)用戶登錄的時(shí)候，我們該如何將未登錄狀態(tài)下的購車和登錄狀態(tài)下的購車數(shù)據(jù)合并呢疼燥。這個(gè)就需要使用到消息了沧卢，我們可以發(fā)送一個(gè)消息給后臺系統(tǒng)，將未登錄狀態(tài)下的outerKey傳遞給后臺系統(tǒng)醉者，后臺系統(tǒng)到Redis中查詢到未登錄狀態(tài)下的購物車但狭，將購物車中的數(shù)據(jù)插入到數(shù)據(jù)庫中披诗，和之前登錄狀態(tài)下的購車數(shù)據(jù)合并，重新緩存到Redis中立磁，此時(shí)緩存到Redis中的購物車是和未登錄狀態(tài)不同的呈队，因?yàn)檫@個(gè)緩存的購物車是有主人的，未登錄狀態(tài)下緩存的臨時(shí)購物車是沒有主人的唱歧。

小小bug的解析：

在開頭我們曾說到未登錄狀態(tài)下加入臨時(shí)購物車宪摧，登錄后合并到登錄用戶的購物車中，接下來我看一下這個(gè)場景颅崩。

小王用小李的電腦逛商城几于，沒有登錄，將看中的商品加入到了臨時(shí)的購物車中沿后，小王還沒有來得及登錄自己的賬號結(jié)算購物車沿彭，因有事出去了一下，此時(shí)小李回來了尖滚，他想到之前自己的購物車?yán)镞€有商品需要付款喉刘，他就毫不猶豫的登錄了自己的賬號，這時(shí)候問題來了熔掺，小王之前臨時(shí)購物車中的商品都會合并到小李的賬戶下饱搏，小李的購物車憑空出現(xiàn)自己未加入購物車的商品。過了一會小王回來了置逻，發(fā)現(xiàn)自己臨時(shí)購物車中的數(shù)據(jù)都沒有了推沸。這樣是不是就存在用戶體驗(yàn)的問題，俗稱靈異事件券坞，呵呵鬓催，開個(gè)玩笑。這種情況就導(dǎo)致了用戶的體驗(yàn)不好了恨锚。

上面的問題我也想過解決方案宇驾，但是無果，求各路大神共同解決猴伶。

疑問解決：

1课舍、Redis擔(dān)任讀的問題，當(dāng)像雙11這種大量訪問的情況下他挎，Redis會不會崩潰筝尾？

這個(gè)問題我也想過，這個(gè)我們可以考慮使用Redis的集群办桨，這樣就可以解決大部分的問題筹淫。

2、數(shù)據(jù)庫也可以做讀寫分離呢撞，為什么要使用Redis擔(dān)任讀呢损姜，直接使用讀寫分離不就可以了嗎饰剥？

數(shù)據(jù)庫的讀寫分離的確可以解決問題，但是像Redis這種非關(guān)系型數(shù)據(jù)庫比較明顯的優(yōu)點(diǎn)就是數(shù)據(jù)處理效率高摧阅，讀寫分離和Redis的效率相比較來說汰蓉，個(gè)人感覺還是使用Redis可靠。

3逸尖、在文章中提到RabbitMQ消息機(jī)制古沥，這個(gè)到底怎么用瘸右？

這個(gè)嗎娇跟，說來話長，在接下來的博文中我會慢慢的道來RabbitMQ的基本使用和RabbitMQ與spring的整合太颤。

如果還存在什么疑問苞俘，很歡迎你回復(fù)本帖，大家一起討論龄章。

開發(fā)網(wǎng)站需要注意的安全方面的問題:http://www.360doc.com/content/13/0518/00/12136407_286230998.shtml

購物車相當(dāng)于現(xiàn)實(shí)中超市的購物車吃谣，不同的是一個(gè)是實(shí)體車，一個(gè)是虛擬車而已做裙。用戶可以在購物網(wǎng)站的不同頁面之間跳轉(zhuǎn)岗憋，以選購自己喜愛的商品，點(diǎn)擊購買時(shí)锚贱，該商品就自動保存到你的購物車中仔戈，重復(fù)選購后，最后將選中的所有商品放在購物車中統(tǒng)一到付款臺結(jié)賬拧廊，這也是盡量讓客戶體驗(yàn)到現(xiàn)實(shí)生活中購物的感覺监徘。服務(wù)器通過追蹤每個(gè)用戶的行動，以保證在結(jié)賬時(shí)每件商品都物有其主吧碾。

購物車的功能包括以下幾項(xiàng)：

n 把商品添加到購物車凰盔，即訂購

n 刪除購物車中已定購的商品

n 修改購物車中某一本圖書的訂購數(shù)量

n 清空購物車

n 顯示購物車中商品清單及數(shù)量、價(jià)格

實(shí)現(xiàn)購物車的關(guān)鍵在于服務(wù)器識別每一個(gè)用戶并維持與他們的聯(lián)系倦春。但是HTTP協(xié)議是一種“無狀態(tài)(Stateless)”的協(xié)議户敬，因而服務(wù)器不能記住是誰在購買商品，當(dāng)把商品加入購物車時(shí)睁本，服務(wù)器也不知道購物車?yán)镌扔行┦裁茨蚵沟糜脩粼诓煌撁骈g跳轉(zhuǎn)時(shí)購物車無法“隨身攜帶”，這都給購物車的實(shí)現(xiàn)造成了一定的困難添履。

目前購物車的實(shí)現(xiàn)主要是通過cookie屁倔、session或結(jié)合數(shù)據(jù)庫的方式。下面分析一下它們的機(jī)制及作用暮胧。

1. cookie

cookie是由服務(wù)器產(chǎn)生锐借，存儲在客戶端的一段信息问麸。它定義了一種Web服務(wù)器在客戶端存儲和返回信息的機(jī)制，cookie文件它包含域钞翔、路徑严卖、生存期、和由服務(wù)器設(shè)置的變量值等內(nèi)容布轿。當(dāng)用戶以后訪問同一個(gè)Web服務(wù)器時(shí)哮笆，瀏覽器會把cookie原樣發(fā)送給服務(wù)器。通過讓服務(wù)器讀取原先保存到客戶端的信息汰扭，網(wǎng)站能夠?yàn)闉g覽者提供一系列的方便稠肘，例如在線交易過程中標(biāo)識用戶身份、安全要求不高的場合避免用戶重復(fù)輸入名字和密碼萝毛、門戶網(wǎng)站的主頁定制项阴、有針對性地投放廣告等等。利用cookie的特性笆包，大大擴(kuò)展了WEB應(yīng)用程序的功能环揽，不僅可以建立服務(wù)器與客戶機(jī)的聯(lián)系，因?yàn)閏ookie可以由服務(wù)器定制庵佣，因此還可以將購物信息生成cookie值存放在客戶端歉胶，從而實(shí)現(xiàn)購物車的功能。用基于cookie的方式實(shí)現(xiàn)服務(wù)器與瀏覽器之間的會話或購物車巴粪，有以下特點(diǎn)：

n cookie存儲在客戶端通今，且占用很少的資源，瀏覽器允許存放300個(gè)cookie验毡，每個(gè)cookie的大小為4KB衡创，足以滿足購物車的要求，同時(shí)也減輕了服務(wù)器的負(fù)荷晶通；

n cookie為瀏覽器所內(nèi)置璃氢，使用方便。即使用戶不小心關(guān)閉了瀏覽器窗口狮辽，只要在cookie定義的有效期內(nèi)一也，購物車中的信息也不會丟失；

n cookie不是可執(zhí)行文件喉脖，所以不會以任何方式執(zhí)行椰苟，因此也不會帶來病毒或攻擊用戶的系統(tǒng)；

n 基于cookie的購物車要求用戶瀏覽器必須支持并設(shè)置為啟用cookie树叽，否則購物車則失效舆蝴；

n 存在著關(guān)于cookie侵犯訪問者隱私權(quán)的爭論，因此有些用戶會禁止本機(jī)的cookie功能。

2. session

session是實(shí)現(xiàn)購物車的另一種方法洁仗。session提供了可以保存和跟蹤用戶的狀態(tài)信息的功能层皱，使當(dāng)前用戶在session中定義的變量和對象能在頁面之間共享，但是不能為應(yīng)用中其他用戶所訪問赠潦，它與cookie最重大的區(qū)別是叫胖，session將用戶在會話期間的私有信息存儲在服務(wù)器端，提高了安全性她奥。在服務(wù)器生成session后瓮增，客戶端會生成一個(gè)sessionid識別號保存在客戶端，以保持和服務(wù)器的同步哩俭。這個(gè)sessionid是只讀的绷跑，如果客戶端禁止cookie功能，session會通過在URL中附加參數(shù)携茂，或隱含在表單中提交等其他方式在頁面間傳送你踩。因此利用session實(shí)施對用戶的管理則更為安全诅岩、有效讳苦。

同樣，利用session也能實(shí)現(xiàn)購物車吩谦，這種方式的特點(diǎn)是：

n session用新的機(jī)制保持與客戶端的同步鸳谜，不依賴于客戶端設(shè)置；

n 與cookie相比式廷，session是存儲在服務(wù)器端的信息咐扭，因此顯得更為安全，因此可將身份標(biāo)示滑废，購物等信息存儲在session中蝗肪；

n session會占用服務(wù)器資源，加大服務(wù)器端的負(fù)載蠕趁，尤其當(dāng)并發(fā)用戶很多時(shí)薛闪，會生成大量的session，影響服務(wù)器的性能俺陋；

n 因?yàn)閟ession存儲的信息更敏感豁延，而且是以文件形式保存在服務(wù)器中，因此仍然存在著安全隱患腊状。

3. 結(jié)合數(shù)據(jù)庫的方式

這也是目前較普遍的模式诱咏，在這種方式中，數(shù)據(jù)庫承擔(dān)著存儲購物信息的作用缴挖，session或cookie則用來跟蹤用戶袋狞。這種方式具有以下特點(diǎn)：

n 數(shù)據(jù)庫與cookie分別負(fù)責(zé)記錄數(shù)據(jù)和維持會話，能發(fā)揮各自的優(yōu)勢，使安全性和服務(wù)器性能都得到了提高苟鸯；

n 每一個(gè)購物的行為法焰，都要直接建立與數(shù)據(jù)庫的連接，直至對表的操作完成后倔毙，連接才釋放埃仪。當(dāng)并發(fā)用戶很多時(shí)，會影響數(shù)據(jù)庫的性能陕赃，因此卵蛉，這對數(shù)據(jù)庫的性能提出了更高的要求；

n 使cookie維持會話有賴客戶端的支持么库。

各種方式的選擇：

雖然cookie可用來實(shí)現(xiàn)購物車傻丝，但必須獲得瀏覽器的支持，再加上它是存儲在客戶端的信息诉儒，極易被獲取葡缰，所以這也限制了它存儲更多，更重要的信息忱反。所以一般cookie只用來維持與服務(wù)器的會話泛释，例如國內(nèi)最大的當(dāng)當(dāng)網(wǎng)絡(luò)書店就是用cookie保持與客戶的聯(lián)系，但是這種方式最大的缺點(diǎn)是如果客戶端不支持cookie就會使購物車失效温算。

Session 能很好地與交易雙方保持會話怜校，可以忽視客戶端的設(shè)置。在購物車技術(shù)中得到了廣泛的應(yīng)用注竿。但session的文件屬性使其仍然留有安全隱患茄茁。

結(jié)合數(shù)據(jù)庫的方式雖然在一定程度上解決了上述的問題，但從上面的例子可以看出：在這種購物流程中涉及到對數(shù)據(jù)庫表的頻繁操作巩割，尤其是用戶每選購一次商品裙顽，都要與數(shù)據(jù)庫進(jìn)行連接，當(dāng)用戶很多的時(shí)候就加大了服務(wù)器與數(shù)據(jù)庫的負(fù)荷宣谈。