B2B2C分銷商城系統開發解析-首篇

B2B2C分銷商城大系統是一款基於移動互聯網的電商應用服務產品，經過在微信中創建購物商城，實如今線購物功能的一款系統軟件。

 

---

b2b2c分銷系統，第一個B指廣義的賣方（即成品、半成品、材料提供商等），第二個B指交易平臺，即提供賣方與買方的聯繫平臺，同時提供優質的附加服務，C即指買方。其中，中間的B（平臺）絕非簡簡單單的中介，而是提供高附加值服務的渠道機構，擁有客戶管理、信息反饋、數據庫管理、決策支持等功能的服務平臺。中間的這個B是電子商務模式的核心重點。

B2B2C多用戶分銷商城系統開發 找陳洋₁₅₀₁₃₁₅₁₇₄₀T/V，F2C，C2C，B2C等大型電商平臺（微商城 + WAP + Android APP + IOS APP + PC+小程序）

b2b2c分銷系統對於網站經營採用了兩種模式經營方案，如A、B。且對管理員後臺能夠進行設置，模式以下：

 

---

b2b2c分銷系統 

A：供應商入駐網站發佈商品分銷→站長審覈商品→入駐商家挑選商品進貨併發布到店鋪→買家挑選商品→買家支付貨款→站長訂單通知供應商（商家）發貨→供應商（商家）發送貨給買家→買家確認收到商品→供應商收貨款→網站收取提成→供應商（商家）申請提現→交易完成。 

B：站長髮布商品分銷→入駐商家挑選商品進貨併發布到店鋪→買家挑選商品→買家支付貨款→站長（商家）發貨→買家確認收到商品→商家賺提成,站長收貨款→商家申請提現→交易完成。 

---

 首先來講一下B2B2C多用戶商城系統的框架：以下↓

1、緩存

    一、數據緩存

    二、頁面、文件等緩存

        相似淘寶、京東都是把圖片、文件緩存在用戶本地，下次再訪問就直接訪問本地文件，若是訪問沒有，就去CDN服務器上下載，下載也是經過集羣分發形式，下載最近的服務器文件。下載到本地以後，就作永久保存，不作刪除，若是須要修改文件，就改文件名就好了。

 

2、分佈式圖片服務器

    相似FastDFS等，這個有java、php、.net等客戶端，支持多語言，很是不錯

3、集羣

    這個是老生常談，必需要作的，一個須要注意的是session的統一管理

4、分佈式

   將一些訪問量高的接口獨立出來，作成服務化的方式，服務化不必定非得用dubbo，其實阿里的不少開源產品，代碼質量寫的也不咋樣，只不過你也沒有更好的替代品了，畢竟它是通過那麼多考驗的了。目前咱們公司有本身定製的dubbo。

 

5、數據庫讀寫分離、分庫分表

   這個主要是DBA作的，數據庫作成支持讀寫分離、分庫分表

 

6、大表處理

   大表通常目前能夠作分區表，可是分區表也是有隱患的，最好前期就支持分表的，根據業務常常劃分

   推薦技術：一、sharding-jdbc，在jdbc層作分表，目前支持mybatis、hibernate、jpa等等，須要開發負責

             二、mycat，經過代理的形式，這個只須要運維負責就行

 

 

 

---

 

最近幾年微信公衆號三級分銷程序挺火的，關於微信的程序開發，功能點比較多，如消息推送、自定義菜單，jssdk集成，支付接口等等，本文主要討論一下會員三級關係的數據庫設計。從優化角度來從新設計。

 

分銷結構操做文檔：

首先看一下傳統的表設計：

如下是一張會員信息表，這裏WxId是微信公衆號的id(因我設計的這個程序是要支持多個微信公衆號的），UserId是當前會員id,下圖中的Pid就是會員的上一級用戶id

 

下面看一下數據：

 

根據上圖，userid=1的這個會員Pid爲0的說明會員是頂級的，沒有任何人推廣。userid=2的這個會員pid爲1，說明他是userid爲1的會員推廣而來。而後看userid=7的這個會員，他的pid=2，說明他是userid=2的這個會員推廣來。說白了推廣關係就是：

userid(1)->userid(2)->userid(7)

userid(1)->userid(3)

userid(1)->userid(4)

userid(1)->userid(5)

userid(1)->userid(6)

那麼咱們要查詢一個會員（假設他的id爲1）全部的推廣一級會員，對應的sql就是：select * from t_user where Pid=1，這裏沒有什麼問題，到是不難

 

那繼續來，要查詢他的二級或是三級分銷會員的話，就麻煩了，須要使用子循環了。對應的代碼以下：

public String gets(int pid){

  StringBuffer sb=new StringBuffer(sb);

  ArrayList list=(ArrayList)DaoFactory.getUserDAO().exe("select id,Pid from t_user where Pid="+pid);

  for (Iterator iter = list.iterator(); iter.hasNext(); ) {
        DataField df=(DataField)iter.next();

  sb.append("<li>"+df.getInt("id")+"</li>");

//遞歸調用

sb.append(gets(df.getInt("id")));

 

  }

}

上面看到了，主要解決辦法就是遞歸調用。雖然功能也能實現，但在數量比較大的狀況下，很容易產生性能問題（這裏只是查找會員，若是在統計每一個級別下會員的消費，收入統計時，須要和消費表關係查詢，那性能不知卡到何時）。

下面重點來了，咱們從新設計一下表，這裏咱們主要是經過數據庫設計來解決，咱們知道數據庫存儲數量量不怕多，因而咱們想，能夠這樣，每當用戶推廣一個會員的時候，咱們向一個表（暫且叫做用戶關係表）寫入他的級別關係不就好了嗎。好比 a推廣了b，而後b推廣了c,c推廣了d，這樣我咱們就向數據庫中寫一個記錄b以上三級的關係。

看一下表中的數據

上圖中，除了原來的會員表，咱們新增長了個會員關係表：t_user_relations

這裏看到，ChildId=2的這個會員，他是id爲1（Pid=1)的一級分銷用戶(FxLevel=1)

ChildId=7的這個會員，數據庫中有兩條記錄，一個是：他是id爲2（Pid=2)的一級分銷用戶(FxLevel=1)，再就是他是id爲1（Pid=1)的二級分銷用戶(FxLevel=2)，因此不難理解，若是一個會員上面有三級的話，這裏應該有三條記錄。簡單理解就是，當用戶新增長時，將此用戶上面全部級別對應的用戶信息記錄到用戶關係表中。

這樣，當咱們要查詢一個會員全部一級會員時，可使用sql:select * from t_user_relations where Pid=1 and FxLevel=1

全部二級會員sql:select * from t_user_relations where Pid=1 and FxLevel=2

全部三級會員sql:select * from t_user_relations where Pid=1 and FxLevel=3

當咱們須要統計三級會員的消費總額的時候，能夠很方便使用sql:select sum(t_pay.Money) from t_user_relations,t_pay where t_user_relations.ChildId=t_pay.Userid and t_user_relations.Pid=1 and t_user_relations.FxLevel=3

同理查詢二級會員的消費：select sum(t_pay.Money) from t_user_relations,t_pay where t_user_relations.ChildId=t_pay.Userid and t_user_relations.Pid=1 and t_user_relations.FxLevel=2

那要查詢全部子會員的消費怎麼辦？總不能寫三個sql吧，固然不會了。使用條件FxLevel>0不就能夠了嗎：）

select sum(t_pay.Money) from t_user_relations,t_pay where t_user_relations.ChildId=t_pay.Userid and t_user_relations.Pid=1 and t_user_relations.FxLevel>0

 

 

這樣一個sql就解決了。若是使用一開始使用的遞歸方法，隨着數據量的增加，速度會很是很是的糟糕。

上面你還可能 還會問一個問題，那若是知道某個會員他是誰的一級，誰的二級呢,.....？這須要用到第一個方法設計的表了，看到了，上面的表設計咱們仍是要用到:)

select Pid from t_user where id=2

if(Pid!=0)說明還不是頂級，繼續查。這裏能夠 使用遞歸查詢或作三次查詢（經過 pid是否爲0，這樣有的可能只是一級或兩次查詢，最多就是3次），放心，這樣的不會太影響性能的，能夠忽略不計。

或者把id,pid數據放到緩存裏，redis是個不錯的選擇。你們能夠試下了。

最後看一下偶開發的效果：）