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、數據緩存
2、頁面、文件等緩存
類似淘寶、京東都是把圖片、文件緩存在用戶本地，下次再訪問就直接訪問本地文件，如果訪問沒有，就去CDN服務器上下載，下載也是通過集群分發形式，下載最近的服務器文件。下載到本地之后，就做永久保存，不做刪除，如果需要修改文件，就改文件名就行了。
二、分布式圖片服務器
類似FastDFS等，這個有java、php、.net等客戶端，支持多語言，非常不錯
三、集群
這個是老生常談，必須要做的，一個需要注意的是session的統一管理
四、分布式
將一些訪問量高的接口獨立出來，做成服務化的方式，服務化不一定非得用dubbo，其實阿里的很多開源產品，代碼質量寫的也不咋樣，只不過你也沒有更好的替代品了，畢竟它是經過那么多考驗的了。目前我們公司有自己定制的dubbo。
五、數據庫讀寫分離、分庫分表
這個主要是DBA做的，數據庫做成支持讀寫分離、分庫分表
六、大表處理
大表一般目前可以做分區表，但是分區表也是有隱患的，最好前期就支持分表的，根據業務經常划分
推薦技術：1、sharding-jdbc，在jdbc層做分表，目前支持mybatis、hibernate、jpa等等，需要開發負責
2、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是個不錯的選擇。大家可以試下了。
最后看一下偶開發的效果：）
