如何为信息流的未读数设计方案：
信息流的未读数之所以复杂主要有这样几点原因：
首先，微博的信息流是基于关注关系的，未读数也是基于关注关系的，就是说，你关注的人发布了
新的微博，那么你作为粉丝未读数就要增加 1。如果微博用户的粉丝数少就简单了，你发微博的时候系
统给你粉丝的未读数增加 1 不是什么难事儿。但是对于大v增加未读数可能需要几个小时。所以未
读数的延迟是你在设计方案时首先要考虑的内容。其次，信息流未读数请求量极大、并发极高，这是因
为接口是客户端轮询请求的，不是用户触发的。也就是说，用户即使打开微博客户端什么都不做，这个
接口也会被请求到。在几年前，请求未读数接口的量级就已经接近每秒 50 万次，这几年随着微博量
级的增长，请求量也变得更高。而作为微博的非核心接口，我们不太可能使用大量的机器来抗未读数请
求，因此，如何使用有限的资源来支撑如此高的流量是这个方案的难点。最后，它不像系统通知那样有
共享的存储，因为每个人关注的人不同，信息流的列表也就不同，所以也就没办法采用系统通知未读数
的方案。
其次，信息流未读数请求量极大、并发极高，这是因为接口是客户端轮询请求的，不是用户触发的。
也就是说，用户即使打开微博客户端什么都不做，这个接口也会被请求到。在几年前，请求未读数接口
的量级就已经接近每秒 50 万次，这几年随着微博量级的增长，请求量也变得更高。而作为微博的非
核心接口，我们不太可能使用大量的机器来抗未读数请求，因此，如何使用有限的资源来支撑如此高的
流量是这个方案的难点。
最后，它不像系统通知那样有共享的存储，因为每个人关注的人不同，信息流的列表也就不同，所以也
就没办法采用系统通知未读数的方案。
那要如何设计能够承接每秒几十万次请求的信息流未读数系统呢？你可以这样做：
首先，在通用计数器中记录每一个用户发布的博文数；
然后在Redis中记录一个人所有关注人的博文数快照，当用户点击未读消息重置未读数为 0 时，
将他关注所有人的博文数刷新到快照中；
此文章为6月Day14学习笔记，内容来源于极客时间《高并发系统设计 40 问》
