Design problems of Web message notification system

General Web site will be a message alert notification, such as a user to another user sent a station letter, then the site at the top of the navigation bar will have a message alert number to prompt you to have new messages.

Above is just a simple example, in the actual project may have a variety of types of reminders, such as a user left you a message, the reminder "new message X" or "New reply Y" and so on.

I'm going to design it to put all types of messages into a single table (notice), and to mark whether the user has processed the message reminder, the site's front desk can only count this table, such as User A to User B sent a private message, A new unread message reminder is inserted in the notice table to remind the user that when user B views the completed messages, the notice table is marked as processed or deleted directly.

However, there is a problem when the large data volume or high concurrency, when the user has already viewed the newly received private message, to go to the notice table for marking processing, there may be a variety of reasons for its corresponding "unread message reminder" has not been written in, this time there is a problem, when the user to request whether there is "unread messages reminder", Just write it in again, and then prompt the user to have a "new message", but in fact the user has already disposed of, but it is "unread message reminder" delay.

If the statistics of new reminders, to the various businesses (such as private messages, messages) in separate statistics, and then merge, and then notify the user, so, how to be called "Message notification System"? I always thought it was unreasonable.

For the message notification system, does my notice table have the meaning of existence, how do you design?

Reply content:

General web site will be a message alert notification, such as a user to another user sent a station letter, then the site at the top of the navigation bar will have a message alert number to prompt you to have new messages.

Above is just a simple example, in the actual project may have a variety of types of reminders, such as a user left you a message, the reminder "new message X" or "New reply Y" and so on.

I'm going to design it to put all types of messages into a single table (notice), and to mark whether the user has processed the message reminder, the site's front desk can only count this table, such as User A to User B sent a private message, A new unread message reminder is inserted in the notice table to remind the user that when user B views the completed messages, the notice table is marked as processed or deleted directly.

However, there is a problem when the large data volume or high concurrency, when the user has already viewed the newly received private message, to go to the notice table for marking processing, there may be a variety of reasons for its corresponding "unread message reminder" has not been written in, this time there is a problem, when the user to request whether there is "unread messages reminder", Just write it in again, and then prompt the user to have a "new message", but in fact the user has already disposed of, but it is "unread message reminder" delay.

If the statistics of new reminders, to the various businesses (such as private messages, messages) in separate statistics, and then merge, and then notify the user, so, how to be called "Message notification System"? I always thought it was unreasonable.

For the message notification system, does my notice table have the meaning of existence, how do you design?

About the design of the message system, must be a data table to record notifications, such as notice table, as for this notice there may be many types, like you say the message and messages, which can be represented in the design by the field, here to share the Worktile notice data structure design.

{    nid: {type:string, unique:true},    Published: {type:number, default:Date.now},    verb: {type:string},    Template: {type:string},    is_read: {type:number, index:true, default:0},    is_pending: {type:number, I Ndex:true, default:0},    filter: {        ftype: {type:string}    },    sender: {type:actor},    receiver: { Type:string, index:true},    data: {        entity: {type:entity},        Source: {type:entity},        target: {typ E:entity}}}    

Detailed design can refer to a standard of activity
As far as you say the message high concurrency problem is actually no problem, you mark the unread message as read after the Switch page, which is again read unread message before the mark as read should have been processed already. Unless your system has reached a high level of concurrency and the system is paralyzed, you do not need to be overly optimized when you are not experiencing bottlenecks, and even if you have a solution to the bottleneck, you can improve performance by putting all unread messages into memory or Redis.

The above is the data structure, the general Web messages are updated in real-time, meaning: You do not refresh the page, at this time the message, you should immediately display the number of unread messages. The practice of the real-time messaging system depends on what language your server uses. Node.js+socket.io
Is easy to do, our product worktile is implemented in the Erlang language

The feeling is that the system has a bottleneck, need a layer of message cache, direct database read and write message efficiency is low, because the database in writing can be read when the data inconsistency, the message exists in the memory of the upstairs Redis or memcache, if still will appear write, read inconsistent situation, should be horizontal expansion of it!

Related articles:

Message notification mechanism for HTML 5

Implementation of the REDIS message notification system

Message notification plug-in based on HTML5 notifications API

