百科生活 投稿
关于【改版后的天猫积分如何获取】，改版后的天猫积分如何获取的，今天小编给您分享一下，如果对您有所帮助别忘了关注本站哦。
- 内容导航：
- 1、改版后的天猫积分如何获取
- 2、如何设计一个积分领取系统
1、改版后的天猫积分如何获取
大家在平时都会用天猫进行购物，今天为大家讲解一下改版后的天猫积分如何获取。
操作方法
打开手机，找到手机天猫，点击并进入。
进入之后，点击右下角的“我”，进入该页面。
进入之后，找到“会员积分”，点击并进入。
进入之后，可以看到购买的物品在收货后，就会得到相应的天猫积分，所以购物是获取天猫积分的一种方法。
返回上一界面，可以看到“玩游戏赢积分”，通过这种方式也可获得天猫积分。
特别提示
以上纯属个人编写，请勿转载抄袭。
2、如何设计一个积分领取系统
从具体到抽象
无论是天猫积分/京豆，都会有一个规则说明，笼统的来说，无外乎两个主要的功能点：如何获取积分以及如何消费积分。
获取京东的方式通常有：
- 每天签到一次，领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这样的大数据存储引擎，可以降低一些开发成本。
本文关键词：改版后的天猫积分如何获取的，天猫积分怎样获得，现在的天猫积分怎么兑换，天猫积分怎么获得，天猫积分兑换后怎么使用。这就是关于《改版后的天猫积分如何获取，改版后的天猫积分如何获取的（如何设计一个积分领取系统）》的所有内容，希望对您能有所帮助！
- 最近发表