Message System Design and Implementation, message system design and implementation

Message System Design and Implementation, message system design and implementation
Text/JC_Huang (simplified author)
Link: http://www.jianshu.com/p/f4d7827821f1
Copyright belongs to the author. For reprinted content, contact the author for authorization and mark "author of simplified book ".

Product Analysis

First, let's take a look at the implementation of messages on the market.

Jian Shu

There are two types of Short-book message systems:

• Simplified message
• Reminder

Simplified message
The nature of a simplified message is the same as that of a private message. It is a message sent to a user and contains specific information.

Simplified book

Reminder
The reminder is a message sent by the system. Its text format is fixed and it generally has hyperlinks for special objects.

Jian Shu reminds zhihu

Like a simplified book, zhihu has two main types:

• Private Message
• Message

Private Message
Like a simplified book, a message sent by the user can also be a message sent by the Administrator.

Zhihu private message

Message
Zhihu's message is better than the reminder of simplified books. zhihu will gather several similar messages to relieve the reading pressure on users.

Three types of zhihu message

Through a simple analysis of the two products, we can find that their messages are classified into two types. On this basis, we can add an announcement.
The main feature of an announcement is that the system sends a message containing specific content, which can be read by all users on the site.
Therefore, there are three types of messages:

Reminder language analysis

We will take a group of reminder samples from the simplified book:

• 3dbe1bd90774 follows you
• Magicdawn liked your article "three single sign-on implementation methods"
• The unscrupulous program liked your article "how to design user permission Control Based on RESTful APIs?"
• Alexcc4 liked your article "Implementing Unit Testing in Nodejs"
• How do you design user permission Control Based on RESTful APIs? Received a comment from cnlinjie.
• Your article Session principle has been added to the topic ios development.

When analyzing the sentence structure, the content of the reminder is nothing more

「 Who has done what to do with things of the same kind 」
「 Someone do something in someone's something 」

Someone = the trigger or sender of the reminder, marked as sender
Do something = the action of the reminder. Comments, likes, and followers are all actions marked as actions.
Something = indicates the action object of the reminder. Which article is specific and marked as target?
Someone's = owner of the action Action object to be reminded, marked as targetOwner

This makes it clear that sender and targetOwner are the users of the website, and target is the specific article. If there are other reminders, add a targetType to mark whether the target is an article or something else. Action is fixed. The whole website may trigger only a few reminders: Comments, likes, and followers ...... (or actions that require reminders for other businesses)

Two methods for obtaining messages

• Push
• Pull

Take zhihu as an Example
It is quite common to push. You need to maintain a list of consumers for a certain question. Whenever a condition for pushing this question is triggered (for example, someone answers a question ), send the notification to each consumer.

A relatively troublesome pull is the reverse push. For example, each user has a list of issues of interest. Every time a user goes online, he or she polls every issue, when the problematic event List displays information that is larger than my original timestamp, It is pulled.

However, we use different methods to retrieve messages based on different types of messages.:
Notifications and reminders are suitable for pulling messages. After a message is generated, there will be a message table. at a specific time, you can pull messages according to the table that you are concerned about, then add it to your message queue,

Information, which is suitable for pushing. After the sender establishes a message, it also specifies the receiver and adds the message to the receiver's message queue.

Subscription

Maintain a list of items that follow the pull method as prompted.
This behavior is called:Subscribe

One subscription has the following three core attributes::

• Target of subscription
• Target type of subscription: targetType
• Subscribed action

For example, if I publish an article, I will subscribe to the comment action of the Article XXX. Therefore, every comment in the article XXX requires a reminder to me.

Subscription rules can also be expanded
I like an article, And I publish an article, the subscription action may be different.
I like an article. I want to subscribe to the update and comment actions of this article.
I published an article. I hope I only subscribe to the comments of this article.

At this time, one more parameter is required: subscribReason
Different subscribReason correspond to an action array,
SubscribReason = like, corresponding to actions = [update, comment]
SubscribReason = publish, corresponding to actions = [comment]

Subscription rules can also be expanded.
Users may have their own subscription settings. For example, I do not want to receive all the favorite actions.
For example, Knewone's reminder settings

Knewone reminder settings

Therefore, we need to maintain another table:SubscriptionConfigTo store the user's reminder settings.
In addition, you can use the default settings provided by the system when no reminder settings are available:DefaultSubscriptionConfig

Aggregation

If I published an article "XXX", I was commented 10 times when I was not online. When I went online, I received 10 messages similar: 「 who commented on your article XXX 」?
Should I still receive a message: "A, B, C, Ding... commented on your article XXX"?

Zhihu is doing very well in aggregation. It is quite technical to know that they want to achieve this:
How is zhihu's message mechanism designed and planned technically?
How is the website message (notification) system generally implemented?

We have no specific implementation method for this part of the function, and we cannot make it more detailed at the moment. ⊙

Five entities

Through the above analysis, we will probably know what entity classes are required for this message system:

Behavior Decomposition

After talking about this, sort out some behaviors of the entire message process:

• System or administrator, create a message
  • CreateNotify (make announce | remind | message)
• User, subscribe to messages, cancel subscription
  • Subscribe, cancelsubscribe
• User Management subscription settings
  • GetSubscriptionConfig, updateSubscriptionConfig
• User: pull messages.
  • PullNotify (pull announce | remind | message | all)
• User: query message queues.
  • Getuserpolicy (get announce | remind | message | all)
• User reading message
  • Read

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> Model Design Example y

Id: {type: 'integer', primaryKey: true}, // primary key content: {type: 'text'}, // message content type: {type: 'integer', required: true, enum: [1, 2, 3]}, // message type, 1: Announcement Announce, 2: reminder Remind, 3: Message Messagetarget: {type: 'integer'}, // target IDtargetType: {type: 'string'}, // target type action: {type: 'string '}, // The Action type of the reminder message sender: {type: 'integer'}, // the sender's IDcreatedAt: {type: 'datetime', required: true}

Save Remind
Message table, we needtarget,targetTypeField to record the object associated with the reminder. WhileactionField to record the action associated with the reminder.
For example, the message "James liked the article 」
Then:

Target = 123, // The article IDtargetType = 'post', // specify the type of the target to be the article sender = 123456 // Xiaoming ID

Save Announce and Message
Of course, Notify also supports storing announcements and information. They will usecontentFields insteadtarget,targetType,actionField.

Userpolicy

Id: {type: 'integer', primaryKey: true}, // primary key isRead: {type: 'boolean', required: true}, user: {type: 'integer ', required: true}, // notify: {type: 'integer', required: true} // The associated policycreatedat: {type: 'datetime', required: true}

We use UserNotify to store the user's message queue, which is associated with the specific content of a reminder.
There are two ways to create userpolicy:

Subtasks

Target: {type: 'integer', required: true}, // The IDtargetType of the target: {type: 'string', required: true}, // The type action of the target: {type: 'string'}, // subscription action, for example, comment/like/post/update etc. user: {type: 'integer'}, createdAt: {type: 'datetime', required: true}

Subscription is a prerequisite for pulling a message from the Notify table to UserNotify. The user first subscribes to an action of a target, and then generates a message of this action of the target, will be notified to this user.
For example, "James pays attention to product A's comments". The data shows:

Target: 123, // IDtargetType of product A: 'product', action: 'comment', user: 123 // Xiaoming's ID

In this way, every comment produced under product A will generate A notification to Xiao Ming.

SubscriptionConfig

Action: {type: 'json', required: true}, // Set user: {type: 'integer '}

Different users may have different subscription habits. In this table, users can set whether to subscribe to a specific action. By default, the default configuration provided by the system is used:

DefaultSubscriptionConfig: {'comment': true, // comment 'like': true, // like}

In this model,targetType,actionIt can be expanded as needed. For example, we can add several more action reminders:hateTrampled,updateUpdated... and so on.

Configuration File yyconfig

// Target type associated with the reminder: {PRODUCT: 'product', // product POST: 'post' // Article}, // action associated with the reminder: {COMMENT: 'comment', // comment LIKE: 'like', // like}, // subscription event reasonAction: {'create _ product': ['comment ', 'like'] 'like _ product': ['comment'], 'like _ Post': ['comment'],}, // default subscription configuration defaultSubscriptionConfig: {'comment': true, // comment 'like': true, // like}

The service layer yyservicenotifyservice has the following methods:

• CreateAnnounce (content, sender)
• CreateRemind (target, targetType, action, sender, content)
• CreateMessage (content, sender, receiver)
• PullAnnounce (user)
• PullRemind (user)
• Subscribe (user, target, targetType, reason)
• Cancelsubtype (user, target, targetType)
• GetSubscriptionConfig (userID)
• UpdateSubscriptionConfig (userID)
• GetUserNotify (userID)
• Read (user, policyids)

The processing logic of each method is as follows:

CreateAnnounce (content, sender)

CreateRemind (target, targetType, action, sender, content)

CreateMessage (content, sender, receiver)

PullAnnounce (user)

PullRemind (user)

Subscribe (user, target, targetType, reason)

Cancelsubtype (user, target, targetType)

GetSubscriptionConfig (userID)

UpdateSubscriptionConfig (userID)

GetUserNotify (userID)

Read (user, policyids)

Subscription, creation, and pull of Sequence Chart reminders
Reminder subscription, creation, and pull

We can callNotifyService.subscribeMethod,
And then called after the product is commentedNotifyService.createRemindMethod,
Then, the user logs on to the system or calls it at another time.NotifyService.pullRemindMethod,
Finally, it is called when the user queries the message queue.NotifyService.getUserNotifyMethod.

Create and pull announcements
Create and pull announcements

When the Administrator sends an announcementNotifyService.createAnnounceMethod,
Then you can callNotifyService.pullAnnounceMethod,
Finally, it is called when the user queries the message queue.NotifyService.getUserNotifyMethod.

Information Creation
Information Creation

To create information, you only need to callNotifyService.createMessageMethod,
This message is queried next time you query the message queue.