[產(chǎn)品設(shè)計(jì)]電商設(shè)計(jì)知乎總結(jié)，產(chǎn)品設(shè)計(jì)電商總結(jié)

?

想做一個(gè)B2B2C的電商平臺(tái)，在后臺(tái)數(shù)據(jù)統(tǒng)計(jì)搭建的時(shí)候需要注意哪些問題？如何設(shè)計(jì)具體的統(tǒng)計(jì)模塊？

?

王于萍：

我認(rèn)為在建數(shù)據(jù)庫(kù)前，需要設(shè)計(jì)好的，是需求和流程，有了這一步的需求，你就知道了在這里你需要什么數(shù)據(jù)；有了流程，你就知道了你能得到什么數(shù)據(jù)，甚至于數(shù)據(jù)類型。

比如供應(yīng)商管理，你會(huì)得到供應(yīng)商的公司地區(qū)、電話、類目等，在數(shù)據(jù)統(tǒng)計(jì)中，你可以對(duì)地區(qū)、類目統(tǒng)計(jì)，再根據(jù)C的對(duì)應(yīng)需求推薦等

?

?

PalmWong：

建議先從業(yè)務(wù)理解開始：

BBC平臺(tái)，首先分成三個(gè)后臺(tái)

商家門戶+平臺(tái)運(yùn)營(yíng)門戶+買家個(gè)人門戶

?

要做統(tǒng)計(jì)的部分同樣是三塊：

1、消費(fèi)者個(gè)人視角出發(fā)：個(gè)人的消費(fèi)統(tǒng)計(jì)

2、平臺(tái)運(yùn)營(yíng)的視角出發(fā)：整個(gè)平臺(tái)的運(yùn)營(yíng)情況統(tǒng)計(jì)，針對(duì)商家的運(yùn)營(yíng)情況統(tǒng)計(jì)

3、商家視角出發(fā)的統(tǒng)計(jì)

?

BBC商城其實(shí)是非常復(fù)雜的業(yè)務(wù)系統(tǒng)，因?yàn)榻巧凸δ艿淖兓瑢?dǎo)致其中數(shù)據(jù)交互其實(shí)非常多。且對(duì)賬、統(tǒng)計(jì)、權(quán)限管理異常情況很多。

?

不是看著天貓的模式，就閉著眼睛可以做的。

?

用 PHP+MySql 架構(gòu)用戶數(shù)和訪問量為千萬(wàn)級(jí)別的類似淘寶商城那樣的 B2C 網(wǎng)站，如何？

?

Dion：

系統(tǒng)架構(gòu)很重要！

?

語(yǔ)言：

主流語(yǔ)言都沒什么問題。PHP、Java什么的都行。

?

前端服務(wù)器：

如果有條件CDN，最好。沒有的話，一定要保證前端的負(fù)載性能。一般推薦Nginx。

?

應(yīng)用服務(wù)器：

集群?jiǎn)h。前端負(fù)責(zé)負(fù)載均衡。集群的話，Session的問題注意下就行。別的沒什么。

?

數(shù)據(jù)存儲(chǔ)：

如果數(shù)據(jù)量比較大的話（百萬(wàn)級(jí)），用MySQL + Memcached做集群沒問題。

如果數(shù)據(jù)量再大的話，考慮NoSQL吧。比如Facebook用Cassandra，Amazon用Dynamo。

?

socici：

你可以簡(jiǎn)單點(diǎn)，從用戶訪問的數(shù)據(jù)角度看

靜態(tài)文件,包括圖片、HTM 、JS、css 這些不經(jīng)常變的數(shù)據(jù)。 單獨(dú)給個(gè)域 如http://static.xxxx.com 由nginx管理

通過前后臺(tái)發(fā)布的動(dòng)態(tài)數(shù)據(jù)，分以下幾種：

讀的數(shù)據(jù)：

1.需要用戶查詢的大數(shù)據(jù)，如訂單之類的，可以去查slaver的數(shù)據(jù)庫(kù)

2.系統(tǒng)公共頁(yè)面顯示的數(shù)據(jù)，如部分商品信息、排行榜之類的可以去緩存里取

寫的數(shù)據(jù)：

要求即時(shí)生效的，如修改用戶信息，直接同步寫到master數(shù)據(jù)庫(kù)

即時(shí)要求不高或者有并發(fā)限制的，如發(fā)微博、發(fā)私信之類的 先寫到隊(duì)列，異步讀取保存到數(shù)據(jù)庫(kù)

?

電商平臺(tái)中商品規(guī)格設(shè)計(jì)的問題，拋出，求吐槽？

?

商品表（商品名稱、價(jià)格、上下架等一些商品基本的信息）

例如：1、 手機(jī)、100

規(guī)格表（主鍵、商品ID、規(guī)格名稱 ）

例如：1 、1、運(yùn)營(yíng)商

商品規(guī)格值表（主鍵、規(guī)格ID、商品ID、規(guī)格值ID、規(guī)格值NAME）

例如：1、1、1、0、電信版

2、1、1、1、移動(dòng)版????

規(guī)格庫(kù)存表（商品ID、規(guī)格值ID組合、規(guī)格值NAME組合、庫(kù)存量、價(jià)格）

例如：1、1/0(運(yùn)營(yíng)商、電信版)、運(yùn)營(yíng)商/電信版、100個(gè)、100塊

?

問題描述：

?

以上方式可實(shí)現(xiàn)多規(guī)格多庫(kù)存但是采用一種約定的規(guī)格順序，感覺在編寫程序時(shí)，系統(tǒng)在后期統(tǒng)計(jì)不同規(guī)格相關(guān)的數(shù)據(jù)就會(huì)很痛苦。

并且在實(shí)現(xiàn)商品創(chuàng)建時(shí)，要先把商品創(chuàng)建好后，才能創(chuàng)建規(guī)格，個(gè)人參考一些大的電商平臺(tái)方式，發(fā)現(xiàn)都是一個(gè)提交完成商品創(chuàng)建。

?

需要的幫助：

?

需要結(jié)合我的問題描述，給一個(gè)合理的商品多規(guī)格、多價(jià)格、多庫(kù)存的設(shè)計(jì)方案，來(lái)解決我編程上的復(fù)雜度，同時(shí)保證我可以在商品創(chuàng)建的交互設(shè)計(jì)中簡(jiǎn)單。

?

socici：

商品分類 （類型id,類型名稱，父ID）

商品表（商品名稱、價(jià)格、上下架等一些商品基本的信息、商品分類）

?

規(guī)格表（主鍵、規(guī)格名稱 ）

規(guī)格值表（規(guī)格值ID、規(guī)格id、規(guī)則值類型、規(guī)格默認(rèn)值）

規(guī)格-分類關(guān)聯(lián)表（商品分類id，規(guī)格id)

?

商品-規(guī)格關(guān)聯(lián)表(商品id,規(guī)格id,規(guī)格值ID,規(guī)格實(shí)際值）

?

庫(kù)存表（商品id,數(shù)量,價(jià)格)

?

類似淘寶關(guān)于產(chǎn)品詳情頁(yè)的數(shù)據(jù)庫(kù)存儲(chǔ)是怎么存儲(chǔ)的呢？

?

1，每個(gè)產(chǎn)品的 圖片數(shù)和介紹的段落數(shù)都是不固定的,是采用編輯器編輯好之后生成html整個(gè)存儲(chǔ)到數(shù)據(jù)庫(kù)么？不現(xiàn)實(shí)吧？

2. 要是以數(shù)據(jù)庫(kù)字段存儲(chǔ)到話,每個(gè)產(chǎn)品的 圖片數(shù)和介紹的段落數(shù)是不固定的,就算設(shè)置一個(gè)上限,那也會(huì)浪費(fèi)很多字段啊

3.在查詢的時(shí)候,如果圖片和介紹文字是分開存儲(chǔ)的,那么在查詢之后頁(yè)面展示的時(shí)候是怎么 將某一圖片和關(guān)于介紹他的問題相匹配的呢

?

劉傳雙：

總體來(lái)說

1、商品的結(jié)構(gòu)化信息保存在數(shù)據(jù)庫(kù)，名稱、價(jià)格、庫(kù)存、屬性等，當(dāng)然不是簡(jiǎn)單的一張表。

2、商品的非結(jié)構(gòu)化信息保存成小文件，存儲(chǔ)在自主開發(fā)的海量小文件系統(tǒng)中，圖片和商品描述信息。

3、商品的圖片文件id需要存儲(chǔ)在數(shù)據(jù)庫(kù)或者其他類型的存儲(chǔ)的，不一定非要多個(gè)字段，這是水平方式，一般把商品的一個(gè)圖片存儲(chǔ)為一條記錄，縱向擴(kuò)展。

4、文檔在存儲(chǔ)之前，先保存圖片，并把文檔中的圖片src地址替換為小文件系統(tǒng)中的圖片路徑，就可以了

?

補(bǔ)充一句，不能把存儲(chǔ)理解成只有數(shù)據(jù)庫(kù)和文件系統(tǒng)，存儲(chǔ)有各種類型的，不同的文件系統(tǒng)、各種RDBMS、NoSql存儲(chǔ)……

?

子柳：

其實(shí)幾位同事已經(jīng)回答了，我再?gòu)臍v史的角度做個(gè)補(bǔ)充

最早這個(gè)字段確實(shí)是放在數(shù)據(jù)庫(kù)里面的，是一個(gè)clob字段，存放的就是html的片段。而且當(dāng)時(shí)這個(gè)字段跟商品的標(biāo)題、價(jià)格、賣家ID等等是在一個(gè)表里面的，性能會(huì)受到多大影響是可以想象的。

所以這種方式是注定長(zhǎng)久不了的，我在2005年，把這個(gè)字段單獨(dú)分離出來(lái)一張表來(lái)存放了，這沒多少技術(shù)含量，當(dāng)時(shí)卻給數(shù)據(jù)庫(kù)減輕了很大壓力，DBA們很感謝我。

在2006年以后，淘寶開始大規(guī)模的采用緩存，這個(gè)字段也放進(jìn)了緩存里面，于是這又給數(shù)據(jù)庫(kù)減輕了很大壓力（只有不在緩存里的數(shù)據(jù)，才去數(shù)據(jù)庫(kù)里面讀取，讀出來(lái)就放入緩存了）。

到了2007年，淘寶開發(fā)了分布式文件存儲(chǔ)系統(tǒng)TFS，于是就徹底的把這個(gè)字段請(qǐng)出了數(shù)據(jù)庫(kù)，一同請(qǐng)出的還有交易快照這樣的大字段信息。

?