关于网站推送消息的几个初步考虑

最近在考虑系统推送消息的实现。尚未技术实现，但有以下几点思考。

1.关于websocket。

查阅了相关资料，考虑到轮询、长连接等方式的弊端，个人感觉应该用websocket更好一些。

毕竟有消息了服务器主动推送这样的模式更贴近生活和经验，没事儿老是让客户端不停问服务器有没有消息，这种模式浪费消息资源，浪费服务器资源。

2.关于消息的类型。

考虑到一般网站等现实需求，消息大致分为系统消息和用户消息。

系统消息，就是一条消息，所有用户都应当被提示，有未读消息。

用户消息，就是针对某一个或几个用户相关的推送消息，比方说谁评论了谁的留言，那么这个消息就应该只和这几个相关人有关系，那么，其他用户是不应该被推送的。

3.关于事件和消息的关系。

大多数情况下，消息是伴随着事件产生的，但是事件不一定产生消息。

举个例子，比如A评论了B的文章，那么这是一个事件，从而应当产生一个消息，提示B有一个未读消息，A评论了你的文章。这是事件产生消息。但是，如果A点赞了B，可以不需要对B进行提示。这就是事件并不产生消息。这只是举个例子，不一定非要较真点赞是否要推送。

那么，怎么样才算是一个真正的事件呢？我觉得，一个事件，应该是被写入到数据库中的一个行为。只有写入了数据库中的行为才算事件。这样考虑的好处有，一是每次涉及到数据库写入的时候不会忘记考虑这个行为是否会产生消息，二是排除掉一些模棱两可的不重要行为。当然，如果非要考虑类似于好友上线提醒这样的功能，也可以（：]）。

4.关于表单存储的考虑。我觉得应该有3张表，分别是用户消息表，系统消息表，系统消息记录表。

用户消息表大致包括主键id，消息类型，内容，接收者id，读标记，读时间，产生时间这几项。

系统消息表大致包括主键id，消息类型，内容，产生时间这几项。

系统消息记录表大致包括消息id，用户id，状态，读时间这几项。系统消息记录表主要记录系统消息被用户读取的情况。从理论上来说，每产生一条系统消息，将对应会有用户数量条数据用以标记每个用户是否读到了这条系统消息。目前没有想到更好的办法，如有高见，不吝请教。

以上只是一些初步思考，后续将记录具体实现方法。