background

Most mobile apps have functional modules for receiving rewards by doing tasks. The purpose of such requirements is to cultivate user habits and improve user activity. Users can get rewards by completing tasks, exchanging goods or topping up phone charges through points, and displaying on wechat.

Draft demand scenario (as shown in figure ↓), summary: New task in the APP at the bottom of the navigation Tab, click the Tab to view the task completed on schedule and to receive and click to jump to do task business interface, when the user to complete the task and receiving conditions, task Tab to red dot to remind users currently have will get reward, and currently not to get reward after users receive little red dot disappear, The task completion progress and collection status are kept on the same day and updated every other day.

Business analysis

Before development, it is necessary to sort out the requirements and confirm the details, then design the solution and estimate the development time. Here, the core content of the business will be sorted out:

  1. To complete the task, users need to operate other business functions. For example, they need to complete the daily comment task after the success of the comment, and complete the novice task after the focus on the topic. This involves the core problem and the task needs to rely on other services

  2. In order to ensure the follow-up expansion, tasks need to support background management, configure task name, description, task type (daily, novice, activity), completion times, number of bonus points, to complete jump URI, etc

  3. After completing the task, the user does not need to automatically receive the reward, but needs to enter the task list and click the claim operation. When the task can be claimed, the navigation Tab needs a small red dot to remind, and the user experience of confirming the completion of the task and reminding can accept a short time delay

  4. Users repeatedly operate services or repeat operations (malicious concurrent requests to brush points) to ensure that the task can only be completed once and the reward can only be received once, which requires idempotency

The project design

Core objectives:
  1. Tasks depend on other services and need to be decoupled without affecting the functions and performance of other services
  2. Design background can be managed, easy to expand
  3. Abstract task module, code abstract development
  4. Task completion and collection are idempotent
  5. High availability
Definitions of nouns:

The event

  • A concept needs to be abstracted here. The user completes the task by operating the business. We define this process as the completion triggered by the user completing the task, such as: comment event, like event, concern event, etc
Solution:

On the implementation scheme, adopt the way of asynchronous consumption queue, rely on the business interface into incident report, the user the task of successful operation business events reported to the team, then the consumption of developing message script, the user task events in the news business logic processing and DB operation, update user task schedule and status can be gotten, Response to the user (red dot reminder for completing the task), design drawing:

  • Dependency business decoupling
    • Dependent services report task events of successful users to a message queue, and then the program consumes them asynchronously
    • The solution solves the strong coupling between dependent services and basically does not affect the interface performance of existing dependent services
  • High availability:
    • The scheduling system starts multiple processes to consume queues
      • Process daemon system, daemon process to survive, crash restart, you can record and view the execution log
      • Such as: gocron
    • Message queue monitoring, can not be consumed in time for early warning, guarantee immediacy, avoid long delay
      • rabbitmq
      • redis list
      • . .
    • Fault tolerance and compensation
      • Queue consumption failures need to be recorded, and can be supplemented by other programs based on business scenarios
      • There is no limit on the number of times a user can report a task event to prevent the user from completing the task and allow the user to retry the task. The program consumption requires that the task can be completed only once

Table structure:

- the task table
CREATE TABLE `task` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT 'on the'.`icon` varchar(300) NOT NULL DEFAULT ' ' COMMENT 'icon'.`title` varchar(30) NOT NULL DEFAULT ' ' COMMENT 'Task Title'.`type` tinyint(4) NOT NULL DEFAULT '0' COMMENT 'Task type, novice task =1, Daily task =2'.`event` int(11) NOT NULL DEFAULT '0' COMMENT 'events'.`des` varchar(30) NOT NULL DEFAULT ' ' COMMENT 'Task Description'.`target_num` int(11) NOT NULL DEFAULT '0' COMMENT 'Target quantity'.`points` int(11) NOT NULL DEFAULT '0' COMMENT 'gold'.`sort` int(11) NOT NULL DEFAULT '0' COMMENT 'order'.`status` tinyint(4) NOT NULL DEFAULT '0' COMMENT 'Status 0= Offline, 1= online, -1= Deleted'.`app_version` varchar(15) NOT NULL DEFAULT ' ' COMMENT 'App Version number'.`app_version_compare` varchar(10) NOT NULL DEFAULT ' ' COMMENT 'APP Version comparison operator'.`operator` varchar(10) NOT NULL DEFAULT ' ' COMMENT 'Operator'.`jump_uri` varchar(300) NOT NULL DEFAULT ' ' COMMENT 'Jump protocol'.`create_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 'Creation time'.`update_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 'Update Time'.`event_begin` timestamp NOT NULL DEFAULT '1970-01-02 00:00:00' COMMENT 'Event Start time'.`event_end` timestamp NOT NULL DEFAULT '1970-01-02 00:00:00' COMMENT 'Event End time'.`task_begin` timestamp NOT NULL DEFAULT '1970-01-02 00:00:00' COMMENT 'Task start time'.`task_end` timestamp NOT NULL DEFAULT '1970-01-02 00:00:00' COMMENT 'Task end time',
  PRIMARY KEY (`id`))ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- User task table
CREATE TABLE `user_task_case` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT 'User task status'.`user_id` bigint(20) NOT NULL DEFAULT '0' COMMENT 'user ID'.`task_id` int(11) NOT NULL DEFAULT '0' COMMENT 'task id'.`task_type` int(11) NOT NULL DEFAULT '0' COMMENT 'Task Type'.`event` int(11) NOT NULL DEFAULT '0' COMMENT 'events'.`task_uni` varchar(30) NOT NULL DEFAULT ' ' COMMENT 'Task Unique Identifier (unique constraint)'.`target_num` int(11) NOT NULL DEFAULT '0' COMMENT 'Target quantity'.`finish_num` int(11) NOT NULL DEFAULT '0' COMMENT 'Completed quantity'.`points` int(11) NOT NULL DEFAULT '0' COMMENT 'Amount of gold available'.`status` tinyint(4) NOT NULL DEFAULT '0' COMMENT 'Status 0= pending, 1= pending, 2= already received'.`finish_at` timestamp NOT NULL DEFAULT '1970-01-02 00:00:00' COMMENT 'Task Completion time'.`get_at` timestamp NOT NULL DEFAULT '1970-01-02 00:00:00' COMMENT 'Time of collection'.`create_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 'Creation time',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uni_user_id_task_uni` (`user_id`.`task_uni`) USING BTREE,
) ENGINE=InnoDB  DEFAULT CHARSET=utf8mb4 COMMENT='User Task Sheet';

Copy the code

Update statement:

-- Update the claim status, note: WHERE condition, strong check
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

Copy the code

Table key field description:

  • task_uni

    • Unique task identification

  • User_id and task_uni combine the unique constraint index

    • Daily tasks:
      • Task ID_ Task Type _ Date (task_ID_type_date)
    • The default is to do it only once (novice task/active task) :
      • Task ID (task_id)

  • idempotence

    • In the user_task_case table, user_id and task_uni combine unique constraint indexes. The unique constraint of mysql ensures that daily tasks and one-off tasks cannot repeat INSERT when multiple processes consume event queues in parallel
    • The idempotency of the fetch is guaranteed by the UPDATE’s WHERE condition validation

Management background:

The product will design the relevant background when planning the demand, but the design may not be reasonable, so we need to assist the product to adjust the management background according to the confirmed solution, to ensure the follow-up expansion

Code level:

  • Abstract oriented development, rational use of design patterns, easy to follow the expansion
Words outside the article:

I have participated in the development of a new APP project in the past year. I started to build the project from zero, and I felt a sense of accomplishment when I saw the DAU rising gradually.

My role has changed, and I now feel more like a participant in a project rather than a task executor. I have a deep understanding of the product while completing business development.

In my spare time, I will also follow up the research on competitive products and users’ opinions or problems, and provide some suggestions on products from the perspective of users.

Later, problems encountered in the development process of new projects or solutions to common business scenarios will be sorted out and shared in blog posts.

First published on Github: 🌱 “Big Talk WEB development”, WEB development related experience summary share, welcome everyone Star wave, follow-up want to see not lost 🌈

Release time: 2020-04-06