Introduction to the

The implementation of AD targeting, described earlier, is a Query-intensive program, so each request sent to it causes a lot of computation. This article will implement a simple social networking site, which will minimize the amount of work the system needs to do when users view the page. P184

Users and StatusP185

The user object stores the basic identity information of the user, the number of followers of the user, the number of status messages that the user has published, and so on. It is the starting point for building other usable and interesting data. P185

Status messages record what different users are saying and communicating with each other. These user-created status messages are the real content of social networks. P185

The user informationP185

User information is stored using HASH. User information includes the user name, number of followers the user has, number of people the user is following, number of status messages the user has posted, date of registration of the user, and other meta-information. Example: “user:139960061”: {“login”: “dr_josiah”, “ID “: “139960061”, “name”: “Josiah Carlson”, “followers”: “176”, “following”: “79”, “posts”: “386”, “signup”: “1272948506”} P185

Example Create user P185

When creating a user, you need to create an object with the number of followers, number of followers, and number of published status messages set to 0 based on the user name specified by the user and the timestamp at that time. P185

In addition to initializing the user information, the user name needs to be locked to prevent multiple requests from creating a new user with the same user name at the same time (use 08. Realize automatic completion, distributed lock and count semaphore realization of distributed lock lock operation).

Status messageP186

A status message is stored using a HASH. The status message contains the message itself, the time when the message was published, the id of the message publisher, the user name (redundant user names are used to avoid the HASH of the user information for presentation, since the user name does not change), and some additional information about the status message. Example: “status: 223499221154799616″ : {” message “:” My pleasure. I was amazed that…” , “posted”: “1342908431”, “id”: “223499221154799616”, “uid”: “139960061”, “login”: “dr_josiah”} P186

When creating a message, you need to obtain the user name and then combine the related information and store it in the HASH. P187

Homepage TimelineP187

The home page timeline is a list of status messages posted by users and the people they are following. A personal timeline is similar to a home timeline in that it contains only status messages posted by users themselves. Because the home page timeline is the primary entry point for users to the site, this data must be as accessible as possible. P187

The home page timeline is stored using an ordered collection whose members are the IDS of the status messages and whose points are the timestamps of the status messages published. Example: “home:139960061”: {… , “227138379358277633”, “1342988984”,… } P188

There are two steps to get the timeline of the home page: P188

  1. useZREVRANGEPaging for a list of ids for the latest status messages
  2. Use pipelining andHGETALLGet all status messages in the status message ID list

List of followers and list of followersP189

The list of users being followed and the list of followers are also stored as ordered collections, with members being the id of the user and the score of the members being the timestamp when the user started following or being followed by someone. Example: “Followers :139960061”: {… , “558960079”: “1342915440”, “14502701”: “1342917840”,… } “following:139960061”: {… , “18697326”: “1339286400”, “558960079”: “1342742400”} P188

When a user starts to follow or stops following another user, it is necessary to update the ordered set of following and ordered set of followers (ZADD, ZREM) of these two users, and modify the number of following and the number of following (HINCRBY) in their user information. At the same time, it also needs the timeline of the operator’s home page. Add or remove another user’s status message (ZUNIONSTORE). P189

The delete operation requires two commands, and since ordered sets do not have commands to evaluate the difference set, there are two ways to do this:

  1. useZREVRANGEGets the list of members of an ordered collection corresponding to another user’s home page, and then uses itZREMRemove these members from the ordered collection corresponding to the operator’s home pipeline
  2. Use the firstZUNIONSTOREThe weight of the ordered collection corresponding to the main line of the operation user is 1, and the weight of the ordered collection corresponding to the personal line of another user is 0, which is used in aggregation modeMINAnd then use it againZREMRANGEBYSCORE key 0 0Remove all members with a score of 0 (pipeline merge can be used)

thinking

Exercises allow batch following and unfollowing operations to be supported on a given basis. In fact, in most cases, single and batch operations are similar, and batch operations are likely to be supported in the future. In order to reduce the amount of back-end development, avoid changing interface signatures or explosive growth of interfaces with similar functions, I often implement the interface for batch operations in advance. Instead of just dealing with current requirements, we need to understand the overall functionality and think from the user’s point of view, focusing on possible changes as early as possible, so that we can develop extensible interfaces.

Publish and delete status messagesP191

One of the most basic actions a user can perform is to publish a status message. The logic for creating a status message was implemented earlier, and the next step is to add a new status message to each follower’s home page timeline. P191

In order to make the publish action return as quickly as possible, we will only add new status messages for the homepage timeline of the first 1000 followers after creation. If the current publisher has more than 1000 followers, use 09. Implementation of task queue, message pull and file distribution implementation of task queue asynchronous processing of subsequent concerns. P192

Delete the status message itself, process the publisher’s own statistics, delete the message ID from the personal timeline, and finally delete the homepage timeline of the first 1000 followers. If the number of followers exceeds 1000, use the task queue to asynchronously process the following followers. P193

Streaming APIP194

Functions are built to broadcast simple events, which are then received and processed by event listeners responsible for data analysis. Stream API requests can continuously return data over a relatively long period of time. P194

The purpose of the streaming API is to generate a sequence of times over time to keep clients and other services across the network up to date on what is happening on the site. P195

There are a variety of decisions to be made during the process of building a flow API, which are primarily related to the following three questions: P195

  • What events does the stream API need to expose?
    • You need to expose the four user actions that are currently implemented: publish a message, delete a message, follow a user, and unfollow a user. This section uses the creation of publish message events and deletion message events as examples
  • Do you need to restrict access? If necessary, how to implement it?
    • Currently, access restrictions are only considered when user privacy or system resources are involved
  • What filtering options should the stream API provide?
    • You can get filtered messages by paying attention to filters (filtering by user), detection filters (filtering by keyword), and location filters, Random messages can be retrieved via streams like Twitter’s Firehose (which gets all public messages) and SAMPLE (which only gets a few public messages).
Identify the clientP198

In order to distinguish different clients, it is necessary to identify them. In most cases, only users who have logged in can be considered, so we use user ID for identification. In order to realize the function of verifying user ID at the same time, we can use JWT.

Filter messagesP200

We will use the PUBLISH and SUBSCRIBE commands of Redis to implement the SUBSCRIBE and PUBLISH functionality: When a user publishes a message, the program publishes it to a channel, and each filter subscribes to receive a message from that channel, yielding back the message when it finds a match for the filter (in the case of a published message, the entity returns the message; In the case of delete messages, the ID and current status are passed back to the Web server, which then sends the messages to the client. P200

This article is published on GitHub: Reading-notes/Redis-in-Action