商业充斥着不同的商品交易，而交易带来的不同业务。
1.业务背景
在市场上移动端APP都会有做任务领取奖励的功能模块，需求的目的是
培养用户使用习惯，提升用户活跃性，用户完成任务获得奖励，
通过奖励兑换产品商品，比如饭圈APP中粉丝会打投(意会)，那么这部分积分可以兑换成为爱豆票数，让爱豆排名靠前。
假定需求场景，概要：app底部有任务tab 点击tab进行任务完成进度和领取情况，点击去完成跳转到指定任务的业务界面，当完成任务并且满足领取条件时候，任务tab需要红点提示用户当前有奖励可领取，用户领取后红点消失，任务完成进度和领取状态，当日任务隔天更新，新手任务永久保留.....
示图1(win画图板画的)
2.任务业务的分析
这里对业务中核心的内容进行分析：
- 用户想要完成任务，需要其他业务功能，如评论后需要完成每日评论任务，任务依赖于其他业务的触发。
- 保证任务可扩展， 任务需要配置后台管理，任务配置，描述，任务类型(新手，每日，活动)，完成次数，奖励的数值，奖励的类型，按钮的跳转协议，跳转具体数值等。
- 用户完成任务后需要到任务列表领取奖励，可领取时导航Tab需要小红点提醒。
- 用户多次操作业务，或者出现重复操作（恶意并发请求刷取奖励），保证任务只能完成一次并且只能领取一次奖励，保证系统的幂等性是整个开发的关键。
3.业务方案规划
1）主要方向：
- 任务依赖其他业务，尽量解耦，最好不影响其他业务的功能和性能
- 后台可管理，便于后续拓展
- 完成任务和领取需要保证幂等性，高可用性
2）解决方案：
使用消耗队列异步，依赖业务接口上报，将用户成功操作业务的任务上报到队列中，然后开发消息消耗的业务程序，对消息中用户触发的任务进行业务逻辑处理和DB操作，插入用户任务记录，当满足领取条件响应给用户(完成任务红点提醒)
图示2（无聊时候画了b方案，没有mq的情况）
4.数据库表设计
任务配置表
| 字段 | 数据类型 | 说明 |
|---|---|---|
| id | bigint(20) | 自增id |
| icon | varchar(256) | 图标 |
| title | varchar(12) | 任务标题 |
| type | tinyint(2) | 任务类型(1当日，2新手，3活动) |
| des | varchar(32) | 任务描述 |
| num | int(3) | 任务数量(需要完成的数量) |
| app_version | int(6) | app开启版本(app版本号设计int方便比较) |
| sort | int(11) | 排序号 |
| start_time | datetime | 任务开始时间 |
| end_time | datetime | 任务结束时间 |
| jump_type | int(8) | 跳转类型（0不跳转,1榜单，2话题，3内容，4web页面） |
| jump_value | varchar(256) | 跳转的详细数值(默认nvl) |
| prize_type | int(8) | 奖励类型(1积分，2金币) |
| prize_value | int(11) | 奖励数值 |
| status | tinyint(2) | 状态(0下线，1上线) |
| create_time | datetime | 创建时间 |
| create_admin_id | bigint(20) | 创建的管理员id |
| deleted | tinyint(2) | 删除(0未删除，1删除) |
任务记录表
| 字段 | 数据类型 | 说明 |
|---|---|---|
| id | bigint(20) | id |
| task_id | bigint(20) | 任务的id |
| create_time | datetime | 创建时间 |
| user_id | bigint(20) | 用户id |
用户奖励领取表
| 字段 | 数据类型 | 说明 |
|---|---|---|
| id | bigint(20) | id |
| task_id | bigint(20) | 任务id |
| create_time | datetime | 创建时间 |
| user_id | bigint(20) | 用户id |
5.后台设计
后台设计比较简单，简单C-R-U-D 任务配置即可
