電商購物車緩存設計

⑴ 初識購物車的產品架構

天下熙熙皆為利來，天下攘攘皆為利往。 ——源於《史記·貨殖列傳》

很高興有一個愉快的周末，因為每次我都有時間去調整和回顧一下走過的一周，應該說這一周還是很有意思的！

1、高考6月789日，一個六年前我曾經為之緊張，如今卻淡然處之。當然，並不是說不是當事人，站著說話不腰疼，心態真地發生了微妙的變化；

2、工作上針對用戶體驗和交互設計，提出了一套初期的小程序迭代產品方案以及後期的重大功能增量式迭代，並且完整交付了產品的解決方案；

3、預研電商C端產品的最為核心功能——購物車，很激動但也不免一絲的擔憂，之前確實沒有對這方面有過接觸，如果偏要說也就是平時網上購物時的一點淵源；

最為繁重的工作就是購物車的調研，其實難度主要集中在兩點：

1、熟悉： 電商的購物車像極了商超提供的實體購物車的概念，至少初衷都是一樣的，方便用戶購物、優化用戶的體驗，最大化商業價值才是最根本的；

2、陌生： 電商的購物車是虛擬的概念，與實體的可見可得的購物車存在差異，不受時間、空間的限制，隨意性增大的同時帶來了人、物關系的弱化；

面對熟悉與陌生這一組矛盾，產品經理的思維能力就顯得格外重要， 模塊化、過程化了整個購物車結構和流程：

1、傳統購物車：購物車是指超市大型自選商場中，顧客用於暫時存放所選商品的一種手推車。通常是有幾層，可以存放不同的物品，有些還可以載小孩。

2、網上購物車：買家可以像在超市裡購物一樣，隨意添加、刪除商品，選購完畢後，統一下單網上商店的購物車要能過跟蹤顧客所選的的商品，記錄下所選商品，還要能隨時更新，可以支付購買。

——網路

第一要素：用戶需求驅動

第二要素：業務發展驅動

以上兩點背景我就不老生常談了，網上有各種版本，比我寫地好的多，可以去參閱。看了那多的背景分析，無非就是兩個關鍵詞：用戶需求、業務需要。

試用體驗了主流電商的，購物車的功能都非常強大。身為一個的初涉電商行業的產品，感覺理解起來是有點吃力的。而對於一個購物車而言，MVP具備的基本功能，最小化可行產品基礎結構：

1、查看商品：購物車裡面的商品清單，包含簡單的商品信息；

2、管理商品：對已加入的商品進行簡單的管理，包括：單選、多選，變更數量，刪除，結算，批量操作的功能服務；

3、支持營銷：活動信息的提示，訂單金額信息的顯示，需要顯示單價、總價、優惠、運費，跨境電商的稅費等在內的金額信息；

一個簡單的用戶購物車的流程：

1.1 加入購物車

-> 從商品頁面加入，需要選擇SKU

-> 從暫存架加入，已有SKU規格

-> 批量加入購物車，針對訂單的重新購買或者重新加入購物車的功能需求

1.2 管理功能

-> 查看購物車，顯示商品，支持分組

-> 修改數量，增減/輸入

-> 移除商品

-> 移到暫存架，可選擇是否從購物車移除

-> 清空購物車

-> 清空過期商品

1.3 結算

-> 關聯促銷活動，獲得折後價

-> 對賬功能支持，計算總價；支持整體結賬、組結賬或自由選擇若干商品一起結賬；

-> 對下達訂單的支持，根據當次結算的所選的產品，更新購物車的數據；

2.1關聯推薦

-> 在不同的視圖中，根據上下文推薦商品；

-> 推薦類型，包括：

    ~~ 根據其他顧客購買的行為、瀏覽和收藏等推薦

      ~~ 根據商品的交叉銷售推薦

-> 根據產品的向上/向下追加銷售推薦

2.2 結賬功能提前

-> 積分使用

-> 優惠券

-> 禮券使用

-> 運費估算，可以選擇不同類型

2.3 策略功能

-> 庫存提醒，剩餘件數，預警提示

-> 促銷活動到期，活動倒計時

-> 促銷活動生效條件，查XX可享受【滿XXX減少XXX】

3.1 購物車頁面

3.2 迷你購物車，作為購物車的快捷入口

問題：如果一款產品滿足多檔促銷活動，如何解決購物車產品邏輯設計以及設圖設計？

思路： 由於涉及到到多個重疊交集的問題，那麼直接使用【韋恩圖】的集合解決方案，將i上的問題要素模型化，通過幾個模型分析：

至於上述問題如何解讀，我只給出了思路並沒有給出詳細的解釋，大家可以自由發揮哦！

如果需要幫忙，可以給我留言...

後面我將會對購物車進行詳細的研究，也會不定時的與大家一起分享交流！

我是王偉

很開心和大家分享，而我想把開心一直繼續！希望對大家有點幫助！

⑵ 淺談移動端電商產品的購物車設計邏輯

先來說說購物車的起源，起初的購物車存在於線下商超的購物場景中，其主要解決的問題是提高用戶購物過程的便利性和客單價，達到優化用戶體驗和促銷的目的。而在之前電商行業是沒有購物車這個概念的，主要原因有：

1、電商發展初期，SKU數量較少，而用戶需求一般來講是一個恆定量，這種情況下，較少的SKU無法起到很好地滿足用戶需求和帶動用戶需求提升的作用。

2、電商發展初期，由於對新生事物信任感的缺失，網購人數及頻率較少，客單量也較少，用戶傾向於立即購買。

3、電商初期無法解決合並支付帶來的拆單後貨款的分配問題等（主要表現在平台型電商）

隨著互聯網電子商務行業的發展，目前，各大電商平台都已經引入了購物車這個概念。

我們首先看下移動端電商產品中購物車的作用。

·收藏

對於用戶來講，購物車首先發揮的是收藏的作用，相對於[收藏夾]來說，購物車在收藏屬性上應該是一個「弱收藏強購買屬性」（購物過程中有比較強烈的購買傾向），而收藏夾則是一個「強收藏弱購買屬性」（比如我看重一款鞋子，但這款鞋子沒有適合我的尺碼，所以我不能加入購物車（加入購物車需要填寫尺碼）只有收藏下來等到有合適尺碼再來買）。因此，購物車展示的商品以SKU形式顯示，而收藏夾以SPU顯示。

·篩選

由收藏帶來的篩選，對於用戶來講，在面對海量的商品資源的情況下，對意向的商品加入購物車，利於快捷的對不同商品的橫向對比，提高用戶購物決策的效率。

·湊單

湊單下包含兩種情況，一是用戶本身需求較多，需要一次性支付，提高購物效率；另一方面是一個隨機性的購物需求的增加（沖動消費），這個主要是基於商品優惠活動的影響（主要指范圍促銷，比如滿減，滿贈，滿返等）。

對於產品方來講，促銷是購物車的主要目的，而促銷一般包括兩種類型：單品促銷和范圍促銷。

單品促銷是指對單個商品的優惠促銷活動，比如打折，贈品等；這種促銷一般在單個商品詳情頁用戶即可得知最終的優惠情況，購物車只是作為一個補充說明。

范圍促銷是指多多個商品的優惠促銷活動，比如滿減、滿贈、滿返；而這種促銷一般由於門檻較高（比如滿100減10，滿500返100等），一方面商品單價往往不能cover所有的優惠另一方面單個商品詳情頁只指出優惠規則，因此在單個商品詳情頁用戶並不能明確最終的優惠情況，需要購物車做一個合並最終得出優惠情況。

而以上兩種促銷的目的都是為了提高客單價，以提升銷售額。

前面講到，購物車對於用戶來講最重要的是收藏作用，因此用戶放在購物車的商品就可以作為用戶的「個性化數據之一」，產品可以根據該數據對用戶做個性化推薦。因此，一般在購物車的下方，都會有「看了又看」「大家都在看」這樣的推薦。而在此值得說的是，前者是基於用戶的個性化數據做的推薦（也就是用戶有收藏、加入購物車等行為）；而後者是在未掌握用戶個性化數據下做的推薦，這種推薦一般來源於商品的熱度（大家都在看，都收藏或加入購物車）；運營需求（商品上新；庫存緊張等）。

從用戶在電商平台的使用流程來看：打開App——選擇意向商品——加入購物車——下單——支付——完成。那麼在這一過程中，下單環節是一定需要獲取用戶的詳細數據（姓名、收貨地等），產品需要明白是哪一個用戶下的單，以匹配唯一的訂單。而在這前一步，也就是加入購物車環節，是否需要用戶登陸後才可使用尼？

在這方面的處理上，不同產品的方法是不一樣的：目前主流的電商產品中，除了天貓、淘寶將「登陸」前置的購物車之前，其他的比如京東、蘇寧、亞馬遜、國美等都將「登陸」後置的用戶下單之前，加入購物車之後。那麼很顯然，後者的用戶體驗會更佳，因為這時候用戶已經有明確且強購物意願了（可能阿里財大氣粗，非要將此環節前置到加入購物車之前）。

那麼在這一環節設計上，因為購物車要匹配用戶的信息實現購物車的唯一性，因此需要明白的有兩點。

第一、用戶在無登錄狀態下加入的購物車和用戶登陸後的購物車是兩個概念：前者是離線購物車，其匹配的用戶信息是設備ID信息，設備ID信息的唯一性帶來購物車的唯一性；而後者的購物車屬於在線購物車，匹配的是用戶的注冊登錄信息，注冊登錄信息的唯一性帶來在線購物車的唯一性，因此需要用戶進行登錄。而考慮到用戶設備的作弊、更換與丟失等風險，因此，在下單環節需要將離線購物車切換到在線購物車，以獲取安全、真實的用戶注冊登錄信息來匹配唯一的訂單。（插個話，在這種情況下，如果用戶使用設備ID來直接下單購買，是不是具有可行性？懇求指導..）

第二、也就是用戶進入下單環節前，需要從離線購物車切換到在線購物車，這時候要同步的有兩個：

1）離線購物車的商品同步到在線購物車（否則用戶很懵逼）。

2）PC端在線購物車的商品同步到移動端在線購物購物車。

基於用戶和產品的需求，在購物車頁面的設計上，主要包括兩大部分：購物車商品信息流和個性化推薦商品信息流。

由於購物車的商品以SKU形式展示，這就帶來的因庫存變化、價格調整及促銷信息調整等帶來的SKU的變化，從而會對用戶購買意願產生影響，那麼這方面是怎麼解決的尼？

在電商產品中，庫存和購物車分別是兩個單獨的系統存在的。

一方面不同的SKU分布在不同的倉庫（天貓或淘寶中的店鋪）中，因此購物車需要從庫存系統調取SKU所屬的倉庫信息（天貓或淘寶中的店鋪）已備後續的拆單支付。

另一方面購物車中SKU的變化受到庫存的影響，因此購物車中SKU需要關聯到庫存系統。這樣以來，在電商前端有三種情況：

1）當可售庫存>某個閾值X，前端顯示庫存充足或者不進行顯示。

2）當0<可售庫存<某個閾值X，前端顯示庫存緊張，提高用戶的緊迫感和危機感，利於促進轉化率的提升。

3）當可售庫存=0，前端將所屬商品灰置，並提示用戶商品已下架。

當然以上是理想化狀態，庫存的變化是比較復雜的，涉及到何時鎖庫存以及庫存類型（邏輯庫存、實時庫存、調配庫存等）。

同樣在電商產品中，促銷系統和購物車分別是兩個單獨的系統存在的，購物車系統可以調用促銷系統數據。當用戶增刪商品數量，商品類型，促銷系統會經過計算將其滿足的最大優惠反饋到前端，帶來最終價格的變化；此外，對於單個商品而言，當出現價格下降時，會在前端顯示「已下降XX」，進而促進用戶的購買慾望，提高轉化率。

⑶ 淺談電商購物車設計

最近在做電商H5的設計，在研究購物車的時候有過那麼一些思考，周末終於有時間把最近的一些看法整理一下，文中所選的競品包括：淘寶（C2C）、京東(B2C)、網易考拉(跨境電商)和蘇寧易購（B2C）、阿里巴巴（B2B），基本涵蓋了目前主流的電商模式，同時這幾個平台用戶數量很廣，能在一定程度上反應用戶的使用習慣。

1、符合用戶購物習慣 ，相比較一些線下的小商品，任何一個電商平台都算得上是一家「超市」了，所以用戶很可能在同一個電商平台購買多個商品，如果用戶每購買一個商品就支付一次，不符合用戶購物習慣，對用戶體驗來說是一個巨大的災難。 因此從購物的流程來說，我們需要立即購買來快速購買，減少流程（當然任性的jd一直沒有），也需要加入購物車，多個商品合並支付。

2、體現訂單信息，即多個商品相互影響或者單個商品數量對訂單的影響。 電商平台最主要的此類信息就是 優惠信息 ，目前優惠主要有兩種，一種是單品的優惠，即單個商品的降價。另一種是多品優惠，比如滿減、滿送、搭配優惠等。如何體現後面這些優惠類型，就需要購物車的幫助。比如網易考拉左上角的滿減優惠：

諸如此類的優惠還很多，對用戶來說這主要是給用戶一個再思考的機會，對平台來說是關聯銷售。其他比如郵費等的信息也需要在購物車中體現。 當然還有很多其他非優惠的訂單信息需要在購物車內就對用戶進行提示，比如跨境電商的2000元限額等。這些信息是能影響購物決策的，因此不能放在訂單確認頁，購物車就是提示的最好地方 。

據說很多女性用戶都是把購物車當做收藏功能用的，把想要的商品加入購物車，之後再在購物車里選擇合適的商品組合進行結算，在這種用戶場景里，購物車也是必不可少的。

對一個購物車來說，他需要實現的 基本功能 ，即一個購物車的下限應該有：

1、瀏覽商品信息 ，即大概的看一下我的購物車里有哪些商品，同時這一定得是去到商品詳情的入口，用戶點擊購物車里的商品後能夠重新回到商品詳情，再一次決策是否結算該商品，商品信息可以比較簡略，只包含關鍵的品名、價格和數量，當然配圖的話比較直觀，因為有些品名實在太長，只看品名用戶還真不知道到底是什麼。

2、對商品的操作 ，對商品的操作包含了：多選，變更數量，刪除和結算，多選是為後面幾個功能服務。

3、包括優惠在內的訂單金額信息的顯示 ，這主要是配合商品的操作，因為數量上的變更可能會引起優惠、價格上的變動。所以購物車需要顯示包括單價、總價、優惠、運費，跨境電商的稅費等在內的金額信息，方便用戶進行購物決策。

上述的三個功能基本也是一個用戶使用購物車的流程

作者研究了5個競品的PC端和移動APP或H5，發現購物車的設計基本PC端和移動端差別不大，顯示的信息基本相同，所做的一般就是把信息重新排布，按鈕移到操作熱區等一系列適應移動端特點的的變化。但也有一些不同。

淘寶和網易考拉購物車無法直接編輯數量 。京東、蘇寧易購和阿里巴巴可以。淘寶和考拉都是需要點擊右上標簽欄中的編輯才能跳出數量的加減。

淘寶的設計比較好理解， 其商品下包含了較多的子選項 ，即一個大的商品下根據大小、顏色等的不同，可能有十多二十個具體商品，單純在購物車內數量加減容易出錯，其PC端可以進行加減操作是因為加減操作頁面同時能夠進行具體商品的選擇， 兩個選擇能在一個頁面的彈窗內實現 。

但對於手機淘寶來說，因為移動端屏幕大小的限制，不能把規格選擇和數量選擇做到同一個界面里，為了降低出錯幾率，手機淘寶把數量和規格都放到了「編輯」這個頁面里

至於考拉為什麼不能在購物車里變更數量，並沒有想到很好的原因，希望能想到的人告知。

⑷ 2002-04-02是什麼類型的數據,電

Copyright © 1999-2020, CSDN.NET, All Rights Reserved

打開APP

上水若善
關注
2022/08/04、05 day01-2/02：Redis數據類型 原創
2022-08-05 20:40:19

上水若善

碼齡2年

關注
文章目錄
今日內容
數據存儲類型介紹
string
**Redis數據存儲格式**
**string類型**
**string類型數據的基本操作**
**string類型數據的擴展操作**
**string類型數據操作的注意事項**
**string類型應用場景**
**key的設置約定**
hash
list
今日內容
常用的數據類型一共有一下5種：

string
hash
list
set
sorted_set
數據類型實踐案例
數據存儲類型介紹
業務數據的特殊性

作為緩沖使用
原始業務功能設計
秒殺
京東618活動
天貓雙11活動
火車排隊購票
運營平台監控到的突發高頻訪問數據
突發時政要聞，被強勢關注圍觀
高頻、復雜的統計數據
在線人數
投票排行榜
附加功能
系統功能優化或升級
單伺服器升級集群
Session管理
Token管理
Redis數據類型（5種常用）

string
hash
list
set
sorted_set
string
Redis數據存儲格式
Redis自身是一個Map，其中所有的數據都是採用key:value的形式存儲
數據類型指的是存儲的數據的類型，也就是value部分的類型，key部分永遠都是字元串
string類型
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-2NBOyzvI-1659702772759)(en-resource://database/4938:1)]

存儲的數據：單個數據，最簡單的數據存儲類型，也是最常用的數據存儲類型
存儲數據的格式：一個存儲空間保存一個數據
存儲內容：通常使用字元串，如果字元串以整數的形式展示，可以作為數字操作使用，但其本質還是字元串
string類型數據的基本操作
添加/修改數據：set key value
添加/修改多個數據：mset key1 value1 key2 value2…
追加信息到原始信息後部（如果原始信息存在就追加，否則新建）：append key value
獲取數據：get key
獲取多個數據：mget key1 key2…
獲取數據字元個數（字元串長度）：strlen key
刪除數據：del key
(integer) 0 代表失敗
(integer) 1 代表成功
string類型數據的擴展操作
業務場景
大型企業級應用中，分表操作是基本操作，使用多張表存儲同類型數據，但是對應的主鍵id必須保證統一性，不能重復。Oracle資料庫具有sequence設定，可以解決該問題，但是MySQL資料庫並不具有類似的機制，那麼該如何解決呢？

解決方案：

設置數值數據增加指定范圍的值
incr key 如果是數值，則給value做增操作，每次增加1個單位
incrby key increment 增加指定的整數的值（可以為負數）
incrbyfloat key increment 增加指定的小數的值
設置數值數據減少指定范圍的值
decr key 如果是數值，則給value做減操作，每次減少1個單位
decrby key increment 減少指定的整數的值（可以為負數）
string作為數值操作

string在redis內部存儲默認就是一個字元串，當遇到增減類操作incr，decr時會轉成數值型進行計算。
redis所有的操作都是原子性的，採用單線程處理所有業務，命令是一個一個執行的，因此無需考慮並發帶來的數據影響。
注意：按數值進行操作的數據，如果原始數據不能轉成數值，或超越了redis 數值上限范圍，將報錯。
9223372036854775807（java中long型數據最大值，Long.MAX_VALUE）
Tips 1：

redis用於控制資料庫表主鍵id，為資料庫表主鍵提供生成策略，保障資料庫表的主鍵唯一性
此方案適用於所有資料庫，且支持資料庫集群
業務場景

「最強女生」啟動海選投票，只能通過微信投票，每個微信號每 4 小時只能投1票。
電商商家開啟熱門商品推薦，熱門商品不能一直處於熱門期，每種商品熱門期維持3天，3天後自動取消熱門。
新聞網站會出現熱點新聞，熱點新聞最大的特徵是時效性，如何自動控制熱點新聞的時效性。
解決方案

設置數據具有指定的生命周期
setx key seconds value 秒
例如：setex tel 10 1 當10s到達後，tel就失效為空了（沒有了）
例如：set tel 2 此命令已經更新，上面的語句已經沒有用了
psetex key milliseconds value 毫秒
例如：psetex tel 9999 1
Tips 2：
redis 控制數據的生命周期，通過數據是否失效控制業務行為，適用於所有具有時效性限定控制的操作

string類型數據操作的注意事項
數據操作不成功的反饋與數據正常操作之間的差異
表示運行結果是否成功
(integer) 0 -> false 失敗
(integer) 1 -> true 成功
表示運行結果值
(integer) 3 -> 3 3個
(integer) 1 -> 1 1個
數據為獲取到
(nil) 等同於null 不存在
數據最大存儲量
512MB
數值計算最大范圍（java中的long的最大值）
±9223372036854775807
string類型應用場景
業務場景

主頁高頻訪問信息顯示控制。
例如新浪微博大V主頁顯示粉絲數與微博數量
解決方案

在Redis中為大V用戶設定用戶信息，以用戶主鍵和屬性值作為key，後台設定定時刷新策略即可。
eg: user🆔3506728370:fans → 12210947
eg: user🆔3506728370:blogs → 6164
eg: user🆔3506728370:focuss → 83
例子：set user🆔00789:blogs 789
例子：set user:id00789:fans 123456789
在Redis中以json格式存儲大V用戶信息，定時刷新（也可以使用hash類型）
eg: user🆔3506728370 →
{「id」:3506728370,「name」:「春晚」,「fans」:12210862,「blogs」:6164, 「focus」:83}
例子：set user🆔00789 {id:00789,blogs:789,fans:999}
使用這種方式： incr user🆔00789:blogs --> (integer) 790
Tips 3：
redis應用於各種結構型和非結構型高熱度數據訪問加速

key的設置約定
資料庫中的熱點數據key命名規范
* [
hash
存儲的困惑

hash類型

新的存儲需求：對一系列存儲的數據進行編組，方便管理，典型應用存儲對象信息
需要的存儲結構：一個存儲空間保存多個鍵值對數據
hash類型：底層使用哈希表結果實現數據存儲
hash類型數據的基本操作

添加/修改數據
hset key field value
例子：hset user name zhangsan
例子：hset user age 38
例子：hser user weight 80
獲取數據
hget key field
單查詢：hget user name
hgetall key
全查詢：hgetall user
刪除數據
hdel key field1 [field2]
刪除weight：hdel user weight
添加/修改多個數據
hmset key field1 value1 field2 value2…
例子：hmset user name zhangsanfeng weight 68 已經有的就改了，沒有的就加上去了。
獲取多個數據
hmget key field1 field2…
例子：hmget user name age -->純值
獲取哈希表中欄位的數量
hlen key
例子：hlen user 看的是field的欄位
獲取哈希表中是否存在指定的欄位
hexists key field
例子：hexists user age – (integer) 1 true
例子：hexists user hight – (integer) 0 false
hash類型數據擴展操作

獲取哈希表中所有欄位名或欄位值
hkeys key
例子：hkeys user 列印field
hvals key
例子：hvals user 列印value
設置指定欄位的數值數據增加指定范圍的值
hincrby key field increment
例子： hincrby user age 2 value欄位增加整數范圍內的值
hincrbyfloat key field increment
例子：hincrbyfloat user age 1.1 value欄位增加小數范圍內的值
hash類型數據操作的注意事項

hash類型下的value只能存儲字元串，不允許存儲其他數據類型，不存在嵌套現象。如果數據未獲取到對應的值為(nil)
每個hash鍵值對式有上限的，可以存儲2^32 -1個鍵值對
hash類型十分貼近對象的數據存儲形式，並且可以靈活添加刪除對象屬性，但hash設計初衷不是為了存儲大量對象設計的，切記不可濫用，更不可以將hash作為對象列表使用（隨著對象存儲的增多，會很麻煩，效率會很低）
hgetall操作可以獲取全部屬性，如果內部field過多，遍歷整體數據效率就會很低，有可能成為數據訪問瓶頸
hash類型應用場景
業務場景
電商網站購物車設計與實現

業務分析

僅分析購物車的Redis存儲模型
添加、瀏覽、更改數量、刪除、清空
購物車於資料庫間持久化同步（不討論）
購物車於訂單間的關系（不討論）
提交購物車：讀取數據生成訂單
商家臨時價格調整：隸屬於訂單級別
未登錄用戶購物車信息存儲（不討論）
cookie存儲
解決方案

以客戶id作為key,每位客戶創建一個hash存儲結構存儲對應的購物車信息
將商品編號作為field，購買數量作為value進行存儲
添加商品：最佳全新的field與value
瀏覽：遍歷hash
更改數量：自增/自減，設置value的值
刪除商品：刪除field
清空：刪除key
購物車實現

用戶001 商品g01 g02
hmset 001 g01 100 g02 200
用戶002 商品g02 g04 g05
hmset 002 g02 1 g04 7 g05 100
給001用戶添加一個商品 g03 添加field
hset 001 g03 5
查看用戶001的所有商品
hgetall 001
用戶001 的g01商品不要了 刪除field
hdel 001 g01
用戶001 的 g03商品 在加10個 添加field對應的值
hincrby 001 g03 10
提問：我們當前的設計是否加速了購物車的呈現？
當前僅僅是將數據存儲到了Redis中，並沒有起到加速的作用，商品信息還需要二次查詢資料庫

⑸ 電商的購物車確認刪除按鈕設計的為什麼不跟軟體卸載的

因為功能訴求根本不一樣好不啦？
軟體卸載界面把確認按鈕弱化，是利用了人類的「3分鍾熱度「現象，用戶需要卸載一個軟體，往往是卸載想法→卸載操作→最終卸載，如果充分的拖延操作的過程，分散用戶注意力，用戶有一定幾率失去卸載的熱度，忘卻卸載的初衷，最終導致繼續使用該軟體（如360/金山等最初佔領廣大電腦小白的桌面，就是利用了電腦小白不想麻煩的心理。）
對於軟體卸載而言，大部分用戶的態度是模稜兩可，對於這部分用戶，卸載界面的弱化是一種重要的防止用戶流失的做法。

⑹ 購物網站如何設計漂亮且實用的購物車

相應的，大量的購物網站也隨之出現。如何設計兼顧美觀與可用性的網站購物車，是一門非常有研究價值的問題。本文為讀者介紹了10個優秀購物車的設計技巧，並為讀者推薦了一些國外的優秀購物車設計欣賞。1. 整版車和迷你車購物車通常有兩種形式，整版頁面的購物車和作為網頁組件的迷你購物車。建議兩種形式同時包括。迷你購物車不影響購物車以外的布局，只顯示購物的列表及簡要信息，並且有一個醒目的鏈接指向整版購物車頁面，下面是一個很好的例子：相反的，整版購物車頁面可以提供更詳細的信息，例如產品詳情、刪除/添加、稅收和發貨選項等。以下顯示了一個整版購物車頁面，它的右上角同時也包含了一個迷你購物車： 2. 結賬：逐步引導或一頁式用逐步引導的方法使用戶更容易上手。看看Apple.com結帳頁面，結帳程序包含四個步驟：登錄，結算及托運，付款方式和最後確認/修改。 除了循序漸進的引導，另一種方式是把所有的付費、運輸和結算操作放在一個頁面上。 如果設計得合理，這也是一種很好的方式。下面的網站使用了良好的單頁結帳過程： 3. 使用圖標鏈接到詳細頁面迷你購物車上應該有鏈接到詳細頁面的醒目圖標，以引導用戶進入詳細頁面。下面這個網頁雖然是日語的，但它的圖標可以清晰的顯示這是購物車鏈接。4. 使用明顯的結賬/添加按鈕設計電子商務購物車，重要的是要包含明確的信息 ，並引導客戶進入結賬程序。最好使用明顯的按鈕，並包含清楚易懂的文字，如「添加到購物車」或「結賬」。 5. 使用清晰整潔的列表設計購物車最好使用列表結構，清晰的現實信息，使用標准字體 ， 並盡量避免使用復雜的背景 。6. 「繼續選購」鏈接「繼續購物」鏈接的作用是引導用戶回到商品列表繼續選購，這當然是所有網站都想要的。 7. 避免填寫過多的條目盡量讓用戶填寫最少的表格，用最快的速度完成網上購物過程。 8. 提供充分的幫助信息快速提示和通用提示是網站必不可少的組成部分，尤其是購物網站，你要讓你的客戶沒有任何疑問和疑慮的完成購物過程。關於電子商務網站的提示技巧，請參閱： 正確使用提示文字提升用戶體驗9. 使用視覺輔助使用圖標、箭頭、文字等醒目的視覺輔助元素，引導用戶的視覺流向。以下圖片顯示的一個極方便的單擊並拖動車 。.形象的購物車圖標告訴顧客，他們可以拖動物品到購物車。 10. 包含確認步驟用戶必須有一個步驟來確認是不是買到了正確的貨物，並且有辦法及時取消選擇，然後進入付款結算程序。

⑺ 現存在購物車的不足

購物車的不足有：
1、市場上的購物車缺少一個相對較小的密閉的空間去讓顧客存放一些比較貴重的物品。2、購物車缺少分隔設計，因為當物品較多時，一些易碎的物品的完整性往往得不到保證。3、購物車的靈活性仍然有待改變，物品重量達到一定程度時，購物車往往就變得難以操控。4、對於殘障人士這類弱勢群體，購物車如何設計的方便供他們使用等。
超市購物車泛指我們在超市購物使用的購物設備的一種，是我們生活中不可或缺的工具，在進行超市購物時使用購物車，一方面可以提高買家更多的需求，另一方面更加提高了賣家的成交量，可謂一舉兩得的雙贏結果。

⑻ 淘寶購物車的資料庫怎麼設計

無非兩種：
一種就是把購物車里的商品存在資料庫里
另一種就是用session或者cookie這種方式存儲在客戶端。
如果你是使用.net開發，那麼可以直接把添加購物車信息的函數放到「加入購物車」按鈕的事件里，如果是asp這種的，你可以做一個加入購入車動作的頁面，用來處理商品加入購物車的動作。
這個頁面接受商品信息和來自頁面的url,處理完畢直接response回去就可以了！

⑼ 電商剖析：解密購物車邏輯

在電商的核心交易流程中，購物車是一其中非常重要的一環，也是其中最復雜的一個環節。在做電商流程中，可以簡單的把業務領域劃分成兩部分，一部分是底層支撐業務模塊，一部分是上層流程串流程的模塊。

底層支撐的模塊，比如，庫存系統、會員系統。這些模塊的特點是，所處理的業務流程相對單一、閉環，不需要太多依賴外部系統既可以完成領域內的邏輯。

如會員系統最重要的流程就是注冊、登錄、校驗登錄態。這幾個流程基本只依賴會員系統自身，沒有對外部系統產生強依賴，強耦合。

比較復雜的是串業務流程的系統，這部分系統業務邏輯會相對更復雜些，比如商詳或者購物車。因為商祥或者購物車所展示給用戶看到的東西需要串聯非常多的業務模塊，將其中的信息進行封裝組合展示給用戶，這里的業務邏輯非常復雜，系統內部的交互非常多。

我們以京東的購物車為例，簡單的剖析一下京東的購物車大體背後的業務邏輯，實現方式。

購物車中所展示的東西，無非就是加入購物車中的商品以及一些促銷信息。那麼第一個問題是，這些購物車中的商品、促銷信息是靜態的還是動態獲取的？

所謂靜態就是指用戶在將商品加入購物車的時候，在購物車中存儲加入購物車的商品所需要展示的各種信息。例如上面展示的商品的主圖文描，促銷等等。

動態獲取就是在查看購車的時候，再去實時調用相應的系統獲取最新的信息。

答案是，購物車的數據只會存儲必要的商品信息，其他的信息完全是動態獲取的。

因為在加入購物車的時候如果是靜態存儲的，那麼在下一次查看購物車的時候，所展示的信息可能就不是最准確的。這中間可能商品信息會發生變化，比如商品被下架了、商品的主圖被調整了、或者主題被修改了、商品的促銷信息也可能會發生變化，在加入購物車的時候可能會命中一個促銷，但是過了一段時間之後，這個促銷可能結束了。所以比較精準的做法是在展示購物車的時候，再去實時拉取一次商品的詳細信息以及當前的最新促銷信息。

但是購物車中還是會存儲一部分數據，主要存儲哪些數據呢？主要如下圖所示。

那麼下面我們來看一下，查看購物車背後到底有哪些邏輯？

第一步首先是校驗會員的登錄態。上面購物車存儲的結構中，我們看到購物車的存儲是以用戶維度進行數據存儲的，所以要展示購物車的時候，首先要拿到用戶的ID。所以這里第一步就會校驗登陸態，因為只有用戶登錄後才能識別當前的用戶具體是誰？才可以從購物車的存儲中獲取響應的數據。然後購物車會根據取到的商品ID列表再去實時調用一次商品系統來獲取最新的商品信息，最終組裝後進行展示。

下一步是獲取庫存信息。庫存情況由於變更比較頻繁，所以每次查看購物車的時候也需要實時的去查看當前商品的庫存情況。如果購物車中的商品沒有庫存，那麼就要進行提示，如下圖所示，在購物車中將此商品置灰，提示此商品「無貨」。

庫存這里還有一個比較特殊的邏輯，就是贈品的邏輯。贈品分為兩種情況，一種是滿多少元送一個贈品，簡稱「滿贈」。另外一個是買一個東西送一個贈品，簡稱「買贈」。兩種都是贈品，但是對於庫存的邏輯處理完全不一樣。

這兩種情況都會要求主商品跟贈品必須要在同一個倉。不然就會出現主品從一個倉發貨，贈品從另外一個倉發貨。要承擔兩份運費的成本。本來就是贈送一個贈品，如果還需要額外承擔運費的話，那麼肯定不劃算。所以在校驗庫存的時候，一定會校驗主品跟贈品是否都在同一個倉有貨

當贈品跟主品不在同一個倉或者贈品沒貨的時候。對於滿贈這種場景，如果贈品沒有庫存，那麼還是可以正常下單的。因為滿贈這種促銷類型會給用戶進行提示「贈品數量有限，先到先得」。所以贈品沒貨的時候也是可以正常下單的，用戶也是能接受的。但是買贈這種場景，如果贈品沒有貨，那麼會提示用戶贈品無貨，不可以下單。因為這種場景用戶會認為贈品是主品的一部分，沒有贈品也就不會去買這個主品了。

獲取完庫存之後，下一步會計算購物車中商品促銷的情況。這也是整個購物車中邏輯最復雜的一部分。促銷本身就比較復雜，因為會存在多種促銷類型，如果某個商品同時命中多個促銷怎麼辦？如果商家設置了非常多的促銷，每一次都需要拿購物車中的商品去遍歷計算每個商品命中哪個促銷規則，整個計算過程也非常耗時。所以購物車會將商品列表傳給促銷系統，促銷系統根據購物車中傳遞過來的商品去計算，這些商品會命中哪些促銷，然後將這些商品按照命中的促銷進行分門別類返回給購物車。比如一個購物車中一個商家下有若干個商品。其中兩個命中了a促銷，另外兩個命中了b促銷，還有三個沒有民主促銷。那麼要按照結構返回給購物車，購物車再展示給到用戶，這樣用戶看的會比較清晰些。

在購物車中除了展示基本的商品信息，還有很多額外的功能，比如計算運費。上圖中會顯示這一個商品包郵免運費。那麼運費是如何計算出來的呢？

其實在商家後台有一個叫做運費模板的東西。商家會設置運費的策略，主要分為兩種規則。一種是根據單個商品去設置運費的規則，一種是根據訂單維度去設置模板。

單品維度指的是某一個商家的某個商品在某些地址需要收多少錢運費。這種的應用場景是當商家發現有些商品發到偏遠地區比較貴的時候，會設置這樣一個單品模板。

比如某個商品發到新疆、西藏、甘肅比較貴，那麼就可以設置這個商品在這三個省收學費15元，反之只要收貨地址不是這三個省的，那麼這個商品就不收運費。

另外一種是訂單維度的模板，也就是按照訂單維度來計算，整個訂單收多少運費。

舉個例子，比如我們經常見的江浙滬包郵。那麼這個模板應該如何設計呢？首先是選好一個商家，然後選好江浙滬的地址。在這些地址設置一個規則訂單，不滿0元運費0元。江浙滬之外需要收10元的運費，那麼再設置一下，除了江浙滬之外的省份。訂單不滿100元收取10元運費。這樣就達到了江浙滬包郵，江浙滬之外的地區需要有門檻，達到100元不收運費，但是不足100元需要收10元運費。

購物車中每一個商家頭部有一個領券的標識。來標識這個商家目前可以有優惠券可以領。這個領券設計的目的是為了讓用戶能夠在最關鍵的環節知道有券可以用，從而提升購物車的轉化率。那麼這個功能是如何做到的呢？

在購物車中會將商品按照商家的維度分成不同的塊。每一個塊代表一個商家，商家裡面的商品如果有促銷信息，按照塊的維度再去展示促銷的信息。領券的計算單位是商家的維度，在購物車中首先將商品根據不同的商家計算好分塊之後，每一個塊都代表一個商家，購物車會去計算當前商家下面以及當前商家購物車中的商品是否有可以領用的優惠券。如果這個商家制了10個批次的優惠券，其中2個批次的券可以使用當前購物車的商品，並且用戶還沒有領券，那麼就會在這個地方進行提示，告訴用戶有可以領用的券。

購物車中還有一個叫做預估到手價。之前購物車中只展示了哪些商品可以命中哪些促銷，但是每一個單品最終成交的價格需要用戶自己去算一下。由於促銷疊加起來比較復雜，有些用戶自己也算不清楚。所以這個預估到手價就是系統根據當前疊加促銷、券之後算出來的一個最終成交的價格。這個功能省去了用戶自己去計算的過程，並且很直觀明了的展示出來了，最終的成交價對用戶提升轉化也有很大的幫助。那麼這個預估到手價是如何實現的呢？

首先會先去計算購物車中商品的價格。有沒有單品維度的價格促銷，比如，價格直降或者秒殺、拼團之類的價格優惠。也就是上圖顯示的「119」，這個是價格維度的計算。在計算好單品價格維度之後，會再去計算一下當前商品是否有命中訂單維度的促銷，比如滿減或者折扣。這個時候會在單品的價格基礎上再減去命中促銷的價格，算出一個優惠價。然後在這個價格基礎上會再去命中一次優惠券的邏輯，去看一下用戶手中有哪些券可以使用。最終再去減去優惠券可以使用的價格，那麼就是用戶實際成交的價格，也就是一個預估到手價。

這里舉一個例子，一個商品原價100塊。做了一個價格直降的活動，拼團或者秒殺，價格降到90。然後這個商品還享受了一個滿減的優惠，滿80減20。這個時候這個單品的價格就變成了90-20=70。如果這個用戶的賬戶中，還有一張可以用於這個商品的現金10元券。那麼這個商品最終到手的價格就是70元，再減去10元的優惠券等於60元。

通過上面幾個過程，系統就可以幫你算出來每一個商品在當前情況下的一個預估到手的價格。

總結下，購物車是整個電商交易流程中比較復雜的一個環節，需要串聯會員、商品、庫存、促銷、優惠券等大部分邏輯進行最終的購物車的呈現。為了保證購物車展示給用戶信息的准確性，購物車只存了最基本的一些信息，絕大部分的信息都是在用戶查看購物車那一剎那實時計算出來的。