前几天的上线功能bug,由于评论数量过多,未异步加载,导致数据丢失,原因是新老功能迁移时未做异步加载,就此功能找一下微博类评论等功能的架构设计思考,还有其他产品,社区,论坛,博客等。
微博曾流传可支撑8位明星同时出轨,但大事件屡屡挂掉,周杰伦出新歌,充值点播渠道挂掉,2019年财报微博日平均活跃用户2.16亿,面对亿级平台该如何设计架构?
难点一:大V发布微博,大事件下同时可达百万,千万用户接受到订阅消息,微博需要对此条信息进行计数,评论,点赞进行过滤,转到用户的各个平台。
难点二:数万用户同时访问,系统单点故障导致的雪崩问题,访问速度变慢,甚至单节点挂掉,导致惊群效应。
难点三:评论的套娃现象,以及实时回复展示问题,一条热评下会有数量回复,以及层级下的回复,且能实时回复并展示。
以上是个人觉得难点所在,平时的业务也可能出现类似现象,但用户量是个问题,达不到峰值访问,就测不出很多隐藏问题。
没有实战经验的高并发都是纸上谈兵!
当看过新浪架构师开发者大会实记后会有所感悟,文章就不大篇幅复制了,贴下链接。
https://blog.csdn.net/guodongbuding0423/article/details/83765669?utm_medium=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.channel_param&depth_1-utm_source=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.channel_param
第一:数据拆分,异步推送
第二:静态内容CDN加速,允许单点失败,服务分解
第三:安全监控,Master/Slave
1、读扩散还是写扩散?
inbox: 收件箱,你收到的消息,即你所关注的人发布的消息。outbox: 发件箱,你发布的消息。
写扩散(Push)
该方式为每个用户维护一个订阅列表,记录该用户订阅的消息索引(一般为消息ID、类型、发表时间等一些元数据)。每当用户发布消息时,都会去更新其follower的订阅列表。优点:读很轻。初始化时仅需要读取自己的inbox即可。缺点:写很重。每发布一个消息,会导致大量的写操作。注:一般来说,用户发布消息,并不会更新所有followers的订阅列表,仅更新在线followers即可。
读扩散(Pull)
该方式为每个用户维护一个发送列表,记录该用户所有发表过的消息索引。优点:写很轻,节省空间。用户每发布一条消息,仅需更新自己的outbox。缺点:读操作很重,计算量大。假设你收听了1k用户,则初始化时,需要从1k个用户的outbox拉取消息,然后计算获得最新的n条消息。
混合模式(Push+Pull)
该方式既为读写扩散的结合,根据用户followers的数量来决定是读扩散还是写扩散。例如followers大于1k的,则使用读扩散,否则使用写扩散。
从目前现在网上的一些资料来看,Twitter是写扩散,腾讯微薄是读扩散,新浪微薄则是二者结合。
2、关于Cache
对于一个千万级甚至亿级用户的大型网站来说,合理使用Cache至关重要。
一个用户的核心数据由如下几个部分组成:inbox,www.laiyuefeng.com outbox,关系链,消息内容。
inbox:主要缓存消息索引,仅为在线用户缓存,从Timyang的PPT来看,新浪微博估计是使用redis的list或set实现。
outbox:缓存一定数量(例如200)条最近发表的消息。
关系链:following相对于followers来说,缓存容易些,follower加载开销比较大,例如刘翔在腾讯微博的听众超过1600万。
消息内容:按内容年龄缓存;一般需要多份支持容灾;需要缓存xml,json,rss,atom等多种格式的缓存以供API使用。
以Twitter为例,其将Cache分为四类:www.jintianxuesha.com Vector Cache,Row Cache,Page Cache,Fragment Cache,均使用memcached实现。其中:
Vector Cache主要缓存用户的inbox以及outbox索引,其命中率高达99%;
Row Cache主要缓存用户关系链数据,以及Tweets内容,命中率为95%;
Fragment Cache缓存Tweet的xml,json,rss,atom四种格式数据,以供API使用,命中率为95%;
Page Cache主要原来缓存那些高人气用户的个人主页,命中率仅为40%。
下图为TwitterCache架构图:
Twitter为啥要为API通道设置Fragment www.baihuayl7.cn Cache和Page Cahce呢?其原因是Twitter的80%流量来自API。
下面以新浪微博介绍一下Cache流程:
消息发布流程:
更新自己的outbox
加载followers列表
更新followers inbox
获取首页流程:
检查inbox www.chuancenpt.com cache是否可用
获取关注列表
聚合内容,获得消息索引
根据索引,返回最终聚合的消息内容
3、关于存储
目前Twitter和新浪的落地存储,都是使用MySQL。而腾讯微博则使用采用SSD+大文件存储(每次写操作都是append操作,写操作可以先用内存缓存,达到适当大小合并,尽量减少随机写)。其他细节因不清楚或不方便透露,不做细述。
4、关于洪峰处理。
一般用异步队列处理方式。消息队列产品有:Kestrel(twitter使用Scala实现),RabbitMQ(使用Erlang实现),MemcacheQ。
Twitter 09年时,用户的平均followers数量为126个。按照每秒400消息发布数算,那每秒就需要推送126*400=50400条消息出去。为了削峰,Twitter自己用Scala实现了一个分布式消息队列Kestrel,其代码仅为1200行,运行在3台机器上,其使用memcached协议,其Server之间无共享状态,且全内存。新浪使用的是MemcacheQ
转自:http://www.jucaiyle.cn pananq.com/index.php/2011/05/21/%E5%BE%AE%E8%96%84%E5%90%8E%E5%8F%B0%E6%9E%B6%E6%9E%84%E6%B5%85%E6%9E%90/
目前只能搜索与个平台发布会以及内容分析,暂时未找到先关技术贴,通过架构分析了解下解决方案。