背景
多數的移動端APP都會有做任務領取獎勵的功能模塊,這類需求的目的是培養用戶使用習慣,提升用戶活躍性,用戶完成任務獲得積分獎勵,通過積分兌換商品或者充值話費,微信體現等。
擬定需求場景(如圖↓),概要:APP底部導航中新增小任務Tab,點擊Tab可查看任務完成進度和領取情況,點擊去完成跳轉到做任務的業務界面,當用戶完成任務並且滿足領取條件的時候,任務Tab需要紅點提醒用戶當前有獎勵可領取,用戶領取後並且當前沒有待領取獎勵小紅點消失,任務完成進度和領取狀態僅保持當天,隔天刷新。
業務分析
在開發前需要對需求進行整理,對細節進行確認,然後設計解決方案,預估開發時間,這裡將對於業務中核心的內容進行梳理:
用戶想要完成任務,需要去操作其他業務功能,如:評論成功後需要完成每日評論任務,關注主題後完成關注新手任務,這裡就涉及核心問題,任務需要依賴於其他業務為了保障後續拓展性,任務需要支持後臺管理,配置任務名,描述,任務類型(每日,新手,活動),完成次數,獎勵積分數量,去完成跳轉uri 等用戶完成任務後不用自動領取獎勵,需要進入到任務列表點擊領取操作,可領取時導航Tab需要小紅點提醒,和產品確認任務的完成和提醒的用戶體驗方案設計
核心目標:
任務依賴其他業務,需要進行解耦,不影響其他業務的功能和性能設計後臺可管理,便於後續拓展抽象任務模塊,代碼抽象開發完成任務和領取需要保證冪等性高可用名詞定義:
事件
任務中涉及依賴其他業務,這裡需要抽象出一個概念,用戶通過操作業務,完成任務的這個操作,我們把這個過程定義為用戶完成任務事件觸發完成,如:評論事件,點贊事件,關注事件,等解決方案:
在實現方案上,採用異步消耗隊列的方式,依賴業務接口埋入事件上報,將用戶成功操作業務的任務事件上報到隊裡中,然後開發消息消耗的腳本程序,對消息中用戶觸發的任務事件進行業務邏輯處理和DB操作,更新用戶任務進度和可領取狀態,響應給用戶(完成任務紅點提醒),設計圖:
表結構:
<code>-- 任務表
CREATE TABLE `task` (
`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '自增',
`icon` varchar(300) NOT NULL DEFAULT '' COMMENT '圖標',
`title` varchar(30) NOT NULL DEFAULT '' COMMENT '任務標題',
`type` tinyint(4) NOT NULL DEFAULT '0' COMMENT '任務類型,新手任務=1,每日任務=2',
`event` int(11) NOT NULL DEFAULT '0' COMMENT '事件',
`des` varchar(30) NOT NULL DEFAULT '' COMMENT '任務描述',
`target_num` int(11) NOT NULL DEFAULT '0' COMMENT '目標數量',
`points` int(11) NOT NULL DEFAULT '0' COMMENT '金幣',
`sort` int(11) NOT NULL DEFAULT '0' COMMENT '排序',
`status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '狀態 0=下線,1=上線,-1=刪除',
`app_version` varchar(15) NOT NULL DEFAULT '' COMMENT 'app版本號',
`app_version_compare` varchar(10) NOT NULL DEFAULT '' COMMENT 'app版本號比較運算符',
`operator` varchar(10) NOT NULL DEFAULT '' COMMENT '操作人',
`jump_uri` varchar(300) NOT NULL DEFAULT '' COMMENT '跳轉協議',
`create_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '創建時間',
`update_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '更新時間',
`event_begin` timestamp NOT NULL DEFAULT '1970-01-02 00:00:00' COMMENT '事件開始時間',
`event_end` timestamp NOT NULL DEFAULT '1970-01-02 00:00:00' COMMENT '事件結束時間',
`task_begin` timestamp NOT NULL DEFAULT '1970-01-02 00:00:00' COMMENT '任務開始時間',
`task_end` timestamp NOT NULL DEFAULT '1970-01-02 00:00:00' COMMENT '任務結束時間',
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
-- 用戶任務情況表
CREATE TABLE `user_task_case` (
`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '用戶任務情況',
`user_id` bigint(20) NOT NULL DEFAULT '0' COMMENT '用戶ID',
`task_id` int(11) NOT NULL DEFAULT '0' COMMENT '任務id',
`task_type` int(11) NOT NULL DEFAULT '0' COMMENT '任務類型',
`event` int(11) NOT NULL DEFAULT '0' COMMENT '事件',
`task_uni` varchar(30) NOT NULL DEFAULT '' COMMENT '任務唯一標識(唯一約束) ',
`target_num` int(11) NOT NULL DEFAULT '0' COMMENT '目標數量',
`finish_num` int(11) NOT NULL DEFAULT '0' COMMENT '完成數量',
`points` int(11) NOT NULL DEFAULT '0' COMMENT '可領取金幣數量',
`status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '狀態 0=待完成,1=待領取,2=已經領取',
`finish_at` timestamp NOT NULL DEFAULT '1970-01-02 00:00:00' COMMENT '完成任務時間',
`get_at` timestamp NOT NULL DEFAULT '1970-01-02 00:00:00' COMMENT '領取時間',
`create_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '創建時間',
PRIMARY KEY (`id`),
UNIQUE KEY `uni_user_id_task_uni` (`user_id`,`task_uni`) USING BTREE,
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用戶任務情況表';/<code>
更新語句:
<code>-- 更新領取狀態,注意:WHERE條件,強校驗
UPDATE user_task_case
SET `status`=2,finish_at=CURRENT_TIMESTAMP
WHERE id=:id AND user_id=:user_id AND `status`=1 AND finish_num>=target_num/<code>
表重點字段說明:
task_uni 任務唯一標識user_id和task_uni 組合唯一約束索引 每日任務: 任務id_任務類型_日期(task_id_type_date) 默認都是隻做一次(新手任務/活動任務): 任務id(task_id)冪等性 user_task_case 表中 user_id和task_uni 組合唯一約束索引,通過mysql的唯一約束,保證了多進程並行消耗事件隊列的情況下,每日任務和一次性任務不能重複INSERT 通過UPDATE的WHERE條件校驗保障領取的冪等性管理後臺:
產品在規劃需求的時候會設計出相關後臺,但是不一定設計的合理,所以這裡需要根據確認的解決方案協助產品對於管理後臺進行調整,保障後續的拓展性
代碼層面:
面向抽象開發,合理使用設計模式,便於後續的拓展
作者:SFLYQ
鏈接:https://juejin.im/post/5e8aa3306fb9a03c3912e99e