The premise

Wechat circle of friends is a function we use every day, but if you come to realize a wechat circle of friends, how will you do it? Let me think about it briefly.

Realize the function

  1. Hair circle of friends
  2. Comment on the dynamic
  3. Check your moments (only your friends’)
  4. View comments (mutual friends only)

Doesn’t it look easy? It doesn’t have many functions.

Begin to implement

Database selected MySQL, familiar with the relational database

Version of a

See only two content, circle of friends dynamic, circle of friends comments, direct design database.

Simple. Well, with this data model, when implemented, problems will be found.

1. How to obtain friend circle data

If you simply pull a friend list, and then pull out the activity of your friends, sorry, your interface is going to explode, because that’s where the user base is.

2. How to get comments from mutual friends in the dynamic

Of course, comments can also capture all comments in the feed and filter out non-friend comments.

Think about,

How to solve this problem? The above slow data acquisition is mainly due to data screening, so if I can directly get the final data, can’t I solve this problem?

Version 2

In order to be able to directly access to the circle of friends data, on the existing basis is certainly not, according to the idea of obtaining data, directly access to the circle of friends data, of course, to add a circle of friends table.

Add a new circle of friends list:

This is very convenient, users can view moments, can directly locate the dynamic view and can view the comments, according to the dynamic ID and comment ID will be added to the content on the line.

However, it is necessary to maintain a table of users’ circle of friends. When users post, delete posts, add friends, delete friends, send comments and delete comments, data synchronization should be performed asynchronously. After all, if the interface is synchronized, the response will be slow. But I think it’s a price worth paying for the quick response of the pull data interface.

You think this is it? Naive. Look at the picture below:

Such news in the circle of friends have seen it. It should be visible to all users and can be interpreted as an official post. In our current design, we plug it into all users’ moments, so if an official post has a million users, we plug in a million pieces of the same data, and there are new users, and we plug in historical data. Not only is it hard to maintain, but there’s too much useless data.

Think about,

The best way to do this is to insert a single piece of data that all users can read. The most straightforward way to do this is to specify a user ID(such as 0) in the circle of friends table, which is common to all users

However, before our comments were saved directly to the moments, can be saved in this way, because each user in the moments table each dynamic is unique, but now if the public ID is inserted, can not be saved so, how to deal with the dynamic comments? Go back to the original dynamic query?

Since there is a user’s circle of friends dynamic table, it can have a circle of friends comment table, the circle of friends dynamic save is the user can view the dynamic, then the circle of friends comment table save is the user can view the comments.

Version 3

Modify user moments table structure as follows:

After this change, the data maintained is basically the same as version 2, and the issue of version 2 is also resolved.

So let’s see what happens now

Check your moments

  1. Dynamic lookup of viewable events from moments (including user ID and public ID)
  2. View related comments from moments comments (including user ID and public ID)
  3. Pull relevant data by ID from dynamic and comment tables

The first two steps take the index, and the third step takes the primary key directly, with no useless data

Data maintenance operations (all operations below are officially judged)

With the dynamic

  1. Find all friends of the user
  2. Add the feed to the feed list of all your friends (including the user himself)

Delete the dynamic

  1. Find all of a user’s friends
  2. Deletes the feed from a friend’s circle of friends feed list
  3. Delete the feed from your friend’s moments comment list

To send comments

  1. Find all friends A of the user
  2. Find A’s friend B who can view the feed
  3. If the comment is a reply to a user, filter the users who are not replying to the user’s friends from B and get C
  4. Add the data to C’s moments comment table

Delete comments

  1. Find all friends A of the user
  2. Find user B who can view this comment from user A in the moments comment
  3. Delete the comment data of B’s moments

Add buddy

  1. Find all your friends’ feeds and add them to the user’s moments feed
  2. Find the relevant comments (including the comments and the comments) of friends in the user’s moments of friends, filter out the comments that cannot be viewed by users, and synchronize the comments in the moments of friends

Remove buddy

  1. Find the relevant comments of friends in the user’s moments of friends and delete the user’s moments of friends comment data
  2. Find all of your friends’ feeds and delete them from the user’s moments feed

Above, basically is my current assumption

conclusion

It can be seen that in the final version, basically all the logic is in the asynchronous data synchronization, and there is little business logic, which can ensure the fast response of the interface pulling data, but because it is asynchronous operation, it will inevitably cause data delay. For example, when processing data is too large, the user sends a feed, but has not done asynchronous processing, and his friends can’t see the feed he just posted.

And other problems that may exist that have not yet been discovered. Here we go. I don’t have a better idea.

The above!!!!!!