平台消息推送是如何实现的

       在正在做的项目里，有这样一个需求，就是平台发送通知给每个用户。每个用户都会收到通知，而且会显示已读未读的状态。
对于上面的这种场景。最简单的实现思路是：
       用户数量与通知数量为多对多，只需要做一个中间表就可以实现。

方案一：

       这种实现思路中，如果用户表的数量为N，通知表里面的数据为M。那么关系表的数据量，将会达到N*M的数据量。每个用户在关闭表中都会有M条通知，在关系表里面，可以通过IsRead字段 来区分该消息是否已读。
       这种实现方式，在管理端每发布一个通知，都会在关系表里面存放N条记录。最终这种方案的关系表里面，会有N*M的数据量。

方案二：

       是对方案一的进一步优化。也是在管理端发布通知之后，在关系表里面存放N条记录。但与一不同的是，关系表里面可以不设计IsRead字段。如果用户点击通知（阅读之后）则把该记录删除即可。整体的实现思路是，该关系表里面，只存放未读消息，的确可以减少数据。
       但是这种方式存放弊端，对于平台来说，活跃的用户总会比不活跃的用户要少。这种做法的话，对于那些“僵尸用户”来说，他们的未读消息状态常年不动。所以也会有很多的数据浪费。

方案三：

       与方案二相反。即：后台发布通知之后，通知只存在与通知表。用户查看通知的时候，会查询通知表。当阅读一条之后，则把阅读的那一条通知，写到关系表。
       即：关系表里面存放的都是用户的已读通知。这种方式，比二的数据量要小一些。但是关系表的数据会越来越多，而且没有办法备份。

对比以上几种方式，

       我们可以结合上面几种方案：当用户登录的时候，在向关系表里面写通知信息。当阅读之后在删除，这样做的话关系表里面就不用保存数据了。
       这个问题的关键，就是登录的时候，在发通知，关系表里面不保存数据，那么是如何区分 新通知的？
       如果不做区分的话，每次用户登录的时候都会收到M条通知，肯定是不合理的。为了解决这种情况，我们可以通过上次登录时间与通知发放时间做比较，进而发送新通知。
       这种做法，优点是，很大程度的节省了空间，缺点是，用户通知的历史记录没有保存下来。
       当然也可以使用isRead字段来保留历史记录。结合上面几种方案，可根据不同的需求进行选择。