微博feed系统的推(push)模式和拉(pull)模式和时间分区拉模式架构探讨

简介: sns系统,微博系统都应用到了feed(每条微博或者sns里的新鲜事等我们称作feed)系统,不管是twitter.com或者国内的新浪微博,人人网等,在各种技术社区,技术大会上都在分享自己的feed架构,也就是推拉模式(timyang上次也分享了新浪微薄的模式)。

   sns系统,微博系统都应用到了feed(每条微博或者sns里的新鲜事等我们称作feed)系统,不管是twitter.com或者国内的新浪微博,人人网等,在各种技术社区,技术大会上都在分享自己的feed架构,也就是推拉模式(timyang上次也分享了新浪微薄的模式)。下面我们就微博的feed推拉(push,pull)模式做一下探讨,并提出新的时间分区拉模式。

      众所周知,在微博中,当你发表一篇微博,那么所有关注你的followers(粉丝)都会在一定的时间内收到你的微薄,这有点像群发一封邮件,所有的抄送者都会在一定的时间内收到。到这里,你可能觉得没有什么难度。我们看下下面的截图:

     

       图一:新浪微博姚晨

         图二:twitter上冯大辉

     新浪微博的姚晨粉丝有2594751,她发表任何一篇微博,都需要2594751个粉丝在一定的时间内收到,twitter的冯大辉发表一篇的话,需要19868个followers收到。

     相反,姚晨需要收到他关注的545个人的所有更新,冯大辉需要收到他关注的2525个人的所有更新。到这里,你是不是感觉到有那么一点点小挑战呢?

     下面我们看下微博一般的整体结构图:

      

                 图三:微博整体结构

       图中展示了微博的整体数据流程,先了解下整体的数据结构,没有涉及到followers等的推拉模式处理。下面我们再看下推模式(push):

          图四:推模式结构

   推模式需要把一篇微博推送给所有关注他的人(推给所有的粉丝),比如姚晨,我们就需要推送给2594751个用户的feeds表中。当然,feeds表可以很好的进行sharding,存储也都是一些数字型的字段,存储空间可能不是很大,用户在查询自己关注的所有人的feed时,速度快,性能非常高,但是推送量会非常大,姚晨发表一篇,就会产生200多万条数据。试想,一个大量用户的微薄系统通过使用推模式,是不是会产生非常惊人的数据呢?

    下面看下拉模式(pull)

            图五:拉模式

     拉模式只需要用户发表微博时,存储一条微博数据到feeds表中(feeds表可以是一个临时表,只保存近期可接受范围的数据).用户每次查询feed时都会去查询feeds表。比如姚晨打开自己的微薄首页,就产生:SELECT id FROM feeds where uid in(following uid list) ORDER BY id DESC LIMIT n(查询最新的n条),缓存到memcached

uidlist=>{data:id list,timeline:上次查询出来的最新的一条数据的时间}

再次刷新:SELECT id FROM feeds where uid in(following uid list) AND timeline>(memcached存储的上次的timeline) ORDER BY id DESC LIMIT n

 

    这种模式实现起来也是比较简单和容易的,只是在查询的时候需要多考虑下缓存的结构。但是feeds表会产生很大的压力,怎么说feeds表也要保存最近十天半个月的数据吧,对于一个大点的系统,这会产生比较大的数据,如果following的人数比较多,数据库的压力就会非常大。而且一般在线的用户,客户端都会定期扫描,又会增加很大的压力,这在查询性能上没有推模式的效率高。

     下面我们在对拉模式做一下改进优化

     

           图五:拉模式(pull)-改进(时间分区拉模式)

           拉模式的改进主要是在feeds的存储上,使用按照时间进行分区存储。分为最近时间段(比如最近一个小时),近期的,比较长时期等等。我们再来看下查询的流程,比如姚晨登陆微博首页,假设缓存中没有任何数据,那么我们可以查询比较长时期的feeds表,然后进入缓存。下一次查询,通过查询缓存中的数据的timeline,如果timeline还在最近一个小时内,那么只需要查询最近一个小时的数据的feed表,最近一个小时的feeds表比图四的feeds表可要小很多,查询起来速度肯定快几个数量级了。

          改进模式的重点在于feeds的时间分区存储,根据上次查询的timeline来决定查询应该落在那个表。一般情况下,经常在线的用户,频繁使用的客户端扫描操作,经常登录的用户,都会落在最近的feeds表区间,查询都是比较高效的。只有那些十天,半个月才登录一次的用户需要去查询比较长时间的feeds大表,一旦查询过了,就又会落在最近时间区域,所以效率也是非常高的。

         关于时间的分区,需要根据数据量,用户访问特点进行一个合理的切分。如果数据发表量非常大,可以进行更多的分区。

        上面介绍的推模式和拉模式都有各自的特点,个人觉得时间分区拉模式弥补了图四的拉模式的很大的不足,是一个成本比较低廉的解决方案。当然,时间分区拉模式也可以结合推模式,根据某些特点来增加系统的性能。

        后记:本文的目的是介绍时间分区拉模式,本人对新浪微博和twitter等的推拉模式的细节并不清楚。

如何联系我:【万里虎】www.bravetiger.cn 【QQ】3396726884 (咨询问题100元起,帮助解决问题500元起) 【博客】http://www.cnblogs.com/kenshinobiy/
目录
相关文章
|
16天前
|
人工智能 前端开发 编译器
【AI系统】LLVM 架构设计和原理
本文介绍了LLVM的诞生背景及其与GCC的区别,重点阐述了LLVM的架构特点,包括其组件独立性、中间表示(IR)的优势及整体架构。通过Clang+LLVM的实际编译案例,展示了从C代码到可执行文件的全过程,突显了LLVM在编译器领域的创新与优势。
37 3
|
6天前
|
监控 安全 API
使用PaliGemma2构建多模态目标检测系统:从架构设计到性能优化的技术实践指南
本文详细介绍了PaliGemma2模型的微调流程及其在目标检测任务中的应用。PaliGemma2通过整合SigLIP-So400m视觉编码器与Gemma 2系列语言模型,实现了多模态数据的高效处理。文章涵盖了开发环境构建、数据集预处理、模型初始化与配置、数据加载系统实现、模型微调、推理与评估系统以及性能分析与优化策略等内容。特别强调了计算资源优化、训练过程监控和自动化优化流程的重要性,为机器学习工程师和研究人员提供了系统化的技术方案。
115 77
使用PaliGemma2构建多模态目标检测系统:从架构设计到性能优化的技术实践指南
|
2天前
|
NoSQL 关系型数据库 MySQL
《docker高级篇(大厂进阶):4.Docker网络》包括:是什么、常用基本命令、能干嘛、网络模式、docker平台架构图解
《docker高级篇(大厂进阶):4.Docker网络》包括:是什么、常用基本命令、能干嘛、网络模式、docker平台架构图解
81 56
《docker高级篇(大厂进阶):4.Docker网络》包括:是什么、常用基本命令、能干嘛、网络模式、docker平台架构图解
|
11天前
|
机器学习/深度学习 人工智能 并行计算
【AI系统】Kernel 层架构
推理引擎的Kernel层负责执行底层数学运算,如矩阵乘法、卷积等,直接影响推理速度与效率。它与Runtime层紧密配合,通过算法优化、内存布局调整、汇编优化及调度优化等手段,实现高性能计算。Kernel层针对不同硬件(如CPU、GPU)进行特定优化,支持NEON、AVX、CUDA等技术,确保在多种平台上高效运行。
63 32
|
11天前
|
存储 机器学习/深度学习 人工智能
【AI系统】计算图优化架构
本文介绍了推理引擎转换中的图优化模块,涵盖算子融合、布局转换、算子替换及内存优化等技术,旨在提升模型推理效率。计算图优化技术通过减少计算冗余、提高计算效率和减少内存占用,显著改善模型在资源受限设备上的运行表现。文中详细探讨了离线优化模块面临的挑战及解决方案,包括结构冗余、精度冗余、算法冗余和读写冗余的处理方法。此外,文章还介绍了ONNX Runtime的图优化机制及其在实际应用中的实现,展示了如何通过图优化提高模型推理性能的具体示例。
40 4
【AI系统】计算图优化架构
|
13天前
|
存储 人工智能 监控
【AI系统】推理系统架构
本文深入探讨了AI推理系统架构,特别是以NVIDIA Triton Inference Server为核心,涵盖推理、部署、服务化三大环节。Triton通过高性能、可扩展、多框架支持等特点,提供了一站式的模型服务解决方案。文章还介绍了模型预编排、推理引擎、返回与监控等功能,以及自定义Backend开发和模型生命周期管理的最佳实践,如金丝雀发布和回滚策略,旨在帮助构建高效、可靠的AI应用。
74 15
|
17天前
|
人工智能 并行计算 程序员
【AI系统】SIMD & SIMT 与芯片架构
本文深入解析了SIMD(单指令多数据)与SIMT(单指令多线程)的计算本质及其在AI芯片中的应用,特别是NVIDIA CUDA如何实现这两种计算模式。SIMD通过单指令对多个数据进行操作,提高数据并行处理能力;而SIMT则在GPU上实现了多线程并行,每个线程独立执行相同指令,增强了灵活性和性能。文章详细探讨了两者的硬件结构、编程模型及硬件执行模型的区别与联系,为理解现代AI计算架构提供了理论基础。
57 12
存储 人工智能 自然语言处理
45 6
|
13天前
|
机器学习/深度学习 人工智能 API
【AI系统】昇腾异构计算架构 CANN
本文介绍了昇腾 AI 异构计算架构 CANN,涵盖硬件层面的达·芬奇架构和软件层面的全栈支持,旨在提供高性能神经网络计算所需的硬件基础和软件环境。通过多层级架构,CANN 实现了高效的 AI 应用开发与性能优化,支持多种主流 AI 框架,并提供丰富的开发工具和接口,助力开发者快速构建和优化神经网络模型。
34 1
|
16天前
|
机器学习/深度学习 人工智能 前端开发
【AI系统】AI 编译器基本架构
本文承接前文关于AI编译器发展的三个阶段,深入探讨通用AI编译器架构。文章首先回顾现有AI编译器架构,如PyTorch的转换流程及优化策略,然后介绍理想化的通用AI编译器架构,涵盖从前端接收多框架模型输入到后端生成特定硬件代码的全过程。重点解析了编译器的中间表达IR、前端与后端优化技术,以及现有AI编译器全栈产品的层次结构,为读者提供了全面的技术概览。
21 2