积分作为一种营销手法，被广泛运用于线上/线下的产品中，以此来添加用户关于产品的粘性。比方天猫积分能够用来兑换产品，京豆能够鄙人单折扣等，如下图所示。
现在，随着获客本钱的添加，怎么削减用户的流失，变成了各个产品的中心出题之一。也正因如此，许多事务引入了各式各样的积分体系。为了更好的面对事务带来的变化，对整个积分兑换流程做一个合理的笼统是正确且有必要的。只是，整个积分的兑换是一个十分巨大且复杂的流程，因而，本着一切从简的理念，咱们这期先聊一聊怎么规划一个积分收取体系。
从详细到笼统
无论是天猫积分/京豆，都会有一个规矩说明，笼统的来说，无外乎两个主要的功用点：怎么获取积分以及怎么消费积分。
获取京东的方法一般有：
- 每天报到一次，领5个京豆
- 买100元以上的东西，领20个京豆
- 发1条20字以上的评论，领10个京豆
- ……
从上面的规矩中，咱们能够看出，根本符合一个格局：xx行为，执行yy次，能够得到zz个ww。
于是咱们能够将上述事例笼统成以下三步：
- 行为感知
- 使命推动
- 权益收取
架构规划
本着高内聚与低耦合的理念，咱们能够笼统成几个中心模块
行为感知模块
该模块担任对用户的行为进行感知，假如用户的登录行为、点赞行为、下单行为等。一般情况，该模块是异步进行的。
原因也很简略，行为感知作为依附于主链路存在的功用，其存在不该该影响到主链路的运行。
例如“用户每日登录获取一个积分”这样的事例，咱们不该该在登录接口同步进行行为感知。一般采纳的做法是，开一个子线程调用一下行为感知接口即可。
可是，行为的品种千奇百怪，怎么对行为进行一个合理的笼统就是咱们要考虑的问题了。一个简易的流程图如下所示：
在上述流程里，行为感知模块能够感知多种数据源（音讯），解析不同事务的音讯数据后，为了转换成体系内部需求的行为目标，一般还需求有一步数据填充的进程，这一步需求咱们和其他的服务进行联动的，在数据填充完结后，外部的行为才真实变成咱们整个积分收取体系内部所需求行为目标，这一步能够能够再宣布一个行为变更音讯出去，以便和其他事务解耦（当然也能够提供一个接口）。
使命推动模块
咱们将怎么收取积分归到该模块中。
所谓使命推动，就是咱们上述事例中说到的例如：下单20元的物品、点赞10条内容、登录1次这样的行为。在该模块中，咱们需求保护一张用户行为记载表和一个使命规矩表。
行为记载表担任保护用户每天的使命进展状况，例如点赞了多少条内容等信息。
使命规矩表担任录入玩法规矩，比方点赞10条内容可得一个积分这样的信息。该部分一般会由一个运营后台来承接。
一个简易的流程图如下
在上述流程中，使命的匹配与使命进展的更新是比较中心的部分。怎么做好技术选型是比较重要的一点，咱们将会鄙人一章详细介绍。
权益收取模块
出于高内聚低耦合的思想，咱们能够将权益体系的责任设置的简略一些，只需求担任添加积分、削减积分，查询积分明细这几个工作。至于从什么途径加积分、加多少积分，则将责任上移到使命推动模块中进行。
举个比方解释一下。比方，用户经过下订单赚取积分。订单体系经过异步发送音讯或许同步调用接口的方法，奉告行为感知模块订单交易成功，补全必要的信息后，发送给使命推动模块；使命推动模块根据拿到的订单信息，查询订单对应的积分兑换规矩（兑换份额、有效期等），核算得到订单可兑换的积分数量，然后调用权益收取模块的接口给用户添加积分。
这一部分的流程比较简略，就不画图了。可是怎么确保积分加的正确，怎么确保不重复加或许不漏加则是该模块的难点。
小结一下
简略对上述三个模块进行一个小结。有了上述一致后，咱们能够笼统出如下的功用图。
详细规划（数据表规划）
数据库和接口的规划十分重要，一旦规划好并投入运用之后，这两部分都不能容易改动。
改动数据库表结构，需求触及数据的搬迁和适配。改动接口，需求推动接口的运用者作相应的代码修正。这两种情况，即就是微小的改动，执行起来都会十分费事。因而，咱们在规划接口和数据库的时候，一定要多花点心思和时间，切不可过于随意。
相反，事务逻辑代码偏重内部完结，不触及被外部依赖的接口，也不包含耐久化的数据，所以对改动的容忍性更大。
在对上述流程进行了一个笼统之后，咱们发现有两个十分重要的表：使命规矩表和使命进展明细表。
数据字典规划
使命规矩表
这张表的规划比较简略，只需求指明相应的活动规矩即可，表结构如下。
| 字段 | 说明 |
|---|---|
| id | 活动ID |
| name | 使命称号 |
| description | 使命描绘 |
| type | 使命类型 |
| userAction | 用户行为 |
| num | 使命次数 |
| rewardCount | 使命完结后的奖赏数值 |
| rewardType | 使命完结后的奖赏类型 |
| period | 单次使命的周期，本次需求仅支撑天等级（DAY）的周期 |
| threshold | 每个使命周期内能完结的次数上限 |
场景举例
点赞三个内容获取一个积分，每天最多可获取20个，那么在数据表中则应该是如下的一条记载
type为like，num为3，rewardCount为1，rewardType为balloon，threshold为20
使命进展明细表
| 字段 | 类型 | 说明 | 示例 |
|---|---|---|---|
| id | Long | 主键ID | |
| userId | Long | 用户ID | |
| taskId | Long | 使命ID | |
| progress | Integer | 完结进展 | |
| extra | Map | 扩展信息 | |
| status | Integer | 使命推动状况 | 0：初始状况1：进行中2：已完结 |
| actionType | String | 用户行为 | |
| gmt_create | |||
| gmt_modified |
存储方案
只需做好一定的笼统之后，数据字典的规划其实是比较容易的，难点在于怎么对数据存储进行合理的选型。
在之前的文章中有说到过，架构的规划本质上是一种取舍的艺术。上文说到规矩的装备一般是放在运营后台承载的，这一块的运用场景规划较小，不需求扛前台流量，因而直接选用mysql，单库单表即可。
而使命进展明细表，记载的是每一个用户的行为明细，假如关于数据的准确性较高，mysql分库分表一般是一个不错的选择。当然假如整个事务需求答应少数的数据丢掉，也考虑运用HBase这样的大数据存储引擎，能够降低一些开发本钱。
总结
以上就是对整个积分收取体系的一个简略规划，咱们先从实际的事例动身，对场景进行一个技术层面的笼统，并概括为成“行为感知->使命推动->权益收取”三个模块。在清晰了每个模块的责任后，咱们给出了对应的流程图，并在最后汇总成了一个完整的功用架构图。聚集详细完结时，咱们定义了两个最中心的数据表：使命规矩表与使命明细推动表，并评论了存储。总的来说整个积分收取的生命周期已经完整。
可是，这儿请注意⚠️。无论是天猫积分或许京东京豆，收取规矩只是其间一个比较重要的部分，一个完整的积分体系不但触及到积分的收取，积分的消费也是十分重要的一环，以及消费往后的对账体系又该怎么规划，这些都是值得咱们探讨的问题。
