高并发系统设计40问
唐扬
美图公司技术专家
立即订阅
9524 人已学习
课程目录
已完结 45 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 为什么你要学习高并发系统设计?
免费
基础篇 (6讲)
01 | 高并发系统:它的通用设计方法是什么?
02 | 架构分层:我们为什么一定要这么做?
免费
03 | 系统设计目标(一):如何提升系统性能?
04 | 系统设计目标(二):系统怎样做到高可用?
05 | 系统设计目标(三):如何让系统易于扩展?
06 | 面试现场第一期:当问到组件实现原理时,面试官是在刁难你吗?
演进篇 · 数据库篇 (5讲)
07 | 池化技术:如何减少频繁创建数据库连接的性能损耗?
08 | 数据库优化方案(一):查询请求增加时,如何做主从分离?
09 | 数据库优化方案(二):写入数据量增加时,如何实现分库分表?
10 | 发号器:如何保证分库分表后ID的全局唯一性?
11 | NoSQL:在高并发场景下,数据库和NoSQL如何做到互补?
演进篇 · 缓存篇 (6讲)
12 | 缓存:数据库成为瓶颈后,动态数据的查询要如何加速?
13 | 缓存的使用姿势(一):如何选择缓存的读写策略?
14 | 缓存的使用姿势(二):缓存如何做到高可用?
15 | 缓存的使用姿势(三):缓存穿透了怎么办?
16 | CDN:静态资源如何加速?
加餐 | 数据的迁移应该如何做?
演进篇 · 消息队列篇 (6讲)
17 | 消息队列:秒杀时如何处理每秒上万次的下单请求?
18 | 消息投递:如何保证消息仅仅被消费一次?
19 | 消息队列:如何降低消息队列系统中消息的延迟?
20 | 面试现场第二期:当问到项目经历时,面试官究竟想要了解什么?
用户故事 | 从“心”出发,我还有无数个可能
期中测试 | 10道高并发系统设计题目自测
演进篇 · 分布式服务篇 (9讲)
21 | 系统架构:每秒1万次请求的系统要做服务化拆分吗?
22 | 微服务架构:微服务化后系统架构要如何改造?
23 | RPC框架:10万QPS下如何实现毫秒级的服务调用?
24 | 注册中心:分布式系统如何寻址?
25 | 分布式Trace:横跨几十个分布式组件的慢请求要如何排查?
26 | 负载均衡:怎样提升系统的横向扩展能力?
27 | API网关:系统的门面要如何做呢?
28 | 多机房部署:跨地域的分布式系统如何做?
29 | Service Mesh:如何屏蔽服务化系统的服务治理细节?
演进篇 · 维护篇 (7讲)
30 | 给系统加上眼睛:服务端监控要怎么做?
31 | 应用性能管理:用户的使用体验应该如何监控?
32 | 压力测试:怎样设计全链路压力测试平台?
33 | 配置管理:成千上万的配置项要如何管理?
34 | 降级熔断:如何屏蔽非核心系统故障的影响?
35 | 流量控制:高并发系统中我们如何操纵流量?
36 | 面试现场第三期:你要如何准备一场技术面试呢?
实战篇 (4讲)
37 | 计数系统设计(一):面对海量数据的计数器要如何做?
38 | 计数系统设计(二):50万QPS下如何设计未读数系统?
39 | 信息流设计(一):通用信息流系统的推模式要如何做?
40 | 信息流设计(二):通用信息流系统的拉模式要如何做?
结束语 (1讲)
结束语 | 学不可以已
高并发系统设计40问
登录|注册

40 | 信息流设计(二):通用信息流系统的拉模式要如何做?

唐扬 2019-12-25
你好,我是唐扬。
在前一节课中,我带你了解了如何用推模式来实现信息流系统,从中你应该了解到了推模式存在的问题,比如它在面对需要支撑很大粉丝数量的场景时,会出现消息推送延迟、存储成本高、方案可扩展性差等问题。虽然我们也会有一些应对的措施,比如说选择插入性能更高的数据库存储引擎来提升数据写入速度,降低数据推送延迟;定期删除冷数据以减小存储成本等等,但是由于微博大 V 用户粉丝量巨大,如果我们使用推模式实现信息流系统,那么只能缓解这些用户的微博推送延迟问题,没有办法彻底解决。
这个时候你可能会问了:那么有没有一种方案可以一劳永逸地解决这个问题呢?当然有了,你不妨试试用拉模式来实现微博信息流系统。那么具体要怎么做呢?

如何使用拉模式设计信息流系统

所谓拉模式,就是指用户主动拉取他关注的所有人的微博,将这些微博按照发布时间的倒序进行排序和聚合之后,生成信息流数据的方法。
按照这个思路实现微博信息流系统的时候你会发现:用户的收件箱不再有用,因为信息流数据不再出自收件箱,而是出自发件箱。发件箱里是用户关注的所有人数据的聚合。因此用户在发微博的时候就只需要写入自己的发件箱,而不再需要推送给粉丝的收件箱了,这样在获取信息流的时候,就要查询发件箱的数据了。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《高并发系统设计40问》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(9)

  • 小白哥哥
    “如果活跃粉丝数量超过了长度,就把最先加入的粉丝从列表里剔除”,这块是不是会有问题。
    最先假如的活跃粉丝很可能一直是活跃的,因为长度有限的原因就把他挑出来会不会不太好。

    作者回复: 剔除了无非就是无法实时获取到消息,但是他还是会被加入到活跃粉丝列表中,而且,在刷新信息流的时候可以拉取大V的发件箱做数据补偿

    2019-12-25
    2
  • 旅途
    老师有两个地方没懂希望能解答下
    1.缓存副本 100m缓存了60% 使用了60m带宽 ,主缓存 消耗剩下40%就是40m带宽 这样的话 加起来不还是100m带宽吗
    2.推拉模式的例子,只有活跃用户是实时推送,不活跃用户异步推送,这样的话不是都使用的推模式吗?

    作者回复: 1. 但是每一个缓存的带宽降低了
    2. 不活跃用户是不推送,但是不活跃用户上线后会拉取发件箱,所以叫推拉结合

    2019-12-25
    1
    1
  • Jxin
    1.闲时非活跃列表的活跃用户的信息同步。这个感觉也可以有。一礼拜没登陆的用户可以跳过,这种用户登陆时拉能更好的优化数据传输。

    2.分到6个缓存节点各自做批量拉取,能理解。但如果是redis集群,我是不是得再业务层再实现一套一样的分槽算法?

    作者回复: 差不多吧 需要知道在哪一个节点上

    2019-12-28
  • 星空123
    老师666

    作者回复: 谢谢关注,感谢一路相伴,祝君前程似锦

    2019-12-27
  • 阿土
    老师你好,查询后数据聚合的时候,分页怎么做的呢?
    2019-12-27
  • 任鹏斌
    打个卡结束了,第二遍好好总结下

    作者回复: 感谢您的一路陪伴,㊗️前程似锦~

    2019-12-26
  • 高源
    老师向你请教问题,开发的服务端程序与客户端通信现在连接有10个,接收发送socket,现在客户端发送了日志或报警信息都是毫秒级的2到3毫秒的日志和报警上来,中间还有业务交互现在能收的过来,处理上用队列,而且涉及业务的要马上响应超时时间2秒,消息日志报警业务都上来,怎么提高处理速度,业务上有顺序的,提高吞吐率

    作者回复: 说实话,我没看懂。。是说要传递日志和业务数据,然后要保证业务处理速度?

    2019-12-26
    4
  • QQ怪
    这两篇真的实践出真理,好厉害老师

    作者回复: 谢谢,我只是站在前人的肩膀上😂😂

    2019-12-25
  • 黄海峰
    这个专栏真的篇篇干货,每篇都能让我理通一些以前似懂非懂的疑惑,忍不住留言感恩一下

    作者回复: 谢谢,有帮助就好~

    2019-12-25
收起评论
9
返回
顶部