目前我們使用購物車的存儲方式主要有：Session方式，Cookie方式，數(shù)據(jù)庫存儲，我們來一一分析優(yōu)缺點。
1.Session（Memcached）方式
優(yōu)點：購物車信息保存在服務(wù)端，可以保存1M 信息。
缺點：對于大型網(wǎng)站會占有過多的服務(wù)器內(nèi)存資源，造成服務(wù)器壓力過大。Session保存的信息會在用戶退出登錄后丟失。用戶下次登錄，購物車中商品信息丟失，用戶只能從新選擇。
2.Cookie方式
優(yōu)點：購物車信息存儲在客戶端，不占用服務(wù)器資源，基本可以到達持久化存儲。
缺點：Cookie有大小的限制，不能超過4K，而且不夠安全。如果是個人PC機，Cookie能很好的保存購物車信息，但如果是公共辦公環(huán)境，Cookie保存的信息基本就失效了(會被其他人購物車信息覆蓋)。對一個大型的電子商務(wù)網(wǎng)站，我們需要對用戶的購買行為進行分析，需要對用戶推薦用戶感興趣的商品，如果把購物車信息保存在Cookie中，則不能對用戶購買行為分析統(tǒng)計。
3.數(shù)據(jù)庫存儲
優(yōu)點：持久化存儲，可以分析用戶購買行為。
缺點: 網(wǎng)站速度變慢，成本和維護增加。
對于一個大型的電子商務(wù)網(wǎng)站，我們需要知道用戶對什么樣的商品感興趣，需要給用戶推薦相似度商品。那么就有必要分析用戶的購買行為。在這里只詳細講述下使用數(shù)據(jù)庫存儲方式的演變。開始我們是使用Cookie存儲購物車的信息，但使用一段時間后發(fā)現(xiàn)有很多客戶投訴，購物車中常常會多了很多商品，而且并不是客戶選擇的商品。數(shù)據(jù)挖掘部門也抱怨不能分析購物車的信息。。。。我們決定改變購物車的存儲方式。開始我們設(shè)計的表是這樣的：
對于登錄用戶，我們根據(jù)UserId查詢購物車信息。對于非登錄用戶，則根據(jù)瀏覽器選擇查詢方式，如果是火狐瀏覽器，我們根據(jù)SessionId查詢，如果是IE或360瀏覽器，我們根據(jù)IP查詢。在一天訂單量只有幾萬單的時候，系統(tǒng)運行的很穩(wěn)定。但發(fā)現(xiàn)一天訂單量超過10萬單的時候，特別是高峰期，購物車數(shù)據(jù)庫寫壓力特別大。查詢也時常超時。我們不得不清理存儲時間超過10天的數(shù)據(jù)。我們新建一個Job每天夜里執(zhí)行刪除超過10天的數(shù)據(jù)。但隨著訂單量的增加。數(shù)據(jù)庫寫壓力依然很大。這時候我們考慮分庫來解決數(shù)據(jù)庫的寫壓力。我們根據(jù)登錄用戶和匿名用戶來拆庫。采用如圖方式
對于登錄用戶我們根據(jù)UserId拆成2個庫，一個是奇數(shù)庫，一個是偶數(shù)庫。對于匿名用戶我們根據(jù)瀏覽器拆分，火狐瀏覽器（SessionId查詢）一個庫，IE或360瀏覽器（根據(jù)IP查詢）一個庫。
對于表結(jié)構(gòu)，我們也做了調(diào)整。使用UserId和CreatedDateTicks時間撮做聯(lián)合主鍵，登錄用戶購物車表結(jié)構(gòu)：
匿名用戶（火狐瀏覽器）存儲表結(jié)構(gòu)：
IE或360瀏覽器存儲表結(jié)構(gòu)：
數(shù)據(jù)存儲方面我們也做了調(diào)整。刪掉了大量的數(shù)據(jù)庫更新操作，因為大量的更新操作會造成鎖表。購物車信息發(fā)生變化時，Content保存用戶購物車信息的XML。現(xiàn)在只需做插入操作了。查詢數(shù)據(jù)時，返回最后一條數(shù)據(jù)即可。采用分庫后減輕了單臺數(shù)據(jù)庫寫數(shù)據(jù)的壓力，Content保存購物車信息的XML避免大量的更新操作?，F(xiàn)在系統(tǒng)可以平穩(wěn)的運行了！
一般來說，可以使用session,cookie和數(shù)據(jù)庫來記錄購物車數(shù)據(jù)
1，不過不提倡使用session，這貨占用服務(wù)器資源，還有過期時間，客戶關(guān)掉瀏覽器時session即消失，下次再上來，又得重新選產(chǎn)品。
2，cookie這東西不錯，放在客戶端的，給個一年的過期時間，只要客戶不清掉，每次來都能記得上次的購物車信息。大家可以看看京東，
在購物車cookie中存了不少東西，有產(chǎn)品編碼和購買的數(shù)量等信息，如京東：yCartOrderLogic={&TheSkus&:[{&Id&:437741$&Num&:2}]}，
原來凡客的cookie中也以JSON的形式存了很多信息。
所以，我以學(xué)習(xí)的心態(tài)，將產(chǎn)品編碼，價格，名稱，類型和數(shù)量等購物信息做成一個對象，然后對象序列化成JSON，存在客戶端的COOKIE中，
在讀取cookie時，在剛開始的時候很好用，反序列化cookie值成購物車條目對象就可以了，但是當產(chǎn)品類型多起來之后，而且有套裝那種多件產(chǎn)品時，
甚至產(chǎn)品不是來自同一個數(shù)據(jù)表時，比如普通首飾和鉆石，表的結(jié)構(gòu)都不一樣了，還得到不同的表格中去取，當然首先你得判斷產(chǎn)品類型
這時候一個購物條目對象已經(jīng)有多條子對象，往往一個查詢中嵌套著兩重以上的循環(huán)加上多個switch case，當購物車中有十個復(fù)雜的條目時，讀取速度
將超過十秒，不管怎么優(yōu)化，速度就擺在那里，不快不慢。。。而且你不能保證客戶不下100個或更多的復(fù)雜購物車記錄，最重要的是cookie是有
存儲大小限制的，這種做法有產(chǎn)品很復(fù)雜時是不利的，果斷放棄！
3，數(shù)據(jù)庫這東西好啊，不會像cookie那種容易丟失，也沒有客戶端的限制，你想怎么存，存多少都行。
購物車數(shù)據(jù)存數(shù)據(jù)庫好處有很多，可以分析購買行為，可以為客戶保存購買信息（不會因為瀏覽器關(guān)閉而丟失）等。
還需要考慮的一個問題是用戶是否登錄，淘寶使用的就是cookie記錄，你可以試試，未登錄時可以加20個商品，登錄后可以加50個，這就是因為
cookie客戶端的限制。
我這里因為產(chǎn)品線的復(fù)雜性，所有購物車條目都保存在數(shù)據(jù)庫中。
購物車數(shù)據(jù)庫設(shè)計成兩個關(guān)聯(lián)表
1，Basket，購物車主表
基本字段有：BasketId,AddTime,UserId,AddressId,Payment,Status等，不解釋了，看英文意思就行
2，BasketDetail，購物車條目表
基本字段有：BasketDetailId,BasketId,Type,Code,Qty,ParentId等，ParentId用作子行標識，其它不解釋
兩個表之間使用BasketId做為關(guān)聯(lián)
當用戶登錄狀態(tài)時，添加產(chǎn)品到購物時，查看Basket中是否有Status為True的購物車，沒有則添加一條新的Basket記錄，并將產(chǎn)品信息相關(guān)數(shù)據(jù)添加至BasketDetail表中
當用戶未登錄時，使用cookie記錄一個BasketId值，不往Basket表中插入數(shù)據(jù)，只往BasketDetail插入數(shù)據(jù)，其中的BasketId值使用cookie中的BasketId值，當用戶登錄
后，查看Basket中是否有Status為True的購物車記錄，有則合并（更新cookie和BasketDetail中的BasketId為查詢出來的Basket表中的BasketId值），無則添加一條新的
Basket記錄，并將BasketId值置為Cookie中記錄的basketid值。
（轉(zhuǎn)載CSDN隨風(fēng)飄揚中博主的博文）
