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是个不错的选择。你们能够试下了。

最后看一下偶开发的效果：）