高并发系统设计40问
唐扬
美图公司技术专家
立即订阅
9511 人已学习
课程目录
已完结 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问
登录|注册

39 | 信息流设计(一):通用信息流系统的推模式要如何做?

唐扬 2019-12-23
你好,我是唐扬。
前两节课中,我带你探究了如何设计和实现互联网系统中一个常见模块——计数系统。它的业务逻辑其实非常简单,基本上最多只有三个接口,获取计数、增加计数和重置计数。所以我们在考虑方案的时候考察点也相对较少,基本上使用缓存就可以实现一个兼顾性能、可用性和鲁棒性的方案了。然而大型业务系统的逻辑会非常复杂,在方案设计时通常需要灵活运用多种技术,才能共同承担高并发大流量的冲击。那么接下来,我将带你了解如何设计社区系统中最为复杂、并发量也最高的信息流系统。这样,你可以从中体会怎么应用之前学习的组件了。
最早的信息流系统起源于微博,我们知道,微博是基于关注关系来实现内容分发的,也就是说,如果用户 A 关注了用户 B,那么用户 A 就需要在自己的信息流中,实时地看到用户 B 发布的最新内容,这是微博系统的基本逻辑,也是它能够让信息快速流通、快速传播的关键。 由于微博的信息流一般是按照时间倒序排列的,所以我们通常把信息流系统称为 TimeLine(时间线)。那么当我们设计一套信息流系统时需要考虑哪些点呢?

设计信息流系统的关注点有哪些

首先,我们需要关注延迟数据,也就是说,你关注的人发了微博信息之后,信息需要在短时间之内出现在你的信息流中。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《高并发系统设计40问》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(7)

  • 台风骆骆
    信息流的架构演化
    1、一开始很简单,两张表,一张存储关注关系 ,一张存储微博消息,用户A发微博就是在相应的微博消息表中写入一条即可,用户B读微博也很简单,就是先得到自己关注的用户列表,然后定时去存储微博消息表中去读取自己关注的微博展示出来即可,优点是只有一份存储,缺点也很明显,对于这张表的读操作太多了,并发过大。
    2、改成推模式,即写扩散机制,用户A发送一条消息,除了写入微博消息表以外,还要写入关注它的所有的用户的收件箱中(这个可以用redis来实现),然后用户去收件箱中读取消息即可,优点就是自己读自己的消息,跟别人没有竞争,缺点是多余存储,在大V用户发微博消息中有延迟,同时写入次数太多了,同时取消关注什么的也比较难操作。
    3、后面改成了推拉结合的方式,即对于大V用拉模式,对于普通的用户继续用推模式。
    4、后面出现了基于时间分区的拉模式,个人觉得可以结合推模式来进行相应的弥补。

    作者回复: 👍

    2019-12-23
    5
  • tt
    我觉得推模式最大的问题是没有做到按需传递信息,可能一个粉丝的用户中,只有很少比例才需要较高的时效性,这些用户不应该消耗太多的系统资源。

    此外,推模式中的写操作太多了,一个人发送,其他人在本质上都是读取这条消息,却也引发了写入操作。

    应该把新的信息写入到若干存储(包括缓存上),然后选择适当的策论,让用户去这些存储上读取数据。这样可以大大降低写入操作的数量。

    作者回复: 是的

    2019-12-23
    1
    1
  • 海罗沃德
    跟微博比,我們的信息流弱爆了,目前都是用elasticsearch做信息流拉模式,閱讀之後就給當前頁的數據批量設置狀態,拉到下一頁就給下一頁數據更新狀態

    作者回复: 存在即合理~

    2019-12-23
    1
    1
  • Jxin
    1.根据分组又建一张表。应该不存全量数据吧,太浪费空间。存与全局收件箱的id映射就好了吧。

    2.这个推模式确实有点恐怖。大量写操作简直就是噩梦。硬刚实现这种大量写是不现实的。所以改成拉模式,在登陆时按需拉取。但全量的按需拉取,登陆时的信息同步延迟也是不能接受,所以推拉结合以及更细力度的操作,满满都是权衡。长见识。

    3.拉可以批量可以压缩,其实优化的空间会大点。

    作者回复: 一般收件箱都是记录ID,也就是对应关系,但即使这样,写入量依然很高

    2019-12-28
  • skyeinfo
    老师,对于信息流的缓存存储有什么比较好的建议呢?因为考虑到分页、过滤等筛选条件。

    作者回复: 微博是只存储发件箱,并且是按照时间来分为多级缓存,比如把最近五天的微博ID存储到一组缓存里面,所以可以存储全量。

    考虑过滤的话,也会存储一些用于过滤的flag信息

    2019-12-23
  • Luciano李鑫
    不理解为什么基于推模式要给每个用户甚至每个分组存储一份完整的消息,为什么不能用存储关联关系,计算得到推送的消息呢?

    作者回复: 是需要存储微博ID,不存储微博的内容,我不知道你提到的存储关联消息指的是不是这个

    2019-12-23
  • 知行合一
    推模式中可以给用户分优先级,优先推送优先级高的用户的方式来提升用户体验。

    作者回复: 是的,推拉结合 是这样的

    2019-12-23
收起评论
7
返回
顶部