• Java生鲜电商平台-促销系统的架构设计与源码解析（生鲜电商促销方案）
• 10、生鲜电商平台-财务系统模块的设计与架构
• 24、生鲜电商平台 - 系统报表设计与架构
• 26、生鲜电商平台-RBAC系统权限的设计与架构
• 38、生鲜电商平台-会员积分系统的设计与架构

Java生鲜电商平台-促销系统的架构设计与源码解析（生鲜电商促销方案）

Java生鲜电商平台-促销系统的架构设计与源码解析

说明：本文重点讲解现在流行的促销方案以及源码解析,让大家对促销，纳新有一个深入的了解与学习过程.

10、生鲜电商平台-财务系统模块的设计与架构

前言:任何一个平台也好，系统也好，挣钱养活团队这个是无可厚非的，那么对于一个生鲜B2B平台盈利模式( 查看：http://www.cnblogs.com/jurendage/p/9016411.html)而言，

其中财务模块无论是对于买家而言还是卖家而言都至关重要，老百姓对钱的看重是没有经历的人想不到的，一句话说清楚了：一分钱也不能少。

买家或者卖家对财务模块的要求很简单：

                              1. 账清楚明白。

                              2. 消费清清楚楚。

                              3. 计算准确无误。

对平台而言：财务的要求是每笔资金的输入与输出，有理有据，真真实实。

我们分两个模块来讨论，买家与卖家我们称为客户财务模块，平台我们称为公司财务模块

1. 客户财务模块

      1.1 买家需要查看任何一天的消费记录。数据按照时间的倒叙排列，根据时间进入某天的消费记录，需要查看当天的历史订单数据。

            业务中按照时间来分组，数据是来源于订单表：

            相关业务核心代码如下：

/**
     * 订单列表
     * 
     * @description 1.用户的所有订单列表。 2.支付状态 3.交易状态.
     * @param request
     * @param response
     * @param orderStatus
     *            0 待支付 1待送达 2已完成
     * @return
     */
    @RequestMapping(value = "/order/list", method = { RequestMethod.GET, RequestMethod.POST })
    public JsonResult buyerOrderList(HttpServletRequest request, HttpServletResponse response, Long buyerId,
            int orderStatus) {

        List<OrderListVo> listVo = new ArrayList<OrderListVo>();

        // 需要顺序
        Map<String, List<OrderInfoVo>> resultMap = new TreeMap<String, List<OrderInfoVo>>(new Comparator<String>() {
            public int compare(String obj1, String obj2) {
                // 降序排序
                return obj2.compareTo(obj1);
            }
        });

        try {
            List<OrderInfo> orderList = orderInfoService.getAllOrderInfo(buyerId, orderStatus);

            // 判断是否有订单
            if (CollectionUtils.isEmpty(orderList)) {
                return new JsonResult(JsonResultCode.SUCCESS, "订单查询成功", listVo);
            }

            // 组装Map对象
            for (OrderInfo order : orderList) {
                List<OrderInfoVo> resultList = new ArrayList<OrderInfoVo>();

                OrderInfoVo orderInfoVo = transform(order);

                String time = DateUtil.dateToString(order.getCreateTime(), "yyyy-MM-dd");

                if (resultMap.get(time) == null) {
                    resultList.add(orderInfoVo);
                    resultMap.put(time, resultList);
                } else {
                    List<OrderInfoVo> mapList = resultMap.get(time);
                    mapList.add(orderInfoVo);
                    resultMap.put(time, mapList);
                }
            }

            // 组装VO
            Set<String> keys = resultMap.keySet();
            for (String data : keys) {
                OrderListVo vo = new OrderListVo();
                vo.setDate(data);
                vo.setList(resultMap.get(data));
                listVo.add(vo);
            }
            return new JsonResult(JsonResultCode.SUCCESS, "订单查询成功", listVo);
        } catch (Exception ex) {
            logger.error("[OrderController][buyerOrderList] exception :", ex);
            return new JsonResult(JsonResultCode.FAILURE, "系统错误,请稍后重试", "");
        }
    }

说明：买家而言其实就是待支付，已经支付等订单的明细查询，根据时间进行分组，根据时间（按照天来计算，查看自己的明细。），然后查询出整个订单明细即可。

相关运营截图如下：

    1.2  对于卖家而言，他肯定想知道每天具体卖了多少东西，多少钱，但是不是针对某一个买家而言，是针对整个统计而言。

          比如：他想知道我今天卖了土豆多少共多少斤，白菜多少斤，萝卜多少斤，花菜多少斤等等，同时他自己会算出今天的利润多少。

        补充说明：其实系统是可以算出来今天他挣钱多少的，但是客户很讨厌输入进货价，相当于把自己的“秘密”出卖了一样，整个系统架构中

先前是有的，但是实际运营发现，不是我们的那个样子，最终是去掉了。

          相关的业务核心代码如下：（数据也是来源于订单明细表中）

订单主表的列表：

/**
     * 查询买家需要确认的订单列表
     */
    @RequestMapping(value = "/order/list", method = { RequestMethod.GET, RequestMethod.POST })
    public JsonResult orderList(HttpServletRequest request, HttpServletResponse response,Integer type,Long saleId) {
        try {
            List<OrderVo> orderList = orderService.getOrderList(type, saleId);
            return new JsonResult(JsonResultCode.SUCCESS, "查询信息成功", orderList);
        } catch (Exception ex) {
            logger.error("[OrderController][orderList] exception :", ex);
            return new JsonResult(JsonResultCode.FAILURE, "系统错误,请稍后重试", "");
        }
    }

根据订单号获取订单明细：

/**
     * 查询买家需要确认的订单列表
     */
    @RequestMapping(value = "/order/detail", method = { RequestMethod.GET, RequestMethod.POST })
    public JsonResult getOrderDetail(HttpServletRequest request, HttpServletResponse response,Long orderId) {
        try {
            OrderDetailVo odv = orderService.getOrderDetail(orderId);
            return new JsonResult(JsonResultCode.SUCCESS, "查询信息成功", odv);
        } catch (Exception ex) {
            logger.error("[OrderController][getOrderDetail] exception :", ex);
            return new JsonResult(JsonResultCode.FAILURE, "系统错误,请稍后重试", "");
        }
    }

订单明细VO:对象：

/**
 * 订单详情VO
 */
public class OrderDetailVo implements java.io.Serializable {

    private static final long serialVersionUID = 1L;
    /**
     * 订单主表id,order_info表的order_id
     */
    private Long orderId;
    /**
     * 唯一订单号
     */
    private String orderNumber;
    /**
     * 买家ID
     */
    private Long buyerId;
    /**
     * 买家店铺名称
     */
    private String buyerName;
    /**
     * 买家店铺图片
     */
    private String buyerLogo;
    /**
     * 买家地址
     */
    private String buyerAddress;
    /**
     * 买家姓名
     */
    private String bossName;
    /**
     * 买家手机
     */
    private String bossTel;
    /**
     * 收货人的最佳送货时间
     */
    private String bestTime;
    /**
     * 订单创建时间
     */
    private String createTime;
    /**
     * 商品列表
     */
    private List<OrderGoodsVo> goodsList;
    
    public Long getOrderId() {
        return orderId;
    }
    public void setOrderId(Long orderId) {
        this.orderId = orderId;
    }
    public String getOrderNumber() {
        return orderNumber;
    }
    public void setOrderNumber(String orderNumber) {
        this.orderNumber = orderNumber;
    }
    public Long getBuyerId() {
        return buyerId;
    }
    public void setBuyerId(Long buyerId) {
        this.buyerId = buyerId;
    }
    public String getBuyerName() {
        return buyerName;
    }
    public void setBuyerName(String buyerName) {
        this.buyerName = buyerName;
    }
    public String getBuyerLogo() {
        return buyerLogo;
    }
    public void setBuyerLogo(String buyerLogo) {
        this.buyerLogo = buyerLogo;
    }
    public String getBuyerAddress() {
        return buyerAddress;
    }
    public void setBuyerAddress(String buyerAddress) {
        this.buyerAddress = buyerAddress;
    }
    public String getBossName() {
        return bossName;
    }
    public void setBossName(String bossName) {
        this.bossName = bossName;
    }
    public String getBossTel() {
        return bossTel;
    }
    public void setBossTel(String bossTel) {
        this.bossTel = bossTel;
    }
    public String getBestTime() {
        return bestTime;
    }
    public void setBestTime(String bestTime) {
        this.bestTime = bestTime;
    }
    public String getCreateTime() {
        return createTime;
    }
    public void setCreateTime(String createTime) {
        this.createTime = createTime;
    }
    public List<OrderGoodsVo> getGoodsList() {
        return goodsList;
    }
    public void setGoodsList(List<OrderGoodsVo> goodsList) {
        this.goodsList = goodsList;
    }
}

相关SQL核心：

<!-- 订单详情 -->
  <select id="getOrderDetail" resultMap="orderDetailMap">
      select 
        o.order_id,o.order_number,o.buyer_id,b.buyer_name,b.buyer_logo,b.buyer_address,b.boss_name,b.boss_tel,
        date_format(o.best_time,''%Y-%m-%d %H:%i'') as best_time,date_format(o.create_time,''%Y-%m-%d %H:%i'') as create_time,
        oi.item_id,oi.remark,g.goods_id,g.goods_name,g.goods_brand,g.goods_label,
        gf.format_id,gf.format_name,u.unit_id,u.unit_name,gf.format_num,
        pm.method_id,pm.method_name,oi.goods_price,oi.goods_number,oi.goods_amount,
        gp.pic_id,gp.pic_url,gp.is_main,gp.pic_seq
     from order_item oi
        inner join order_info o on o.order_id=oi.order_id
        inner join buyer b on b.buyer_id=o.buyer_id
        inner join goods_format gf on gf.format_id=oi.format_id
        inner join goods g on gf.goods_id=g.goods_id
        inner join unit u on gf.unit_id=u.unit_id
        left join process_method pm on pm.method_id=oi.method_id 
        left join goods_picture gp on g.goods_id=gp.goods_id
     where oi.order_id=#{orderId} 
     order by gp.is_main desc
  </select>

疑问一：为什么会贴出如此多的代码吗？尤其是SQL? 

理由只有一点：的确这块比较复杂，很多都是基于SQL语句的查询，需要SQL功底。

相关的业务运营截图如下：

下面的核心的历史收益这块，卖家可以扔掉自己的手抄本了。根据这个平台就可以方便的明细的账单记录

补充说明：数据报表有金额，有数据，有统计，有分析，包括以后的折线图，柱状图等等报表分析，让用户明确的知道今天挣钱多少，明天预警备货多少，一切清楚明了。

总结：我的经验是所有的人心与人性都是相同的，你需要功能的客户其实也想看到，对于这种模式的采用，我们是经历了很多都经验后才总结出来的，

          看起来很简单，其实背后的努力不简单。一起努力做好生鲜电商。

转载自-- https://www.cnblogs.com/jurendage/p/9049318.html

24、生鲜电商平台 - 系统报表设计与架构

说明：任何一个运行的平台都需要一个很清楚的报表来显示，那么作为 Java 开源生鲜电商平台而言，我们应该如何设计报表呢？或者说我们希望报表来看到什么数据呢？

          通过报表我们可以分析出目前整个公司的运营情况，以及下一步的调整方向，这样更加有理有据的掌握整个市场与决策。

设计基础维度：

         1. 今日订单，今日营业额，总订单数，总营业额

         2. 今日的注册买家，总的注册买家。

         3. 实时的营收，实时的下单买家。

         4. 今日下单买家，空降 A (空降 A 指的是今天注册同时下单的客户)

数据的力量在于清楚的明白的告诉整个系统运营人员，昨天我们的销售团队创造了多少的业绩，以及整个趋势是怎么样的，今天的努力方向是怎么样的，昨天的所获是怎么样的

如何进行一起努力与学习。

业务分析： 今日订单，今日营业额，总订单数，总营业额等来源于订单表以及订单汇总表。鉴于数据量并不是很大，所以可以实时的进行查询。

                    如果存在数据量过大，比如订单表我们有 100w 的数量，那么可以采用定时器在规定的时间内进行执行，然后把统计结果放在统计表中

统计表的系统设计如下：

CREATE TABLE `report_days` (
  `id` bigint(20) DEFAULT NULL,
  `order_number_count` int(11) DEFAULT NULL COMMENT ''今日订单数'',
  `order_rmb_count` decimal(12,2) DEFAULT NULL COMMENT ''今日营业额'',
  `order_number_amount` int(11) DEFAULT NULL COMMENT ''总订单数'',
  `order_rmb_amount` decimal(12,2) DEFAULT NULL COMMENT ''总营业额'',
  `create_time` datetime DEFAULT NULL COMMENT ''创建时间''
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT=''每日报表'';

说明：其实就是向这里面进行数据的更新与增加操作即可，每天进行报表的读取与显示

           不过有些网友提出采用缓存来处理，我个人的意见是不需要。数据也没那么多，而且都是定时器来执行，缓存的价值与意义很小。

相关的执行代码如下：

@Component
public class TaskReport {

    private static final Logger logger=LoggerFactory.getLogger(TaskReport.class);
    
    @Autowired
    private BuyerOrderReportService buyerOrderReportService;
    
    @Autowired
    private ReportDayService reportDayService;
    
    @Autowired
    private BillService billService;
    /**
     * 计算每天报表;
     *    每日上午6:00触发
     */
    @Scheduled(cron="0 0 6 * * ?")
    protected void day(){
        try{
            logger.info("TaskReport.day.start");
            //统计每天订单报表;
            Integer today = 0;//0表示今天    1表示昨天;
            reportDayService.insertBatch(today);
            //统计买家每日订单金额;
            buyerOrderReportService.insertBatch(today);
        }catch(Exception e){
            logger.error("TaskReport.day.exception",e);
        }finally {
            logger.info("TaskReport.day.end");
        }

2. 相关的报表的形状显示，目前折线图，柱状图是比较理想的一种方式，采用百度的 echarts 进行显示

相关的运行实例如下：

 补充说明：相关的 echarts 的用法，这边就不列举了，的确蛮简单的，返回 json 给 echarts 所需要的数据格式即可。

代码这里只贴出相对核心的代码：

public class IndexController extends BaseController {

    private static final Logger logger = LoggerFactory.getLogger(IndexController.class);
    
    @Autowired
    private OrderInfoService orderInfoService;

    @Autowired
    private OrderItemService orderItemService;

    @Autowired
    private SalesService salesService;

    @Autowired
    private BuyerService buyerService;

    @Autowired
    private SellerService sellerService;

    @Autowired
    private ReportedService reportedService;

    @RequestMapping(value = "/index", method = { RequestMethod.GET, RequestMethod.POST })
    public String index(HttpServletRequest request, HttpServletResponse response, Model model, Long areaId) {

        logger.info("[IndexController][index] :查询订单统计数据");
        try {

            // 查询订单总数量和金额
            Map<String, Object> totalMap = orderInfoService.getCountAndAmount();
            int totalCount = (int) totalMap.get("count");
            BigDecimal totalAmount = (BigDecimal) totalMap.get("amount");
            if (totalAmount == null) {
                totalAmount = BigDecimal.ZERO;
            }
            // 查询今日的订单总数量和金额
            Map<String, Object> todayMap = orderInfoService.getOrderCountAndAmountByToday();
            int todayOrderCount = (int) todayMap.get("count");
            BigDecimal todayOrderAmount = (BigDecimal) todayMap.get("amount");
            if (todayOrderAmount == null) {
                todayOrderAmount = BigDecimal.ZERO;
            }

            // 查询实时的订单总数量和金额
            Map<String, Object> realTimeRevenueMap = orderInfoService.getRealTimeRevenueCount();
            int realTimeOrderCount = (int) realTimeRevenueMap.get("count");
            BigDecimal realTimeOrderAmount = (BigDecimal) realTimeRevenueMap.get("amount");
            if (realTimeOrderAmount == null) {
                realTimeOrderAmount = BigDecimal.ZERO;
            }

            // 入驻买家数量
            int totalBuyerCount = buyerService.getBuyerCount(null);
            // 当日注册买家数量
            int todayBuyercount = buyerService.getDailyBuyerCount();
            // 当日入驻卖家数量
            int todaySellerCount = sellerService.getDailySellerCount();

            model.addAttribute("totalCount", totalCount);
            model.addAttribute("totalAmount", totalAmount);
            model.addAttribute("todayOrderCount", todayOrderCount);
            model.addAttribute("todayOrderAmount", todayOrderAmount);
            model.addAttribute("totalBuyerCount", totalBuyerCount);
            model.addAttribute("todayBuyercount", todayBuyercount);
            model.addAttribute("todaySellerCount", todaySellerCount);
            model.addAttribute("realTimeOrderAmount", realTimeOrderAmount);
            model.addAttribute("realTimeOrderCount", realTimeOrderCount);

            // 查询今儿下单买家数量和空降A;
            int order_buyerCount = orderInfoService.getBuyerCountByTodayOrder();
            int newBuyerNum = orderInfoService.getBuyerNumByThatDay();
            model.addAttribute("order_buyerCount", order_buyerCount);
            model.addAttribute("newBuyerNum", newBuyerNum);
            Reported reported = new Reported();
            reported.setrSolveStatus(1);
            int count = reportedService.getCount(reported);
            model.addAttribute("count", count);
        } catch (Exception ex) {
            logger.error("[IndexController][index] :exception", ex);
        }
        return "index";
    }

3. 对于卖家而言，我们的报表需要有以下几个维度来统计（统计最新的 TOP 的卖家）

        3.1   买家消费。

        3. 2  卖家收入

        3.3   热卖的菜品

        3.4   销售业绩

        3. 5  订单项最多的买家。

 这里面也是些统计的数据，相对而言跟上面的买家维度差不多，代码方面也类似，无外乎需要的是多点数据库的查询与统计即可。

总结：其实整个报表的设计与实现过程并不难，难的是你为什么要这样设计，你通过这个运营的后台给整个项目的运营能够带来怎么样的用户体验与指导，

            你需要通过数据来诊断这个销售团队过程中是否存在什么问题。有没什么刷单以及其他的作弊嫌疑在里面。

最后：很多人说系统功能很强大很好，但是我的一种思维方式是不一定，强大固然好，但是你需要通过这么多的系统数据中来分析出问题的关键，而不是所谓的代码堆积。

           你所需要的是思考，再思考，最终思考。

转载自 -- https://www.cnblogs.com/jurendage/p/9108863.html

26、生鲜电商平台-RBAC系统权限的设计与架构

说明:根据上面的需求描述以及对需求的分析，我们得知通常的一个中小型系统对于权限系统所需实现的功能以及非功能性的需求，在下面我们将根据需求从技术角度上分析实现的策略以及基于目前两种比较流行的权限设计思想来讨论关于权限系统的实现。

1.1.       技术策略

l         身份认证

在B/S的系统中，为识别用户身份，通常使用的技术策略为将用户的身份记录在Session中，也就是当用户登录时即获取用户的身份信息，并将其记录到Session里，当需要进行身份认证的时候通过从Session中获取用户的身份信息来实现用户的身份认证。

l         资源权限校验

资源权限校验取决于系统的授权模型，这块将在之后进行详细的阐述。

l         数据权限校验

数据权限校验取决于系统的授权模型，这块将在之后进行详细的阐述。

l         授权模型

授权模型作为权限系统的核心，从本质上决定了权限系统的易用性，这个易用性包括权限的授予和权限的校验，并同时也决定了权限的继承，权限的排斥和包含等方面的实现。

在经历了这么多年的发展，授权模型在目前中小型应用系统接受的比较多的主要有RBAC模型和ACL模型，将在之后展开专门的篇幅进行讲解。

l         权限校验的体现

权限校验的体现在中小型系统中体现出来的通常只是对于系统菜单、按钮显示的控制和对于拥有权限的数据的访问上。

它们共同依赖于资源权限校验和数据权限校验，对于系统菜单、按钮的显示上的控制在B/S中通常采用的技术策略为在生成菜单、按钮的Html时做权限级的判断，当操作主体不具备权限时则不生成该菜单、按钮的Html，从技术角度分析为方便使用者，避免使用者调用权限校验接口，通常的做法为提供菜单、按钮的标签，通过此标签生成的菜单和按钮即为经过权限过滤的。

l         高性能

为提高权限系统在授权以及校验权限时的性能，通常的做法为采用缓存技术以及加强权限系统的管理建设，加强权限系统的管理建设有助于建立一个最为适合需求的权限结构，同时做到了简化系统权限授予。

l         安全性

安全性方面来讲在B/S系统中通常有两个方面需要控制：

n         通过非法途径访问系统文件

在Java的Web应用中通常采用的技术策略为将需要受保护的文件放入WEB-INF文件夹中，大家都知道在WEB-INF下的文件除了在服务器上能直接访问外，通过普通的URL是无法访问到的。

其次的做法为做Filter，即对需要受保护的资源做访问的Filter，如操作者不具备权限则直接报出错误。

n         通过非法途径访问系统操作

通常采用的技术策略为对每个直接暴露对外的需要受权限保护的对象做操作级别的权限控制，简单来说在Web系统中通常采用MVC框架来实现，通常Command层是直接对外的，为防止用户通过URL或其他方式访问Command，从技术上我们需要考虑对现有系统的尽量少的侵入性，所以通常采用的做法是在Command之上做Before Interceptor或Proxy，在此Interceptor或Proxy中做权限的校验，以确认操作者具有相应的权限。

经过上面的描述，我们已经基本了解到满足权限系统需求的技术实现策略，从中我们也可以看出权限系统中最为重要的为授权模型，由于权限系统的通用性，在业界也是推出了不少的授权模型，在这里我们已目前比较通用的两种授权模型来具体讲解权限系统的完整实现。

1.2.       基于RBAC的实现

1.2.1.       RBAC介绍

RBAC模型作为目前最为广泛接受的权限模型，在此也将对其模型进行简要的介绍，RBAC模型成功的经典应用案例当属Unix系统了。

NIST（The National Institute of Standards and Technology，美国国家标准与技术研究院）标准RBAC模型由4个部件模型组成，这4个部件模型分别是基本模型RBAC0（Core RBAC）、角色分级模型RBAC1（Hierarchal RBAC）、角色限制模型RBAC2（Constraint RBAC）和统一模型RBAC3（Combines RBAC）[1]。RBAC0模型如图1所示。

图表 1 RBAC 0模型

l         RBAC0定义了能构成一个RBAC控制系统的最小的元素集合

在RBAC之中,包含用户users(USERS)、角色roles(ROLES)、目标objects(OBS)、操作operations(OPS)、许可权permissions(PRMS)五个基本数据元素，权限被赋予角色,而不是用户，当一个角色被指定给一个用户时，此用户就拥有了该角色所包含的权限。会话sessions是用户与激活的角色集合之间的映射。RBAC0与传统访问控制的差别在于增加一层间接性带来了灵活性，RBAC1、RBAC2、RBAC3都是先后在RBAC0上的扩展。

l         RBAC1引入角色间的继承关系

角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系仅要求角色继承关系是一个绝对偏序关系，允许角色间的多继承。而受限继承关系则进一步要求角色继承关系是一个树结构。

l         RBAC2模型中添加了责任分离关系

RBAC2的约束规定了权限被赋予角色时,或角色被赋予用户时,以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。责任分离包括静态责任分离和动态责任分离。约束与用户-角色-权限关系一起决定了RBAC2模型中用户的访问许可。

l         RBAC3包含了RBAC1和RBAC2

既提供了角色间的继承关系，又提供了责任分离关系。

1.2.2.       实现方案

通过上面章节对RBAC的介绍，从RBAC模型中我们可以看出它已经实现了一个使用起来很方便的授权模型，并同时也就权限的继承，权限的排斥和包含提出了解决的模型。

那么现在的关键是我们需要来看看基于RBAC到底是怎么实现权限系统的需求的呢？在这里我们针对在技术策略中未描述的授权模型和权限校验部分做实现方案的讲解。

l         授权模型

授权模型遵循RBAC进行搭建，即建立如上图表一的模型。

针对授权模型中的几个关键部分我们进行描述：

n         授权

按照RBAC的模型，在授权时分为配置资源以及资源的操作、授予角色对资源的操作权限、分配角色给用户这几个步骤来完成。

从这几个步骤我们进行分析：

u       配置资源以及资源的操作

实现这步非常的简单，直接维护资源以及资源操作两个对象的持久即可实现。

u       授予角色对资源的操作权限

实现这步同样非常的简单，维护角色与资源的关联模型即可。

u       分配角色给用户

实现这步同样非常的简单，维护角色与用户的关联模型即可。

n         权限的继承

权限的继承在RBAC的模型中通过增加角色的自关联来实现，即角色可拥有子角色，子角色继承父角色的权限。

按照此模型可以看出在授权时维护权限的继承也是非常的简单，维护角色的自关联模型即可。

n         权限的排斥和包含

权限的排斥和包含这块我没有具体看RBAC的规范，通常的做法是通过在资源的操作权限模型中增加自关联模型以定义哪些资源的操作权限是排斥和包含的，在授权时可以看到同样需要维护的只是资源权限的自关联模型。

l         资源权限校验

根据上面的授权模型，在做资源权限校验的时候需要经过以下步骤：

n         判断用户所在的角色是否拥有对资源进行操作的权限

获取用户所拥有的角色，遍历其角色，以各角色建立Session，并通过类似的role.doPrivilege(Resource,Operation)的方式来判断该角色是否具备权限，如具备则直接返回，如不具备则直到遍历结束。

n         递规用户所在角色的父角色判断是否拥有对资源进行操作的权限

当遍历完用户本身的角色得到用户不具备对资源进行该操作的权限时，则开始递规其所在角色的父角色来判断是否拥有对资源进行操作的权限，过程同上，如确定某角色具备，则返回，如不具备直到递规结束。

l         数据权限校验

在RBAC模型中没有明确定义数据权限的实现策略，鉴于此首先要讲解下基于RBAC模型的数据授权模型的建立，基于RBAC模型，将数据映射为RBAC中的资源，对数据的操作则映射为资源的操作，同样的是将此资源以及资源的操作构成的权限授予给角色，将用户分配给角色完成数据权限的授权过程。

但根据数据权限校验的需求，数据的权限也是需要继承的，而且数据权限的授予对象需要是多种，这样的话就对上面根据RBAC映射形成的数据权限的授权模型造成了冲击，需要重构上面的授权模型来满足需求。

为实现数据权限的继承，需要将RBAC模型中的资源重构为允许自关联的模型，为实现数据权限能够授予给多种对象，需要将本来资源操作权限授予给角色的模型演变为数据操作权限授予给角色、组织机构或具体人员，根据RBAC模型，同样的建立一个中间对象，此对象和数据操作权限所授予的对象做1对多的关联，在经过这样的重构之后数据权限的授权模型就形成了，也满足了数据权限的继承和授予给多种对象的需求。

图表 2 基于RBAC演变的数据权限模型

上面的图中少画了数据的自关联。
根据上面的数据权限模型，来看看数据权限的校验是怎么样去实现呢？

在做数据权限校验的时候我们需要实现的为两种方式，一种是获取操作主体具有数据操作权限的全部数据，另外一种为分页获取操作主体具有数据操作权限的数据。

就这两种方式分别来进行阐述：

n         获取操作主体具有数据操作权限的全部数据

从数据库中获取所有数据，遍历取出的数据从数据权限模型中获取相应的拥有数据操作权限的权限拥有者，如果该数据未配置数据操作权限的控制，那么就无需对该数据进行权限级的判断，如配置了，则需判断当前用户是否在该数据操作权限所对应的拥有者中，如用户不在，则需递规获取该数据的父数据的操作权限的拥有者，到用户拥有权限或递规结束时终止。

n         分页获取操作主体具有数据操作权限的数据

分页的做法和上面差不多，只是在获取了所有的数据后在内存中做分页返回。

1.2.3.       优缺点分析

从上面的基于RBAC的实现方案中可以看出基于RBAC模型的优点在于：

l         易用和高效的授权方式

用户在进行授权时只需对角色进行授权，之后将相应的角色分配给用户即可。

l         简便和高效的授权模型维护

在技术角度来讲，进行授权模型的维护上因为基本只需要维护关联模型而显得简单而高效。

 缺点在于：

l         复杂的权限校验

在进行权限校验时需要不断的遍历和递规，造成了性能的影响。

l         对于数据权限的不够支持

         没有明确的数据权限模型，可以看到在经过重构的数据权限模型其实已经和RBAC模型有一定的 
        出入，而且在数据权限的校验上实现起来是非常的低效。

最终根据说明，设计如下系统架构图：

一、设计规则定义

1.      数据库表明定义规则：t_ 模块名_表名

二、权限管理系统系统设计

1.      用户管理(t_sys_userInfo)

CREATE TABLE `t_sys_userInfo` (

`userId` VARCHAR(20) NOT NULL COMMENT ''用户主键'',

`userName` VARCHAR(20) NOT NULL,

`orgId` VARCHAR(20) NOT NULL COMMENT ''所属机构ID'',

`orgName` VARCHAR(50) NOT NULL COMMENT ''所属机构名称'',

`orgPath` VARCHAR(120) NOT NULL COMMENT ''所属机构路径'',

`userAccount` VARCHAR(16) NOT NULL COMMENT ''登录帐号'',

`userPwd` VARCHAR(16) NOT NULL COMMENT ''登录密码'',

`userMobile` VARCHAR(11) NULL DEFAULT NULL COMMENT ''移动电话'',

`isAdmin` DECIMAL(1,0) NOT NULL DEFAULT ''3'' COMMENT ''1、超级管理员2、企业管理员3用户'',

`lockFlag` DECIMAL(1,0) NOT NULL COMMENT ''是否锁住 1、锁住　0、未锁住'',

`departId` VARCHAR(20) NOT NULL COMMENT ''所属部门'',

`createBy` VARCHAR(20) NOT NULL,

`createName` VARCHAR(50) NOT NULL COMMENT ''创建人'',

`createTime` DATETIME NOT NULL COMMENT ''创建时间'',

`lastUpdateBy` VARCHAR(32) NOT NULL COMMENT ''最后修改人ID'',

`updateName` VARCHAR(50) NOT NULL COMMENT ''最后修改人'',

`lastUpdateTime` DATETIME NOT NULL COMMENT ''最后修改时间'',

PRIMARY KEY (`userId`)

)

COMMENT=''用户信息表''

COLLATE=''utf8_general_ci''

ENGINE=InnoDB

;

2.      资源管理(t_sys_resInfo)

CREATE TABLE `t_sys_resInfo` (

`resId` VARCHAR(32) NOT NULL COMMENT ''主键ID'',

`resName` VARCHAR(128) NOT NULL COMMENT ''资源名称'',

`parentId` VARCHAR(32) NOT NULL COMMENT ''资源父节点'',

`parentName` VARCHAR(128) NOT NULL COMMENT ''资源父节点名称'',

`resType` DECIMAL(1,0) NULL DEFAULT ''1'' COMMENT ''1、功能菜单　２、功能点　３、按钮'',

`resState` DECIMAL(1,0) NULL DEFAULT ''1'' COMMENT ''记录资源的状态(可用，不可用):0表示不可用，1表示可用'',

`resSort` DECIMAL(8,0) NULL DEFAULT ''0'' COMMENT ''资源排序 '',

`resUrl` VARCHAR(512) NULL DEFAULT '''' COMMENT ''资源URL地址'',

`leafCount` DECIMAL(1,0) NULL DEFAULT ''0'' COMMENT ''子节点数量'',

`resPath` VARCHAR(2048) NULL DEFAULT '''' COMMENT ''记录资源节点的路径：当前菜单的上级菜单，上级菜单的父级菜单'',

`iconCls` VARCHAR(20) NULL DEFAULT '''' COMMENT ''资源图标'',

PRIMARY KEY (`resId`)

)

COMMENT=''系统资源''

COLLATE=''utf8_general_ci''

ENGINE=InnoDB

;

3.      组织机构表(t_sys_org)

CREATE TABLE `t_sys_org` (

`orgId` VARCHAR(20) NOT NULL COMMENT ''组织主键'',

`orgName` VARCHAR(50) NOT NULL COMMENT ''组织名称'',

`orgShortName` VARCHAR(30) NULL DEFAULT NULL COMMENT ''组织简称'',

`parentId` VARCHAR(32) NOT NULL COMMENT ''组织父节点ID'',

`parentName` VARCHAR(50) NOT NULL COMMENT ''父节点编码'',

`orgType` DECIMAL(1,0) NOT NULL DEFAULT ''1'' COMMENT ''组织的类型 1、企业 2、部门 3、分公司,4,支行'',

`orgStatus` DECIMAL(1,0) NOT NULL DEFAULT ''1'' COMMENT ''记录组织的状态是否启用：0，停用/1，启用'',

`orgHisStatus` DECIMAL(1,0) NOT NULL DEFAULT ''1'' COMMENT ''0，停用/1，启用'',

`orgLinkMan` VARCHAR(50) NULL DEFAULT NULL COMMENT ''机构的法人代表名称'',

`orgTelephone` VARCHAR(20) NULL DEFAULT NULL COMMENT ''机构的联系电话'',

`orgFax` VARCHAR(20) NULL DEFAULT NULL COMMENT ''机构的传真'',

`orgEmail` VARCHAR(100) NULL DEFAULT NULL COMMENT ''机构的电子邮箱'',

`orgAddress` VARCHAR(200) NULL DEFAULT NULL COMMENT ''组织地址'',

`orgWebsite` VARCHAR(200) NULL DEFAULT NULL COMMENT ''组织的网站'',

`leafCount` DECIMAL(1,0) NULL DEFAULT NULL COMMENT ''子企业数量'',

`orgSort` DECIMAL(10,0) NULL DEFAULT NULL COMMENT ''组织排序'',

`resIconStyle` VARCHAR(20) NULL DEFAULT '''' COMMENT ''资源图标'',

`orgPath` VARCHAR(2048) NULL DEFAULT NULL COMMENT ''记录组织的节点路径'',

`createBy` VARCHAR(20) NULL DEFAULT NULL COMMENT ''创建人ID'',

`createName` VARCHAR(50) NULL DEFAULT NULL COMMENT ''创建人'',

`createTime` DATETIME NULL DEFAULT NULL COMMENT ''创建时间'',

`lastUpdateBy` VARCHAR(20) NULL DEFAULT NULL COMMENT ''最后修改人ID'',

`updateName` VARCHAR(50) NULL DEFAULT NULL COMMENT ''最后修改人'',

`lastUpdateTime` DATETIME NULL DEFAULT NULL COMMENT ''最后修改时间'',

PRIMARY KEY (`orgId`)

)

COMMENT=''组织架构信息''

COLLATE=''utf8_general_ci''

ENGINE=InnoDB

;

4.      组织角色表(t_sys_role)

CREATE TABLE `t_sys_role` (

`roleId` VARCHAR(20) NOT NULL COMMENT ''角色表主键ID'',

`orgId` VARCHAR(20) NULL DEFAULT NULL COMMENT ''所属组织'',

`orgPath` VARCHAR(20) NULL DEFAULT NULL COMMENT ''组织路径'',

`orgName` VARCHAR(50) NOT NULL COMMENT ''组织名称'',

`roleName` VARCHAR(50) NOT NULL COMMENT ''角色名称'',

`roleDesc` VARCHAR(100) NULL DEFAULT NULL COMMENT ''角色描述'',

`createBy` VARCHAR(20) NOT NULL COMMENT ''创建人ID'',

`createName` VARCHAR(50) NOT NULL COMMENT ''创建人'',

`createTime` DATETIME NOT NULL COMMENT ''创建时间'',

`lastUpdateBy` VARCHAR(20) NULL DEFAULT NULL COMMENT ''最后修改人ID'',

`updateName` VARCHAR(50) NULL DEFAULT NULL COMMENT ''最后修改人'',

`lastUpdateTime` DATETIME NULL DEFAULT NULL COMMENT ''最后修改时间'',

PRIMARY KEY (`roleId`)

)

COMMENT=''角色信息表''

COLLATE=''utf8_general_ci''

ENGINE=InnoDB

;

5.      用户角色表(t_sys_userRole)

CREATE TABLE `t_sys_userRole` (

`userRoleId` VARCHAR(20) NOT NULL COMMENT ''主键ID'',

`roleId` VARCHAR(20) NULL DEFAULT NULL COMMENT ''角色表主键ID'',

`userId` VARCHAR(20) NULL DEFAULT NULL COMMENT ''用户主键'',

PRIMARY KEY (`userRoleId`)

)

COMMENT=''用户角色关系表''

COLLATE=''utf8_general_ci''

ENGINE=InnoDB;

6.      角色资源表(t_sys_roleRes)

CREATE TABLE `t_sys_roleRes` (

`roleResId` VARCHAR(20) NOT NULL COMMENT ''角色资源主键ID'',

`roleId` VARCHAR(22) NOT NULL  COMMENT ''角色表主键ID'',

`resId` VARCHAR(20) NOT NULL  COMMENT ''资源主键'',

`isReadWrite` DECIMAL(1,0) NOT NULL DEFAULT 1 COMMENT ''1,只读取2，可读写'',

PRIMARY KEY (`roleResId`)

)

COMMENT=''角色资源关系表''

COLLATE=''utf8_general_ci''

ENGINE=InnoDB

7.      企业资源表(t_sys_orgRes)

  CREATE TABLE `t_sys_orgRes` (

`orgResId` VARCHAR(20) NOT NULL COMMENT ''角色资源主键ID'',

`orgId` VARCHAR(22) NOT NULL  COMMENT ''角色表主键ID'',

`resId` VARCHAR(20) NOT NULL   COMMENT ''资源主键'',

`isReadWrite` DECIMAL(1,0) NOT NULL DEFAULT 1 COMMENT ''1,只读取2，可读写'',

PRIMARY KEY (`orgResId`)

)

COMMENT=''角色资源关系表''

COLLATE=''utf8_general_ci''

ENGINE=InnoDB

相关运营截图：

转载自-- https://www.cnblogs.com/jurendage/p/9120168.html

38、生鲜电商平台-会员积分系统的设计与架构

说明：互联网平台积分体系主要用于激励和回馈用户在平台的消费行为和活动行为，一个良好的积分体系可以很好的提升用户的粘性及活跃度。

一、互联网平台积分体系设计必要性

互联网平台积分体系是一个独立、完整的系统模块，主要用于激励和回馈用户在平台的消费行为和活动行为，通过积分体系可以激发与引导用户在平台的活跃行为，逐步形成用户对平台的依赖性和习惯性，提升用户对平台的黏度和重复下单率。

积分体系在保持系统独立性的同时，又与平台会员系统、商品系统、订单系统等具有紧密的关联性，积分体系的规划设计需与平台其他系统模块同时设计开发，才能保证平台上线后的用户整体体验感知效果。

互联网平台建立积分体系的必要性归纳为以下几点：

• 通过积分体系有助于培养用户平台的使用习惯和对平台的依赖性；
• 通过积分体系可以提高用户在平台的转化率和重复下单率；
• 可以提升用户在平台的活跃度和对平台的感知体验效果；
• 增加用户参与平台各项活动的积极性和互动性，促进用户有效转化；

通过平台积分体系的建立，可以实现四个方面的作用：

1.对平台用户行为的导向性作用

不同互联网平台运营不同的激励手段和渠道，向用户传达产品和服务能够提供的功能，这些功能能够解决哪些问题，比如互联网平台的用户评论功能，用户下单完成后，对本次的服务过程作出评论，平台通过积分的赠送对评论的内容和用户评论的行为进行引导，实现用户的正向激励。

2.对用户正确行为的强化作用

基于用户对平台有了初步了解和熟悉之后，通过积分体系的设计可以激励用户做正确有效的事情，或者在一定时间段内，需要用户参与的各项营销活动，也是产品规划设计过程的核心主线。

比如：互联网平台从开发过程转入试运营阶段，需要快速提升平台访问量和曝光度，在尽短时间能够覆盖最大的用户群体，因此设计用户注册、邮箱验证、手机验证、实名验证等行为积分，以在试运营时间内注册的用户赠送一定积分的方式，快速吸引用户注册，实现平台试运营阶段的访问量目标。

平台进入持续运营阶段，需要提升用户下单率和用户有效转化率，因此通过设计消费积分（即设置下单消费赠送积分、促销商品购物积分、活动商品打折积分、订单满送积分等），引导促进用户下单和提高二次下单率，实现用户的有效转化。

3.对用户错误行为的弱化作用

通过积分体系的设计，可以对平台用户错误行为进行负激励，从而有效引导用户在平台的行为，促使用户行为按照产品规划的路线活动，根据用户行为是否满足产品规划需求进行加分和减分，对于用户错误的行为进行弱化。

比如：互联网平台用户投诉和评论环节，出现恶意投诉和恶意评论，影响到平台用户感知效果，通过扣减积分或配以锁定账号、禁止发布内容等方式，对用户的恶意投诉和评论行为进行弱化。

4.起到增加用户黏性的作用

互联网领域同质化和激烈的竞争环境，造成互联网平台除用户需要的功能内容外，竭力挖掘产品的可用性和用户价值，同时建立平台完整的积分体系，通过积分的升级和用户等级来提升用户对平台的依赖性，留住用户。比如在平台拥有较高积分值和等级的用户，流向其他平台的成本和门槛就很高，因此降低了用户流失的风险。

二、互联网平台积分体系设计步骤

基于对平台积分体系必要性分析的基础上，核心在于鼓励和引导用户的行为，因此在设计积分体系的过程中，需要对用户的平台行为进行分解和分类，根据不同行为需要强化的程度不同赋予不同的分值，以完整性积分体系规划原则进行积分体系设计划分为以下五大步骤：

1.分解产品功能

从用户需求的角度出发，对于平台的各项功能进行梳理和分解，归纳平台用户的不同行为，找出需要鼓励的行为。互联网平台功能流程梳理分析图如下：

2.分解识别用户行为

对于用户行为或者用户可进行的操作进行细化分解，比如用户完成帐户设置可以分解为上传用户头像、完成邮箱验证、完成手机验证等方面。具体的分解细化到用户的每一个不同操作。对用户行为（操作）的分解，不仅仅从产品价值的角度，还要从用户的角度，查看在这个产品上用户所有可能进行的操作，尤其是一些负面操作，不希望发生的操作经常会发生，在分解的过程要区分开。

用户行为归纳为注册、登录、身份验证、下单购物、评论、回复、参与商城活动、支付捆绑与开通、退换货、投诉、申请贷款、贷款进度查询、积分查询与兑换等主要方面。

3.根据产品及时间需要对用户行为进行分类评价，确定鼓励程度

完成了第2步的用户行为（操作）分解后，形成一个详细的用户行为列表，根据产品的需要，对这些行为进行分类和评价，给予每一个操作一个“鼓励程度”的评分，可以进行详细的分值设计，鼓励程度以正负值表示不同的激励方向，用户数值大小表示程度大小。根据鼓励程度，结合实际确定积分加分值及期限制，形成详细的积分体系表。尤其对每一行为进行积分分值确定的过程还同时考虑可能导致用户过度投机刷分的行为产生，避免积分体系发挥不了激励作用。

4.积分体系试运行

完成互联网平台积分体系设计后，进行积分体系上线试运行阶段。在试运行的过程中发现积分体系中的各种不足之处，并对此进行适当的调整，主要针对不同用户行为项分值和正负激励项加以测试，根据用户不同行为项的操作和体验效果，对分值和正负激励项进行调整优化，最终形成互联网平台完整的积分体系系统。

5.积分体系的阶段性调整

根据产品的发展周期，需要对积分体系进行阶段性的调整。在不同的时间段，产品需求希望鼓励用户的参与行为是不同，因此需要在不同的阶段对积分体系进行一定的调整，尤其是当产品进行了大规模的功能调整（增加或者删除功能等），更需要调整积分体系使其与产品发展保持一致。

、互联网平台积分体系架构设计

根据互联网平台积分体系设计过程及主流平台体系架构，提炼形成目前电子商务平台积分体系架构，从积分获取、积分使用消费、积分获取规则、积分消费规则、积分扣减和积分管理六大体系进行建设，具体如下图：

1、积分获取

（1）消费积分获取

消费积分获取是会员在平台消费所获得奖励积分，必须在平台消费完成支付且不存在退换货的情况下，系统按照积分获取规则，自动将会员消费积分充值到会员积分账户。消费积分具体划分为两类：

1）促销积分

商城针对不同节假日促销奖励积分，用户在节假日登录商城下单消费，将获得高于非节假日积分，如十一黄金周，会员消费可获得双倍积分；

商城根据不同类目商品销售情况，针对特定类目商品或特定商品进行促销，用户在促销时间内下单购买此商品，即可获得促销积分，如为提高某一商品的销售额，购买该商品即获得额外赠送100分，以此来刺激商品消费。

2）下单消费积分

只要用户在商城下单购物，根据消费积分规则将获得订单金额一定比例的奖励积分，通过下单消费积分，刺激用户下单购物，提高商城用户下单转化率和重复下单率。

（2）等级积分获取

商城等级积分获取与会员等级相关联，平台不同会员等级拥有不同的积分限制和范围，同时不同会员等级也拥有不同的平台权限，等级积分越高，会员等级就越高、权限越大。利用了人们自我价值的实现、接受肯定等方面的心理因素。对于每一个商城用户，都希望能够在一定程度上得到他人的认可和肯定，以其实现自我价值，这是马斯洛需求层次理论中的最高层次需求。为了体现用户在商城中的不同低位和身份，以等级模式将会员积分进行区分，不同等级积分拥有不同的低位和权限。

等级积分是基于用户消费积分和行为积分基础上，通过用户下单消费和不同的行为活动获取消费积分与行为积分，随着会员的消费积分和行为积分的不断累积，会员账户积分累积到一定的程度，满足等级积分的不同等级规则，即获取达到对应等级的积分。

（3）行为积分获取

行为积分主要是通过用户在商城平台上的各种行为活动而获得的奖励积分，依据平台功能流程分解，将用户行为积分归纳为：

2、积分获取规则

积分通过不同渠道获得，根据不同的获取方式和用户行为，积分对应的规则也不一样，积分规则只是对于积分获得多少的一个衡量标准，每个互联网平台的积分规则都不一样，但积分获取的方式和渠道基本一致，因此积分获取规则仅根据大部分互联网平台积分获取规则提供参考建议：

对于互联网平台基本积分就是用户通过平台下单购物获得积分，大部分平台都会给定基本积分标准，如消费1元获得1积分，即订单消费金额和积分比例为1:1，还有消费10元获得1积分，即订单金额和积分比例为10:1。

1）指定商品高倍积分：如一般商品获得积分比例1：1（消费1元得1积分），而指定商品可获得的比例是1：2（消费1元得2积分）；

2）指定时间段高倍积分：如一般时间获得积分比例1：1，而五一、国庆获得积分比例是1：3；

3）指定时间段指定商品双倍积分：如五一、国庆A类商品可获得比例是1：2；

4）不同会员等级不同积分获得：如高级会员1.5倍积分、VIP会员2倍积分；

5）不同价格区间不同积分获得：如1000以上的商品双倍积分；

6）不同价格区间、不同会员等级有不同的积分等级：

7）不同类型商品不同积分等级，如购买A类商品可以获得高倍积分；

8）购物满多少送积分，如购物小计满200赠10分，满500赠20积分，满500以上赠30积分；

9）不同会员级别额外赠分，如高级会员满100再赠送10分；

10）购物小计每满50送1分，如小计是230元，就可获得4分；

11）购物车中商品数量满多少送积分，如购物车中数量满5件赠10分；

12）给商品写评论和评分获得额外赠分；新用户注册可获得5积分奖励；

3、积分消费

（1）积分+现金消费

购买商品是指积分直接当现金使用，系统设置好兑换标准，如10个积分抵1元钱使用。用户在购买商品时可以选择用自己账户上的积分抵掉部分或全部现金。用户在使用积分+现金消费过程中，可以根据自身选择“积分+现金”支付或“现金+积分”支付，“积分+现金”支付是系统首先从用户积分账户按照兑换比例换算成现金，然后用换算成的现金支付，在积分换算的现金不足的情况下，系统会计算出差额，然后用户选择对应银行完成在线支付；而“现金+积分”支付是系统首先选择用户现金账户支付，在用户现金账户不足的情况下，会从积分账户按照差额完成订单支付。

此种消费方式需要系统进行对应功能开发，首先系统会将所有商品的价格按照积分规则换算成对应积分，按照商品价格与积分比例1:10，即230元的商品需要2300积分才能购买。然后用户选择商品下单后，系统按照用户选择的支付方式完成订单支付。

（2）兑换商品消费

兑换商品是指用户使用积分兑换相应的商品。商家可以挑选部分商品放在积分兑换区，设置好每个商品所需积分数，用户根据自己账户上的积分数量及兑换标准，直接可以获得商品，不需要支付现金（一般运费另付）。

商家后台需要对应开发配置用积分兑换商品功能，商家点击“积分兑换商品”弹出商家在线销售的所有商品列表，商家从中选择可以用积分兑换的商品，点击提交后，商品会自动被推荐到积分兑换区所属分类下，然后用户登录选择对应商品后，直接点击“兑换”按钮，进入用户收货信息填写页面，用户输入收货人、收货地址和联系电话后，点击“提交”即完成订单的支付，等待商家发货。

（3）兑换优惠券消费

兑换优惠券需要用户登录商城，进入用户管理中心操作，点击兑换优惠券后，选择需要兑换的数量，系统按照积分兑换优惠券规则，完成兑换，并实时扣除用户积分账户对应的积分，将剩余积分进行显示。同时用户在选择兑换优惠券数量时，可以选择兑换优惠券的面额，优惠券面额从10元、20元、50元、100元不等，用户可根据自身积分情况合理选择。

用户完成优惠券兑换后，点击“兑换记录”中的“优惠券兑换记录”，将显示用户所有用积分兑换优惠券的操作记录，涉及兑换时间、兑换优惠券面额、兑换数量、使用状态等参数，同时优惠券具有有效期，在优惠券即将过期的前一个月，系统会以“短信和站内信”的形式提醒用户，“优惠券即将到期，请尽快兑换使用”的内容，每个7天将自动提醒一次，优惠券有效期从兑换时间算起六个月内有效。

（4）积分赠送消费

积分赠送消费需要在用户管理后台开发对应的功能来实现，对于用户管理后台，需要开发积分赠送功能，即用户进入后台，点击“积分赠送”后，在“好友选择”列表中选择需要赠送积分的好友名称或账户名，并在“赠送金额”中输入需要赠送的积分金额，点击“提交”后，用户赠送的积分已经送出，用户可到“积分记录”中的“赠送记录”查看，涉及赠送时间、赠送人、赠送积分数量、积分接收状态（已接收、未接受、拒绝）等参数；积分接收用户登录用户中心，点击“积分管理”中的“接收积分”，将显示赠送时间、赠送人、赠送积分数量、接收/拒绝字段，点击“接收”后，对应的积分会自动累计到用户积分账户，而对方的积分账户也会相应扣除对应积分。

4、积分消费规则

积分消费规则将对应积分消费的方式和渠道，不同的消费方式有不同的积分消费规则，用户管理中心和商家管理中心的相关积分消费功能都是基于积分消费规则建立开发，具体积分消费规则如下图：

（1）积分+现金消费规则

积分+现金消费规则主要是积分与商品价格的兑换比例，通过对目前主流电子商务平台积分规则调研发现，商品价格与积分兑换比例一般为1:10，即120元的商品需要1200积分才能购买，用户下单购物后，系统会自动按照比例计算商品积分，并配合现金情况，此功能需要在用户填写订单信息和选择支付方式实现支付页面来实现，嵌入页面用户收货信息下方，根据用户选择的不同支付方式，对应计算所需积分。

（2）积分兑换商品消费规则

首先需要设定一个基本兑换商品标准，即商品价格与积分兑换比例为1:10，在此基础上，按照不同品类不同种类商品价值大小，对于商品价格在2000元以下的商品，兑换比例为1:10，对于商品价格在2000元以上的商品，兑换比例提升到1:15，相应的开发功能已在积分消费中体现。

（3）积分兑换优惠券规则

用户用积分兑换优惠券，兑换优惠券比例设定1:10，即用户兑换一张20面额的优惠券，需要200积分，用户积分是长期有效，但优惠券具有有效期，用户兑换优惠券后，必须在有效期内使用，过了有效期即失效，优惠券可以充当现金券使用，优惠券与现金券的比例为1:1。

（4）积分赠送消费规则

积分赠送主要是用户赠送的积分在一定期限内未被对方领取，即赠送的积分失效，会自动返还到用户积分账户，只有在一定的期限内，被对方领取后，赠送的积分才会从用户积分账户中扣除，并累积到接收方的积分账户，积分赠送具有有效期，有效期一般为7天。

5、积分扣减规则

积分扣减规则主要是对于用户错误行为的负激励，比如用户下单购物后，恶意投诉商家和对商品进行恶意差评等行为，已经直接和间接影响到平台用户和商家的经营服务，对于类似此种用户行为，将从用户积分账户中扣除5-15分，如用户积分账户无积分或不足情况，平台可直接对用户投诉内容进行删除或锁定用户ID，直接冻结用户的任何平台操作（必须在经过平台核查属实的情况下）；     而对于商户直接利用开店机会进行刷信用、刷交易等虚假操作，平台直接将其店铺进行冻结，冻结周期根据商户虚假交易的程度定。

1. 用户注册提供虚假资料，经平台核查后，直接扣减10分；
2. 用户连续3个月内未登录商城平台，视为恶意注册无效用户，直接冻结用户ID；
3. 用户出现恶意评价和恶意投诉，经平台核查后，直接扣除10分，对于积分不足用户直接锁定用户账户或ID；
4. 商家利用店铺虚假交易、刷流量、刷信用等行为，直接扣除15分，并锁定店铺ID或禁止发布商品。

6、积分管理

（1）会员积分管理

会员积分管理主要针对用户管理中心的积分管理功能，涉及会员积分查询、会员积分消费两大功能。

1）会员积分查询

会员积分查询包含会员当前总积分查询、会员积分获取记录、会员积分消费记录；

• 用户点击会员积分查询，系统自动显示当前用户积分账户总积分；
• 用户点击进入会员积分获取记录，将详细查看到积分的获取明细，涉及到积分获取时间、获取方式、获取积分数量字段；
• 用户进入会员消费记录，将详细查看到积分的兑换消费明细，涉及到兑换商品明细、积分兑换优惠券明细、积分赠送明细、积分兑换现金明细；兑换商品明细涉及到兑换时间、兑换商品名称、兑换积分数量字段；兑换优惠券明细涉及到兑换时间、兑换优惠券面额、兑换优惠券数量、兑换优惠券使用状态字段；积分赠送明细涉及到赠送时间、赠送人、赠送积分数量、赠送状态字段。

2）会员积分消费

会员积分消费包含积分兑换优惠券、积分赠送两个功能模块。

积分兑换优惠券流程：

• 用户点击“积分兑换优惠券”进入兑换优惠券页面；
• 用户选择兑换优惠券面额10元、20元、50元、100元；
• 选择对应优惠券面额的兑换数量；
• 用户点击“提交”后，兑换优惠券的积分将从用户积分账户中进行扣除，并且直接引导用户到兑换优惠券的明细页面，查看兑换详细情况；
• 系统会根据优惠券兑换时间，在有效期即将到期的最后一个月，以“短信和站内信”方式提醒用户，“优惠券即将到期，请尽快使用”的内容；并每隔7天向用户提醒一次。

积分赠送功能流程：

• 用户进入后台，点击“积分赠送”后；
• 在“好友选择”列表中选择需要赠送积分的好友名称或账户名；
• 在“赠送金额”中输入需要赠送的积分金额；
• 点击“提交”后，用户赠送的积分已经送出，用户可到“积分记录”中的“赠送记录”查看，涉及赠送时间、赠送人、赠送积分数量、积分接收状态（已接收、未接受、拒绝）等参数；
• 积分接收用户登录用户中心，点击“积分管理”中的“接收积分”，将显示赠送时间、赠送人、赠送积分数量、接收/拒绝字段，点击“接收”后，对应的积分会自动累计到用户积分账户，而对方的积分账户也会相应扣除对应积分。

（2）系统积分管理

1）统计积分管理

系统统计积分主要管理商城平台所有会员积分的获取、消费、兑换以及扣减等数据，包含查询所有会员积分、兑换积分和消费积分，同时提供EXCEL导出功能，具体包含管理员可以按照会员统计时间进行区段查看，对应会员积分可以按照会员名称、会员ID、会员积分范围值进行检索，快速锁定需要查看的会员积分和详细积分数据：

• 所有会员积分的获取，包含通过不同渠道方式获取的积分，获取时间、获取积分数量等字段；
• 可以按照条件（会员名称、会员ID、积分范围值）快速检索匹配性会员积分数据，点击“查看”将详细看到对应会员的积分来源、消费等数据；
• 点击右上角“EXCEL导出”，将快速导出对应会员积分的数据，利用EXCEL对积分数据进行统计分析；
• 查看所有会员总累计有效积分值(其中包括：销售积分值、活动送积分值),会员平均积分值，总消费积分总值(积分换优惠券),有效优惠券总额,过期优惠券总额，会员员平均持有优惠券金额和总计使用优惠券金额等数据。

2）送积分管理

送积分管理将查看、管理所有赠送积分用户的详细数据，包含赠送时间、赠送人和接收人、赠送积分数量、赠送积分状态等字段，由于用户赠送积分是从用户自有积分账户中扣除后，赠送给接收人的过程，是用户双方自由交易的行为，因此在送积分管理模块中，系统不干预用户赠送积分过程，但用户赠送积分的所有数据，都可以通过系统后台查看、管理。

• 系统管理员可以查看赠送积分用户的详细变化数据，包含赠送前积分、赠送后积分、赠送过程等数据；
• 送积分管理除过积分赠送外，还涉及用户行为的积分赠送，根据用户在商城平台的所有活动行为，按照各自的积分规则，进行赠送积分的配置，赠送积分可根据平台的发展阶段进行合理的调整，使其与产品的功能需求保持一致；
• 同时通过积分赠送明细，查看所有积分的赠送环节、发生时间、有效期和状态，同时可以对赠送积分的有效期进行有效配置。

3）积分兑换配置

积分兑换配置主要包含积分兑换商品配置、积分兑换优惠券配置和兑换现金配置。积分兑换操作管理、积分兑换明细查看、积分兑换条件筛选等。

积分兑换商品配置：

• 系统管理员可以查看商家推荐的积分兑换商品，并对积分兑换商品进行审核，审核通过后，积分兑换商品将展示在积分兑换专区；
• 可以查看所有积分兑换商品用户的订单数据，按日期查看所有积分兑换商品用户的兑换时间、兑换商品、兑换商品价格、兑换用户数、订单完成状态等字段数据；
• 点击“兑换配置”，输入积分兑换商品的比例，点击提交后，进入兑换明细，查看所有积分兑换商品的记录。

积分兑换优惠券配置：

• 查看所有积分兑换优惠券的记录，包含兑换日期、兑换人、兑换优惠券面额、兑换数量、优惠券使用状态、优惠券有效期字段数据；
• 点击“兑换配置”将设置积分兑换积分券的比例，优惠券面额管理将管理优惠券的面额，同时可以对面额进行调整和重置；
• 点击“优惠券有效期”将配置有效期，可以查看、修改、管理和变更优惠券有效期，根据用户的兑换情况，分析兑换比例和有效期设置的合理性，并进一步对其进行调整。

兑换现金配置：

• 兑换现金是和商品的价格属性相关联，兑换比例初始设置1:10，并根据商品的价值大小二次进行配置，商品价格在2000元以下，兑换比例为1:10，商品价格在2000元以上，兑换比例为1:15,；
• 可以选择商品价格范围，根据不同的价格范围进行兑换比例配置；
• 可以查看兑换明细，包含兑换商品、商品类目、商品价格、兑换比例，点击兑换比例可即时修改；

4）积分到期预警

积分到期预警模块是通过短信和站内信方式向积分即将到期的用户进行提醒，通过此模块，可以快速设置提醒短信内容模板，设置提醒预警时间和周期，同时可以选择提醒的用户（按照不同到期时间筛选）。

• 首先可以查看所有预警过的记录信息，包含预警时间、预警内容、预警周期、预警失效积分等详细数据；
• 点击“预警配置”，可以快速创建修改预警模板和预警内容，同时配置预警时间和预警周期，选择预警方式（短信提醒或站内信提醒）；
• 选择需要预警的用户，点击预警用户进入用户筛选列表，按照积分到期日期由近到远进行排序，方便对其进行选择。

积分到期预警的内容和周期，将直接影响到用户的平台感知和体验效果，合理的预警内容和周期，可以提升用户对平台的感知效果。

转载自-- https://www.cnblogs.com/jurendage/p/9176010.html

今天关于Java生鲜电商平台-促销系统的架构设计与源码解析和生鲜电商促销方案的讲解已经结束，谢谢您的阅读，如果想了解更多关于10、生鲜电商平台-财务系统模块的设计与架构、24、生鲜电商平台 - 系统报表设计与架构、26、生鲜电商平台-RBAC系统权限的设计与架构、38、生鲜电商平台-会员积分系统的设计与架构的相关知识，请在本站搜索。