Architecture design and implementation of shooting project
Detailed Design and Implementation of User Module
Detailed design and implementation of login and registration
In order to facilitate the use of users, this system adopts a one-click login and registration scheme. When the user enters a mobile phone number that does not exist in the system, it is registration, and if the mobile phone number exists, it is login.
This system uses the mobile phone number to send the verification code to log in and register.
Specific implementation: After the user fills in the mobile phone number, the front end sends a request to the back end to obtain the mobile phone verification code, and the back end calls the Alibaba Cloud SMS service, sends the verification code to the user, stores the verification code in redis, and sets the expiration time as One minute. The purpose of setting the expiration time is to prevent the user from sending the verification code multiple times in a short period of time, resulting in waste of resources. If the expiration time is not reached, no new verification code will be sent. When the user enters the verification code, the front-end will send the verification code entered by the user to Back-end verification, after the verification is successful, it is judged whether the mobile phone number exists. If it exists, a token and login information are generated and stored in redis, and the login is completed. If not, it is registered, and the default information of the user is automatically generated and stored in the database.
Detailed design and implementation of logout
If the user needs to log out of the current account, he can click Note to log out on the settings page to complete the logout. When clicked, there will be a message prompt box to remind the user whether to log out of the current account. After confirmation, the front end sends a request to the server, the server deletes the user's login information from redis, and the front end exits to the login registration page.
Detailed design and implementation of modifying personal information
The functions for users to modify personal information include modifying personal information, modifying avatars, etc. Users can click Edit Profile in My Page to modify personal information and avatar.
Modify avatar: On the edit profile page, click on the avatar to modify, select a picture from the album, if you choose a new picture, after submitting, the server will upload the picture to oss (Alibaba Cloud Object Storage Service) after receiving the picture from the client , save to the corresponding resource path. The oss Api returns the storage path of the image, and the server obtains it and stores it in the image table of the database.
Modify other information: Just enter the corresponding information in the input box. After the front-end page verifies the information, it will provide it to the server after passing the verification. After the server receives the information, it will update the information to the database.
The detailed design and realization of the letter module in the station
The private message function in the station is mainly realized by using netty+websocket+rabbitmq. By establishing a long connection with the server, the user sends a message and uploads it to the message queue rabbitmq through the server, and then sends it to the server for consumption by rabbitmq. The consumer pushes the message to the client of the user corresponding to each message. Through the long connection between the client and the server, the server actively pushes messages to the client.
Messages are divided into two types: user private messages and notification messages. Private message messages are as shown in the above logic, and notification messages include follow notifications, reply notifications, and comment notifications. For example, when a user comments on your post, in addition to recording the content of the comment, the server also needs to call the notification message service of the in-site message module to actively push the message to the user who commented on the post.
The specific architecture design diagram is shown in the figure below:
When the message has not been viewed, the default status of the message is unviewed, and a red dot will be displayed on the message list to indicate unread. When you click to view, the message will be marked as read, and the red dot will disappear.
The user can select a message to delete, the client sends the id of the message to be deleted to the server, and the server performs soft deletion in the database.
When the user enters the message module, the system will query all the undeleted messages of the user by default. The client can receive data such as message content, message type, message status, and sending time, and classify, display and typesetting the messages through these attributes.
Detailed design and implementation of the circle of friends module
Detailed design and implementation of sending dynamics and articles
Dynamics and articles are stored in a table, and a type field is used to indicate the difference between the two. But the main difference between the two is that the dynamic reference is the dynamic release of qq space, which can write dynamic content and add pictures, while the published articles are edited with rich text, and the html text is finally stored in the database.
Users can find the entrance to click to publish news and write articles in the Moments module. When posting news, users can enter the news content and upload pictures (up to 9 pictures can be uploaded). To publish an article, you can enter the article title and article content. After the writing is completed, it is verified by the client and sent to the server, and the server saves the content in the article table.
Delete dynamics, detailed design and implementation of articles
The news and articles published by the user can be deleted by themselves, but the articles and news of other users cannot be deleted. When the client sends a request to delete a news or article, it will pass the id of the news to the server, and the server will judge whether it is The user's activity or article, if it is, it is successfully deleted.
Forward dynamics, design and implementation of articles
Users can forward the news sent by other users. When forwarding, they can enter what they want to say, and the forwarded article will also be recorded in the user's article and dynamic table, but the type is marked as forward. When the user clicks forward, the article will be saved Or a dynamic abstract (that is, the first 50 words),
the id (Pid) of the original article, and the forwarding user id and other information. The forwarded dynamics will also be displayed in the dynamic category list of the user's homepage.
Review design and implementation
Users can comment on other users' dynamics or articles, and the comments are bound together with the dynamics. After the user sends a comment, the client sends the comment content to the server, and the server stores the comment content, dynamic id, comment user id, comment time, etc. into the database. Comments support second-level comments, and second-level comments use pid to bind the id of the previous level of comments.
Delete comments: Users can delete comments sent by themselves, and article or dynamic authors can also delete comments under dynamics or articles. Specific implementation: the front end carries the parameter comment id to send a request to the back end to delete the comment, and before deleting, judge whether it is a comment sent by itself or whether it is a comment belonging to its own dynamics or articles.
Like Design and Implementation
Users can like articles and updates, because like operation is a relatively frequent operation, so redis is used to cache like operations and the number of likes, and redis uses a string key-value structure to store whether updates have been liked , the key is the dynamic\article id, and the value is whether it has been liked. After the like request is initiated, the client sends the dynamic\article id to the server, and the server first goes to redis to obtain the like status. If there is no cache in redis, then Query from the database, reverse the state, and cache the state in redis. If there is a cache in redis, change the state of redis. If the state is converted from no likes to likes, add one to the number of likes in redis. minus one. Use timed tasks every once in a while to save the number of likes in redis to the database, and update the dynamic status of likes in the database.
Design and implementation of query dynamics and article details
Click on the dynamics and articles to view the dynamics and article details. The details page includes the dynamics, the content of the article, the author's avatar, the author's name, the release time, the list of comments, the list of likes and the list of reposts.
Query comment list: Query the comments to which the dynamic belongs according to the dynamic and article id, and recursively query the second layer of comments, use paging query, query 10 comments each time, query the second page when sliding down, and sort according to the like time .
Query the list of likes: Query the users who like the likes from the likes table according to the dynamics and article id. In order to alleviate the pressure on the database, 10 users who like the likes are queried each time, sorted according to the time of the likes.
Forwarding list: According to the dynamic id, query the data of pid = the dynamic id in the dynamic table, that is, the list of forwarding the dynamic, and sort according to the forwarding time.
Focus on detailed design and implementation
The relationship between users is stored in the system user relationship table. The user id and follower id are stored in the table. The specific process of the following operation is: firstly, it is judged whether the user who needs to follow has already paid attention, if so, the user is prompted whether to unfollow, if the user confirms unfollowing, the connection between users is canceled, that is, the connection between users is soft deleted .
Check the user relationship list, the user relationship list includes: mutual relationship list, fan list, follow list. Cross-correlation list query is to query the users you follow in the user relationship table and users who follow you at the same time. Follower list query is to query the list of followers in the user relationship table. The following list is to query the list of users you follow.
Design and Implementation of Article Rewards
Users can use points to reward their favorite articles. Users can click on the reward on the article details page of other users, and can choose to reward points or enter the points themselves to reward. After the server receives the request, the operation is roughly divided into two steps. First, deduct the points of the tipping user, and then increase the points of the author of the tipped article. This step must satisfy atomicity, which needs to be guaranteed by using redis distributed locks.
The specific implementation of Redis distributed lock: First, acquire the lock before the reward operation starts, and use the Lua script of redis to lock with the setnx command. The function of the setnx command is: when the specified key does not exist, set the specified value for the key. If the key is successfully stored, it means that the lock is successful, and the code continues to execute. If the key cannot be set successfully, it means that the acquisition of the lock failed, and the cycle continues to acquire the lock. If the lock cannot be acquired within a period of time, the locking fails and the lock is no longer acquired. After the tipping logic is executed, the lock needs to be released, and the Lua script must also be used to ensure atomicity when releasing the lock.
Detailed design and implementation of the mall module
Detailed design and realization of goods and services
Commodity foreground service implementation: users can view product details at the system foreground. After clicking to enter the product details page, you can click Buy Now, select the purchase quantity and specifications, and click Confirm to purchase.
Commodity background service implementation: After the administrator successfully logs in to the mall system, he can choose to modify the commodity, category, and commodity specification. The administrator can add new products, delete products, query products, modify products, add categories, delete categories, modify categories, add specification parameters, delete specification parameters, and modify specification parameters for product specifications. Series modification is to add new series, modify series, delete series. The result is returned after the modification is successful. The following is a flowchart of commodity service.
Detailed design and implementation of order service
The specific process of the order starts after the user clicks to submit the order after purchasing the product specification and quantity. When the order is submitted, the system will create an order to store the quantity, price, specification and other information of the purchased product. Click Confirm Payment to deduct the corresponding points, complete the order, and the order status will change from unpaid to paid. If the product is shipped, the order status will change to Shipped, and after the user signs for it, the order status will change to Signed for. Users can view orders in various states on the order page, and can choose to delete completed orders. The order service flow chart is shown in the figure.
