Use the simplest language, describe the most complex scheme!

Have you ever encountered such a user scene, one day in taobao APP search: 50 degrees Flying Moutai, and then the next day when I read the news in toutiao APP, Moutai appeared from time to time. That’s the scene we’re going to talk about today.

It can be said that every APP or every TOC system has less or more operations TO collect data, user information and user behavior. To collect user information and usage, you need to use the buried service. For this buried service, many third-party service providers provide corresponding services. As long as the corresponding step interface is followed, the corresponding data can be collected. For example, umeng’s burial site service:

www.umeng.com/page/z/maid… Third party burial point service, some are free, some are charged. If you use a free service, you may not get a timely response from the service provider in case there is a problem with the service. If you use charged services, if the control is not good, you are afraid to provide a large amount of user data to a third party platform, in case the third party handles your data, or accidentally leaks it, you can talk to anyone. Based on the above two situations, set up a buried service.

0x01: Database design

The amount of data in the database of buried point service is exponentially proportional to the number of APP users. If necessary, you can use separate tables. The detailed table structure design is roughly as follows:

  • Id: id of the primary key

  • Enumerated types: iOS, Apple, Android, HTML5, miniApp, etc

  • User_id: indicates the id of the login user. No login is NULL

  • User_name: indicates the user name

  • Sex: indicates the user gender

  • Page: indicates the interface of the operation. Enumeration type must be defined according to the owning module. For example: enter the payment interface defined as payment_page_view; It is best to define a rule such as module name + page + action

  • Action: Operation, INSERT add, update update, delete delete, query

  • Action_time: operation time

  • Module: indicates the owning module

  • Create_date: creation time

Only some general fields are defined here. Other fields can be defined according to different projects and business scenarios. Increase by yourself to meet your own business needs. The goal of defining this table is to analyze user behavior based on the collected data; Or according to the statistics of the operation of the system data, such as user activity, activity and so on.

0x02: Interface design

Buried data is universal and generally needs only one interface. The interface must be designed for POST requests, because collecting data is best designed for bulk delivery. If a piece of data is collected, the interface is requested once, which is very unfriendly to the server and causes server stress. The TrackListDto of the interface’s request parameters can be roughly designed as:

  • Enumerated types: iOS, Apple, Android, HTML5, miniApp, etc

  • User_id: indicates the id of the login user. No login is NULL

  • User_name: indicates the user name

  • Sex: indicates the user gender

  • -Blair: Sign. Prevent buried services from being attacked by hackers

List: indicates the List of buried data

import java.util.List; public class TrackListDto { private String platform; private String user_id; private String user_name; private String sex; private String sign; private String ts; private List<TrackInfoDto> list; // omit the getter setter}Copy the code

TrackListDto can also define some other general properties that need to be defined for specific business scenarios.

TrackInfoDto is defined roughly as follows:

  • Page: indicates the interface of the operation. Enumeration type must be defined according to the owning module. For example: enter the payment interface defined as payment_page_view; It is best to define a rule such as module name + page + action

  • Action: Operation, INSERT add, update update, delete delete, query

  • Action_time: operation time

  • Module: indicates the owning module

import java.util.Date; public class TrackInfoDto { private String page; private String action; private Date action_time; private String module; // omit the getter setter}Copy the code

TrackInfoDto can also define attributes that are positively related to the user’s behavior. In this case, the data corresponds to the database one by one, but also needs to be defined according to the specific business scenario.

0x03: Main implementation logic

  • The client

At the client level, according to the user’s operation, collect data into a TrackListDto object, and the TrackInfoDto array of the object, it is best to reach a certain number, such as 10, 20, in the invocation of a buried point service interface. Another key step is that the front end and back end should agree on a signature generation algorithm for signature generation and signature verification.

  • The service side

The server has only one interface, which is to accept the data collected by the client and store it in the library. However, there are two issues to consider. The first is to verify the problem to prevent customer attacks. The second is that concurrent requests from a large number of users can cause database bottlenecks. If the user quantity is large, real-time storage, certainly to the database caused very big pressure.

Verification problem: The client and the server agree on the check algorithm. The check algorithm must be consistent with the check algorithm at the front and back ends. If you need a little more security, you need a burial service to monitor it.

Concurrent requests from a large number of users can cause a database bottleneck: this requires the introduction of message queuing MQ, where the data is first stored and then asynchronously stored.

Although simple in design, it is the solution to support a million project. No matter how awesome your plan is, a plan that can’t be realized is a bad plan!!