网站的消息(通知)系统一般是如何实现的?

就比如说知乎为每个用户发送的通知这样的功能。
关注者
173
被浏览
38,646
登录后你可以
不限量看优质回答私信答主深度交流精彩内容一键收藏

我来尝试回答一下把。像知乎这样的通知系统通常都需要一个专门的队列工具来实现。

说到队列系统无非就两种思路,一种是推的,一种是拉的。

每个用户,问题等等可以关注的东西都有一个队列,可以理解成一个有限大小的有序集合。

推的比较常见,就是例如这个知乎的这个问题,维护着一张关注者的列表,每当触发这个问题推送的条件时(例如有人回答问题),就把这个通知发送给每个关注者。

拉的相对麻烦一点,就是推的反向,例如每个用户都有一张关注问题的列表,每当用户上线的时候,对每个问题进行轮询,当问题的事件列表出现了比我原本时间戳大的信息就进行拉取。

由于赞同、评论,回答,感谢,关注,私信。。。。太多太多东西能够触发消息系统了,所以可以说知乎的消息系统非常的忙碌,当忙碌到一定程度的时候问题就出现了。例如在推的模式下,@张亮,@周源什么的关注者极多,这种人突然抽风似得开始点击赞同,系统就会出现一下要推给上万上百万人次的宕机困境,在拉的模式下,几十个关注了所有知乎的所有问题所有活跃用户的狂人突然高兴了,一起上线也是一样的道理。

所以这样的消息系统平时问题不大,但是在消息峰值的时候却通常是服务器的噩梦。所以一般来说,一个网站在架构的时候,会为这样忙碌的消息系统采用比较高速的存储介质,例如 Redis ,MemCache 都是用内存,据说新浪微博还在几台服务器上用上了 L3 Cache .其次,这样的消息系统通常需要一个延迟处理系统来进行工作颗粒的细化和调度,例如 Resque,DelayJob 这样的开源库,再次就是对于推拉模式的取舍进行优化,例如 Twitter 在服务器较繁忙的时候只会对 Online 的 用户推送,offline 的用户延迟推送,活跃用户用推,不活跃用户用拉,等等。

总之这个问题是大数据的时候比较典型的东西。不过,很多东西在产品出生前就做出架构是很难也是没必要的,都是在具体问题演生的同时进行处理和升级。