Feed系统架构资料收集(转)
2023-09-14 08:58:46 时间
add by zhj:有些链接已经失效,后续会修改。
原文:http://blog.csdn.net/zhangzhaokun/article/details/7834797
微博feed系统的push和pull模式和时间分区拉模式架构探讨
关于如何构建一个微博型广播最后这篇文章写得很不错的,也基本讲清楚了Feed系统的方方面面的考虑了,基本涉及到了一个Feed系统从小发展到大的全过程了!还没有完全
领会到它为用Cassandra替换Redis的理由,或者他还是考虑把Casandra的作为半缓存的结构来替换的,加大Cassandr的内存,可以
缓存大量的热数据,当然它的好处是冷热数据都可以完美的持久化,但是数据的一致性处理起来有些麻烦,毫无疑问他会是采用R+W>N的模式,但是无论
写多份还是读多份都是有些难于取舍的,Feed系统的写入量本来就很大,如果写入多份的话会大大降低写入的性能,另外,存在Feed的系统,无一例外的是
Feed都会是全系统的核心,提高读的性能会大大提高用户的体验,如果读取的时候读多份数据会相对降低性能,到底取舍哪一个呢?我这里光是凭空想象,无法
取舍,具体还可以看性能测试来说法,如果有同学做过这方面的压测,还望留言告知下!
腾讯微博主要使用拉模型,只有未读的微博数是使用推得模式实现的!拉模型的问题在于一个人跟随了几百或者上千的人的时候,去看关注的人所发的消
息要进行多个层次的Map/Reduce才能得到结果,需要非常高效的获取最新Feed的方式以及快速的聚合算法,只用Memcache\Redis之类
的从性能上是比较难于实现的,需要从数据层面或者是缓存的层面都进行聚合,再在应用层面进行聚合,技术难度比较大!这个模式属于知易行难,绝大多数公司不
具备构建基础设施的能力!
新浪微博使用推拉结合的方式,大号不推送,小号则推送,看Feeds的时候,需要将推过来的Feeds索引数据与关注的大号的Feed进行聚合,小小的牺牲下拉的性能一下子就将大号的推送问题解决掉了!
对于稍微小些的网站,比如Pinterest和花瓣都使用推的方式来实现,PInterest的直接在Redis中保存500个最新的索引信息,使 用Python脚本定时来扫描,保证缓存的索引信息始终只保存最新的500个,老的信息则直接丢弃掉,花瓣则将老索引存储到LevelDBA中去了!
Pinterest网站的内容信息缓存在memcache中,关系信息则缓存到Redis中,持久化方式保存!对于那种大号的粉丝,亦或是关注的人 数太多则需要将关系数据拆分之后再缓存起来,对于动态变化的部分则需要独立存放,在使用的时候需要将两部分数据聚合,在可变部分达到一定长度的时候,需要 与不变的部分进行合并!
当然推送的时候,所有的网站都使用异步的方式来实现!
相关文章
- 2018年系统架构设计师上午真题
- 【开源】手把手教你写支持RMT架构的P4语言后端编译器!
- 一文让你深度了解Linux内核架构和工作原理
- 金融数据中心网络架构与技术
- 个人工作管理系统开发手记4:重新思考系统架构
- 国产开源基于BS架构的中小医院信息系统
- 软考系统架构设计师(三):操作系统
- DDD实战之五:战略设计之上下文映射和系统分层架构
- 马蜂窝如何利用 APISIX 网关实现微服务架构升级
- Only Train Once:微软、浙大等研究者提出剪枝框架OTO,无需微调即可获得轻量级架构
- Mysql Server系统架构介绍详解数据库
- 电竞大数据平台 FunData 的系统架构演进详解大数据
- 革新型安全:ESET Linux系统架构(esetlinux)
- Redis主从部署:搭建可靠高并发架构(redis主从部署)
- 架构Redis系统的架构: 实现高性能和高并发(redis高并发系统)
- MySQL 主从热备模式架构: 实现高可用数据库(mysql主从热备)
- 秒定时任务架构Oracle 14400秒定时任务(oracle14400)
- 系统Linux分支系统:开放源码架构(linux的分支)
- Red Hat Linux严重Bug将影响基于Haswell架构的服务器
- MySQL双主架构:实现多从同步(mysql双主多从)
- PHP与MSSQL架构构建的网站系统实践(php mssql 架构)
- AMD安装MySQL突破性技术推动数据库架构创新(amd安装mysql)
- 基于SSM架构实现Redis缓存优化提升系统性能(ssm redis缓存)
- Oracle高可用架构之Database Gateway管理(oracle dg管理)