38 | 计数系统设计（二）：50万QPS下如何设计未读数系统？

2019-12-20 唐扬
《高并发系统设计 40 问》
课程介绍


讲述：唐扬

时长:大小10.97M


你好，我是唐扬。
在上一节课中我带你了解了如何设计一套支撑高并发访问和存储大数据量的通用计数系统，我们通过缓存技术、消息队列技术以及对于 Redis 的深度改造，就能够支撑万亿级计数数据存储以及每秒百万级别读取请求了。然而有一类特殊的计数并不能完全使用我们提到的方案，那就是未读数。
未读数也是系统中一个常见的模块，以微博系统为例，你可看到有多个未读计数的场景，比如：
当有人 @你、评论你、给你的博文点赞或者给你发送私信的时候，你会收到相应的未读提醒；
在早期的微博版本中有系统通知的功能，也就是系统会给全部用户发送消息，通知用户有新的版本或者有一些好玩的运营活动，如果用户没有看，系统就会给他展示有多少条未读的提醒。
我们在浏览信息流的时候，如果长时间没有刷新页面，那么信息流上方就会提示你在这段时间有多少条信息没有看。
那当你遇到第一个需求时，要如何记录未读数呢？其实，这个需求可以用上节课提到的通用计数系统来实现，因为二者的场景非常相似。
你可以在计数系统中增加一块儿...

展开全文
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。

精选留言

  • 钱
    2020-05-10
    未读数这种需求目前还没做过，不过也做过70WTPS的接口服务，其他组在大促时也百万级千万级也有，主要思路是类似的缓存＋集群，缓存可以多级缓存，集群数量可以成百上千。
    缓存——本质是专业的人做专业的事情的思想，它的内部结构决定了他就是快

    集群——本质是分而治之的思想，人多力量大，当然需要劲往一处使才行

    取巧——本质是发现她的规律，选择合适的数据结构和算法，也能极大的加快运行的速度

    场景——本质看有无必要万无一失，万无一失不好实现的，不过和钱不强相关，不万无一失也可以，如果用户本身也不同在乎，那就更容易了，统计错误也不打紧的
    展开
    共 1 条评论
    23
  • rumly
    2020-07-11
    仅仅用 16 台普通的服务器就支撑了每秒接近 50 万次的请求 相当于每台机器能够承担的QPS是 31250。这个单机QPS已经非常高了，如果带REIDS访问的服务就更难了，想问下具体的细节，单机的QPS是如何达到这么高的？谢谢。
    共 1 条评论
    6
  • 小可
    2019-12-20
    这三个方案都很“硬核”，不过最最重要的，不要照搬硬套，还是要根据实际场景分析问题的难点，找准关键点，制定应对方案，谢谢老师。

    作者回复: 谢谢~

    
    7
  • 阿土
    2019-12-20
    考试你好，我有两个问题
    第一:关注的人删除了博文，记录的博文数要不要相应减少？快照里面的数据要不要减少？
    第二:如果一个人关注的人很多，比如有一千个，那么它每次过去未读数就就要读取1001次缓存，能够支持50w并发，性能上是如何优化的？

    作者回复: 1. 博文数要减少，快照不能减少，所以不是很精确，不过应该可以接受
    2. 不需要1001次哦，如果有四个缓存节点，就读四次，每次是批量获取的，就是算好哪些数据存储在哪个缓存节点上

    共 5 条评论
    4
  • Geek_219216
    2020-01-13
    老师 未读数还会落地到数据库吗

    作者回复: 不会的，直接用redis

    
    2
  • longslee
    2020-01-09
    打卡。感谢老师实战经验，眼界开阔了许多。 有一个疑问，这些方案，是老师你们独特想到的，还是业界通用做法呢，如果是业界通用的，业界都是从哪里最先开始获取到理论支持的呢？

    作者回复: 其实方案是理论的实践，理论是通用的，方案是独特的

    
    3
  • Geek_2b64f5
    2020-08-30
    如果一个人关注的明星或者好友非常多的时候，快照的数据结构怎么设计？怎么保证redis读取全量快照的延时？
    
    1
  • 陈琪
    2020-04-01
    是否可以按大V和非大V结合处理的方式： 推拉结合
    1. 发文的时候，如果这个人粉丝数少，直接推送到他每个粉丝数的 "普通未读数计数"，
    2. 如果这个人是大V，就不推。
    3. 用户获取未读数 = (他关注的大V里总数-快照数) + “普通未读数计数”
    需要考虑的就是一个用户从普通V变成了大V。
    这种总体读写性能都能比较好平衡，老师觉得呢
    展开

    作者回复: 粉丝数其实就是大v和非大v的区分

    共 2 条评论
    1
  • Jone_乔泓恺
    2020-03-26
    总是担心 redis 这种内存型数据库会因为服务器故障导致数据的丢失

    作者回复: 主从+主备就好了

    
    1
  • zk_207
    2020-03-05
    扬哥你好，请教个问题，如果接口QPS到达20w甚至是50w级别，只靠缓存能承受得了吗？Redis并发到了10w级好像性能就不行了，请求解答，谢谢

    作者回复: 可以用多个节点来扛呀：）

    
    1
  • 大龄程序员在线治掉发
    2020-01-07
    统计这个 ID 之后有多少条消息，这就是未读数了
    我这里有个疑问,如果用户有10条未读,他直接读第五条消息,那么10-5 = 5 , 就是5个未读,实际上是9条,这样未读就不对了?

    作者回复: 这个场景在读的时候只能把之前未读的消息都读了

    
    2
  • Geek_42f729
    2020-01-06
    如果有多个组件需要展示红点，是不是需要根据不同的组件给用户创建多个不同的时间戳来进行比较呢？

    作者回复: 是的

    
    1
  • 黄展志
    2019-12-20
    谢谢唐老师，受益良多，加油，等你更新最后三讲

    作者回复: 我们一起成长进步

    
    1
  • 边际革命
    2020-11-17
    感谢老师，给我开阔了眼界
    
    
  • 飞鸟在途
    2020-10-12
    免流量和微博运动那个打点是针对一个个uid的精准打点，不能用全量打点的方式实现。
    
    
  • 123456
    2020-03-26
    感觉有点小疑问:杨幂发了一条微博， 然后删了一条两年前的微博， 粉丝们的未读数可能就不会有变化了

    作者回复: 会不那么准确

    
    
  • Bravery168
    2020-03-16
    我之前在实现红点消息和未读数也采用的是时间戳偏移计算的思路，当然数据规模没有微博这么大。这里用到通用计数器和快照比较得出未读数的思路挺好，任何实现方案还是要紧密结合应用场景来做精心设计，在存储，读写性能等维度上达到一个平衡。

    作者回复: 是的

    
    
  • 亚马逊森林
    2020-03-14
    老师你好，redis的bitmap 存储系统未读书也是可行的吧，整串表示某条系统消息，字串的索引存储用户id，值存储用户是否未读

    作者回复: 要实际测试一下存储空间消耗情况

    共 2 条评论
    
  • 👽
    2020-02-24
    影响系统设计的最主要因素还是业务的并发量，
    并发量低的时候，耗时长的业务，也不是问题。
    并发量高的时候，耗时再短的业务，也是问题。

    这一节，主要的解决问题的思路，还是用缓存来处理这种高频请求的问题；当一个请求需要被大量访问，就需要考虑缓存来代替关系型数据库。

    进一步处理就是，用空间换时间。消息未读数这种，即时性极高的业务，需要这种空间换时间的处理方式。
    展开

    作者回复: 👍

    
    
  • 张德
    2020-01-02
    这一讲通俗易懂 很棒

    作者回复: 谢谢

    
    