会员体系-系统豆的获取与消费

　　因为业务需求，系统需要设计会员体系，其中一环是有关系统豆的获取与消费。

一、设计场景

　　1）系统豆的获得：用户可通过购买产品、签到、发表动态、评论、分享等途径获得系统豆，用户可查看系统豆获得明细及总数

　　2）系统豆的消费：系统豆可以用于消费（按一定比例折算成人民币），消费途径包括

　　　　过期，要求每年6月30日（去年12月31日前获得但未使用的系统豆）和12月31日（本年6月30日前获得但未使用的系统豆）定时清除上半年未使用的系统豆，提高用户在平台的消费积极度

　　　　购买产品，按先获得先消费的原则，保证用户对拥有系统豆的合理消费。

　　3）退还系统豆：说到购买就会涉及退货，对此产品要求退还在购买中消费的未过期的系统豆（够人性吧）。

二、设计思路及流程图

　　设计分为三部分，一部分是系统豆的获得，二是消费，三是退还。有人想将获得、退还一块考虑，不幸的告诉你两者区别很大，退还较获得实现复杂的多，也是这三部分最为麻烦的一个，下面逐一介绍。

　　1）对于系统豆获得的设计是非常简单的，我们只需两步，一是为用户建统计系统豆（beans_count）字段，二是建系统豆明细表（记录系统豆增减数量、增减途径、用户id、记录时间等信息），用户表与明细表一对多关联

　　2）对于系统豆的消费一个费解的问题是如何保证先获得先消费

　　　　方案一：刚开始想到的方案是在明细表中增加消费标记字段，按时间顺序消费已有系统豆，但这个方案的可操作性确是有限的，一是需要解决余数问题，二是消费数额大往往导致很大的计算量，这显然不是一个理想的方案。正是因为存在这些难以避免的缺陷，迫使自己思考再思考，终于有了较为理想的解决办法，所以好的方法都是不满意触发的。

　　　　方案二：由于对上述方案不甚满意，于是开启了思考模式，终于在某个时刻触发灵感，一个好的方案就这样产生了。我们的思路是这样的，我们不再单一考虑每条系统豆的获得记录，而是在某次消费的时候检查用户有多少系统豆即将过期，这样我们只需保证优先消费即将过期的系统豆即可。由于有了这样的切入点，所以我们现在的问题是要如何轻松获得用户即将过期的系统豆数。

　　　　到了这里我们有必要重新捋一下需求，怎么样的系统豆符合过期的条件？每年6月30日和12月31日定时清除上半年获得但未使用的系统豆，于是我们做这样的假设，假设系统在6月30日之前上线，那么到了7月1日，之前所有获得的系统都都将被视为即将过期的系统豆，接着我们就会想到，如果从7月1日起用另一个字段保存新获得的系统豆（new_beans），那么beans_count - new_beans就是我们需要的即将过期的系统豆数量。

　　　　那么到此我们的问题得到解决了么？并没有，这里我们只是获取到了6月30日之前要过期的系统豆数量，那么随着时间的推移，我们如何能保证6月31日获得去年12月31日前获得但未使用的系统豆数量（轮换变化）？于是我们想到了系统豆过期定时处理，结合过期处理这个问题将迎刃而解。我们只需在每年的6月30日和12月31日做如下两步处理即可：一、beans_count = beans_count - (beans_count - new_beans)，二、new_beans = 0，这样就可以永远保证beans_count - new_beans获得是准确的将过期的系统豆数量（这里需要说明，之前new_beans还需要在第一个过期系统豆清理时间点开始统计，现在完全不用了，new_beans和beans_count字段从一开始保持同增即可）。

　　　　通过上面分析，现在的表结构为用户表新增统计系统豆（beans_count）、新获得的系统豆（new_beans）两个字段，明细表保持不变，设计流程图如下：

　　　　系统豆过期流程图

　　　　

　　

　　注：其中beans_count为云豆总数，new_beans为新得云豆数，num为要过期云豆数。

　　系统豆支付流程图

　　

　　

　　注：其中beans_count为云豆总数，new_beans为新得云豆数，num为要过期云豆数，pay_beans为支付云豆数。

　　3）关于系统豆的返还我们需要考虑消费时间、当前时间和定时清理时间这三个时间点，这样可以将处理情况清晰的分为四种情况，并且需要建立一张中间表保存消费具体细节，具体设计如下

　　　　

　　

注：其中beans_count为云豆总数，new_beans为新得云豆数，pay_beans为支付云豆数，expire_beans为要过期云豆数，dval=pay_beans-expire_beans。crTime为创建时间，cuTime为当前时间，6.30和12.31为crTime当年的时间。

　　中间表结构

　　

序号	字段名	字段中文含义	字段类型	是否为主键	是否可以为空	是否唯一	备注
1	id	唯一标识	Bigint(20)	YES	NO	YES
2	user_id	用户id	Bigint(20)	NO	NO	NO
3	create_time	创建时间	datetime	NO	NO	NO
4	beans_num	所需系统豆数	Int(11)	NO	NO	NO
5	empire_beans	使用要过期系统豆数	Int(11)	NO	NO	NO
6	order_id	订单id	varchar(50)	NO	NO	NO

　　到此，一个比较完整的系统豆获取、消费系统设计完成。

 　　附上一段判断是否过期的代码

public class Test {

    public static void main(String[] args) {
        System.out.println(new Test().isEmpire(new Date()));
    }

    private boolean isEmpire(Date date) {
        Date createTime = date;
        Calendar calendar = Calendar.getInstance();
        calendar.setTime(createTime);
        String index1 = calendar.get(Calendar.YEAR) + "-06-30 00:00:00";
        Date index_6 = getDateFromString(index1);

        Date currentDate = new Date();
        calendar.setTime(currentDate);
        String index2 = calendar.get(Calendar.YEAR) + "-12-31 00:00:00";
        Date index_12 = getDateFromString(index2);
        return ((createTime.compareTo(index_6) < 0 && currentDate.compareTo(index_6) < 0) || (createTime.compareTo(index_6) > 0 && currentDate.compareTo(index_12) < 0)) ? false : true;
    }

    public static Date getDateFromString(String datastr) {
        Date date = new Date();
        SimpleDateFormat dateFormat = new SimpleDateFormat(
                "yyyy-MM-dd HH:mm:ss");
        SimpleDateFormat dateFormat2 = new SimpleDateFormat("yyyy-MM-dd");

        try {
            if (datastr.length() == 10) {

                date = dateFormat2.parse(datastr);
            } else if (datastr.length() == 19) {
                date = dateFormat.parse(datastr);
            }
        } catch (ParseException e) {
            e.printStackTrace();
        }
        return date;
    }
}