38-计数系统设计（二）：50万QPS下如何设计未读数系统？_For_group_share1
需积分: 0 150 浏览量
2022-08-03
16:16:53
上传
评论
收藏 472KB PDF 举报
38-计数系统设计（⼆）：50万QPS下如何设计未读数系统？38-计数系统设计（⼆）：50万QPS下如何设计未读数系统？
你好，我是唐扬。
在上⼀节课中我带你了解了如何设计⼀套⽀撑⾼并发访问和存储⼤数据量的通⽤计数系统，我们通过缓存技
术、消息队列技术以及对于Redis的深度改造，就能够⽀撑万亿级计数数据存储以及每秒百万级别读取请求
了。然⽽有⼀类特殊的计数并不能完全使⽤我们提到的⽅案，那就是未读数。
未读数也是系统中⼀个常⻅的模块，以微博系统为例，你可看到有多个未读计数的场景，⽐如：
那当你遇到第⼀个需求时，要如何记录未读数呢？其实，这个需求可以⽤上节课提到的通⽤计数系统来实
现，因为⼆者的场景⾮常相似。
你可以在计数系统中增加⼀块⼉内存区域，以⽤⼾ID为Key存储多个未读数，当有⼈@你时，增加你的未读
@的计数；当有⼈评论你时，增加你的未读评论的计数，以此类推。当你点击了未读数字进⼊通知⻚⾯，查
看@你或者评论你的消息时，重置这些未读计数为零。相信通过上⼀节课的学习，你已经⾮常熟悉这⼀类
系统的设计了，所以我不再赘述。
那么系统通知的未读数是如何实现的呢？我们能⽤通⽤计数系统实现吗？答案是不能的，因为会出现⼀些问
题。
系统通知的未读数要如何设计系统通知的未读数要如何设计
来看具体的例⼦。假如你的系统中只有A、B、C三个⽤⼾，那么你可以在通⽤计数系统中增加⼀块⼉内存区
域，并且以⽤⼾ID为Key来存储这三个⽤⼾的未读通知数据，当系统发送⼀个新的通知时，我们会循环给每
⼀个⽤⼾的未读数加1，这个处理逻辑的伪代码就像下⾯这样：
这样看来，似乎简单可⾏，但随着系统中的⽤⼾越来越多，这个⽅案存在两个致命的问题。
⾸先，获取全量⽤⼾就是⼀个⽐较耗时的操作，相当于对⽤⼾库做⼀次全表的扫描，这不仅会对数据库造成
很⼤的压⼒，⽽且查询全量⽤⼾数据的响应时间是很⻓的，对于在线业务来说是难以接受的。如果你的⽤⼾
库已经做了分库分表，那么就要扫描所有的库表，响应时间就更⻓了。不过有⼀个折中的⽅法，不过有⼀个折中的⽅法，那就是在
发送系统通知之前，先从线下的数据仓库中获取全量的⽤⼾ID，并且存储在⼀个本地的⽂件中，然后再轮询
所有的⽤⼾ID，给这些⽤⼾增加未读计数。
当有⼈@你、评论你、给你的博⽂点赞或者给你发送私信的时候，你会收到相应的未读提醒；
在早期的微博版本中有系统通知的功能，也就是系统会给全部⽤⼾发送消息，通知⽤⼾有新的版本或者有
⼀些好玩的运营活动，如果⽤⼾没有看，系统就会给他展⽰有多少条未读的提醒。
我们在浏览信息流的时候，如果⻓时间没有刷新⻚⾯，那么信息流上⽅就会提⽰你在这段时间有多少条信
息没有看。
List<Long>userIds=getAllUserIds();
for(Longid:userIds){
incrUnreadCount(id);
}
评论0