设计模式：通知系统 [英] Design pattern : notification system
问题描述
我正在一个使用社交网络功能的网站（例如Facebook）。
我想实现一个显示内容的通知系统喜欢X添加你的朋友，Y邀请你参加派对，Z已经采取最后的问答...我不知道该怎么做。
我想知道什么是最好的解决方案：
- 解决方案1，又名日志记录。
专用表通知。每次在发生通知发生的事情（朋友添加，问答等等）时，我在此表中添加行。表格通知包含不同信息的字段，根据表格中添加什么样的通知。
好：容易代码，通知功能和正常功能之间的分隔，当我需要阅读表格时，资源消耗不会太高。
不好：通知表可能会增长很大（我想我将在表中添加10k行/天），重复信息：通知表中的信息可以在所有其他表中使用日期/列表/任何比较找到。
- 解决方案2，又名无处不在。
每次我需要显示通知列表或显示有多少新通知，我查看所有有关的表，比较日期/等等，以了解上次用户检查通知后是否发生新的事件。
好：与解决方案1相比，不是一个太大的表，没有信息的冗余。
坏：由于用户数量（〜1k +），我感到害怕，因为它是资源/耗时的，因此难以编码/维护，导致服务器爆炸。
你能告诉我你觉得好多了，为什么，还是有一个没有想到的解决方案？
感谢=）
编辑：
假设我使用了一个非常基本的数据库设计：用户有朋友，可以做测验。 1表用于用户列表，quizz列表，1表quizz< - >用户关系，1表用户< - >用户的友谊。
每当用户访问自己的个人资料时，他都可以看到发生了什么：new quizz< - >用户关系，新用户& - - 用户关系等
您将如何设计这样的通知？ / p>
创建一个系统队列，每个添加到此队列的消息都有一个消费者列表和内容。主要消息泵处理每个消息，并将消息发送给所有消费者。
让两个人互相交往。您向主系统队列添加消息，A为B的朋友，消费者为A和B.当您的消息pump（处理器）看到此消息时，将其添加到A队列和B队列中。现在用户A和用户B都有一个新消息，他们是朋友。反过来，每个用户都有一个消息处理器，所以当它看到一个叫做我是[某人]的朋友的消息时，它会处理这一点，为A的朋友添加一个新的墙壁条目，A是B的朋友等等。
这是非常简单的，但希望展示如何使用消息队列（非常类似的系统用作Windows UI框架），所以已经有一个现有的例子，并且有很多可以使用的同步消息队列模式。
休息由你决定。
I'm working on a website that will use features of social networking (like facebook for example).
I would like to implement a notification system which shows stuff like "X added you as a friend", "Y invite you to the party", "Z has taken the lastest quizz"... and i don't know how to do.
I wonder what is the best solution :
- Solution 1, aka "logging".
A dedicated table "notification". I add rows in this table everytime something that rise a notification happend (friend adding, quizz answering, etc.). The table "notification" has fields that contains different information, according to what kind of notification is added to the table.
Good : easy to code, separation between notification feature and "normal" features, not too much resources-consuming when i need to read the table.
Bad : Notification table will grow probably very big (i think I will add 10k rows/day in the table), "duplicated" information : informations in the notification table can be found in all other table using date/list/whatever comparison.
- Solution 2, aka "look everywhere".
Everytime i need to show the notification list or the show how much new notifications there are, I look to all the concerned table, compare date/etc to know if something new happened since the last time the user checked the notification.
Good : Not a too big table compared to solution 1, no "redundancy" of information.
Bad : I am affraid because of the number of user (~1k+), it make the server explode because it is resource/time consuming, little harder to code/maintain.
Can you please tell me what you think the better and why, or do you have a solution i didn't imagined ?
Thanks =)
Edit : Let's say i use a really basic DB design : users have friends, can do quizzes. 1 table for user list, quizz list, 1 table quizz<->user relation, 1 table user<->user for friendship. Everytime a user visit his own profile, he can see what happened : new quizz<->user relation, new user<->user relation, etc. How would you design a notification like that ?
Create a system queue, each message added to this queue has a list of "consumers" and the content. The main message pump processes each message and sends the message to all consumers.
Lets say 2 people befriend each other. You add a message to the main system queue that A is friends with B and consumers are both A and B. When your message "pump" (processor) sees this message it adds it to the queue of A and the queue of B. So now user A and user B have a new message that they are friends. In turn each user has a message processor, so when it sees a message called "I am friends with [someone]" it processes this as add a new entry to the "wall" visible to friends of A that "A is friends with B", etc.
This is overly simplistic but hopefully shows how message queues can be used for this (very similar system is used as the windows UI framework) so there is already an existing example and there are plenty of synchonized message queue patterns you can use.
Rest is up to you to design.
这篇关于设计模式：通知系统的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
