web消息通知系统设计问题

Question

一般网站上都会消息提醒通知，如一个用户给另一个用户发了一条站内信，那么就会在网站顶部的导航栏上就会有一个消息提醒的数字来提示您有新消息。上面只是一个简单例子，在实际项目中可能就会有多种类型的提醒，如某个用户给你留言了，就显示提醒“新留言x条”或者“新回复y条”等等吧。我打算设计成把所有类型的消息提醒统一的放到一张表（notice）里，并标记用户是否已处理了这条消息提醒，在网站的前台就可以只统计这一张表就行了，比如用户A给用户B发送了一条私信，就在notice表里插入一条新的未读消息提醒，用来提醒用户，当用户B查看完成私信后，再回到这张notice表标记为已处理或者直接删除。但是大数据量或高并发的时候就会存在一个问题，当用户已经查看完了新收到的私信后，去notice表做标记处理时，可能由于种种原因其对应的“未读消息提醒”还没有写进去，这时候就出问题了，当用户去请求是否有“未读消息提醒”时，刚好又写进去了，然后就提示用户有“新消息”，但是实际上用户早已处理掉了，只不过就是“未读消息提醒”延时了。如果说统计新消息提醒，去各个业务（如私信，留言）中单独统计，然后合并，再通知给用户，这样做的话，怎么称得上是“消息通知系统”呢？总觉得这样是不合理的对于消息通知系统，我的notice表是否有存在的意义呢，大家是怎么设计的？

Answer 1

感觉就是系统有了瓶颈，需要一层消息缓存了，直接数据库读写消息效率偏低了，因为数据库在写的时候可读导致数据不一致，消息存在内存中楼上的redis或者memcache中，如果还是会出现写，读不一致的情况，应该横向拓展了吧！