新浪微博平台技术架构经验(阅读笔记)

原创
2014/08/13 00:15
阅读数 3.5K

1、总体架构设计原则

  • 去中心化

  • 异步化

  • 模块无状态化

  • 拆分(数据拆分、服务拆分、部署拆分...)

  • 容量规划、监控与工具自动化

  • 服务化

  • 针对具体业务做特殊优化

  • ...


2、遇到的一些问题

  • 单点故障

  • 微博发表慢

  • 微博数据量太大

  • 大V用户发微博,推送给粉丝的时间延迟(指某些粉丝看到大V发表的微博的时间延迟)无法忍受

  • 如何快速定位用户发表的某一页的微博?(微博数据假设已按月拆分)

  • 复杂的关注关系(我的粉丝、我关注的、互粉、我关注的人也关注、共同关注等等)如何设计?

  • 未读信息数如何设计?

  • ...


3、上面问题的解决方案

3.1、单点故障

单点故障概念太宽泛,可以包括数据库节点单点、服务节点单点、Web服务器单点等,新浪微博为防止单点,主要采用MPSS(Multiple Port Single Server)技术,每个服务器上部多个端口,一个服务单元可以分布在三台机器上,以及去中心化技术:比如避免Master/Slave模式,因为Master节点存在单点故障问题

3.2、微博发表慢

采用异步化解决微博发表慢问题

3.3、微博数据量太大

数据量大,自然而然可以通过数据拆分(或者Sharding)来解决,关键在于如何拆。主要包含如下:

  • 按用户ID拆,比如微博用户账户数据

  • 可以按时间拆分,比如用户发表的微博数据

  • 可以按业务拆,比如用户数据单独提出到一个数据库集群,微博数据提出到另外一个数据库集群

  • 可以按冷热数据拆分

  • 可以按哈希后的结果进行拆分,这种相当于又做了一次索引,能够加快访问速度

具体而言,是将新写入的微博数据放入Cache中,然后有一个定时任务轮询淘汰一段时间之前的缓存数据,并且自动将冷数据写入硬盘。

3.4、大V用户发微博时推送数据的时间延迟问题

业务上将用户划分为热用户(比如最近一天内登陆过的用户是热用户)和冷用户,大V用户发表一条微博后,只推送给粉丝中的热用户。粉丝中的冷用户等他再次登录微博时自己去拉取。这是一种典型的从业务角度进行性能优化的例子。

3.5、如何快速定位用户发表的某一页微博?(微博数据假设已按月拆分)

将用户每个月发表微博的条数、每月发表微博的最小ID和最大ID都记录下来,这样即可快速定位到分页数据(原理是根据该用户发表微博的最小ID以及每个月发表微博数、页大小计算)。其实相当于多建了一级索引。

3.6、复杂的关注关系如何设计?

新浪微博大量使用Redis,主要利用Redis的高性能、开源和丰富数据结构,关注关系同样用Redis来存储(主要是Redis Hash结构)。按多维度构建索引。

3.7、未读信息数如何设计?

基于偏移,记录用户已读取的消息ID(比如100)和系统该用户的最新ID(比如105),那么该用户未读信息数就是5。新浪微博开发了一个计数器服务来支持一些业务数据的计数。


4、一些架构设计原则说明

4.1、模块无状态

模块无状态最主要的是为了能够支持线性扩展或者水平扩展。

4.2、数据分级存储

访问越频繁的数据要放在用户越容易取到的地方。比如大V用户的微博数据直接放在本地缓存。用户自己最近发表的微博数据放L1 Cache。用户发表的历史微博数据按照发表时间分表放L2 Cache和数据库。等等。

4.3、服务化

按照业务数据内聚性拆分基础服务,比如微博数据基础服务、用户数据基础服务,这些基础服务构成服务层,服务层与分布式存储、分布式缓存、消息系统等中间件打交道,拆分服务除了带来复用性,还能避免业务集中瘫痪,也有利于针对单个服务进行升级;

服务层上面是应用层,应用层通过组合使用不同的基础服务来实现功能,它们也一般不需要直接与那些中间件打交道;应用层再上去就是API接口层,它们主要提供给第三方开发者使用。

4.4、容量规划、监控和工具自动化

这三个主要是运维层面来保障,是保证网站高可用性的前提。

容量规划比如根据业务数据增长量估算硬件资源消耗。

监控主要包括下面三方面:

  • 硬件资源监控:对CPU、IO、内存、网络带宽等硬件资源的监控

  • 业务接口监控:接口调用频率、接口调用成功比例等

工具自动化主要是因为人总会出错,所以尽量让一些任务通过工具进行自动化,从而也能大大减少重复繁杂的人力成本。

4.5、多机房数据复制问题

多机房数据复制问题主要包括数据延迟和数据一致性。一般有下面三种数据复制策略,新浪微博采用的第二种:

  • Master/Slave:单点风险,并且不同地区访问Master节点的延迟也不一样,不可接受

  • Multi-Master:多主节点,注意避免多个Master节点同时修改

  • Paxos算法:这个算法具体我不是很清楚(只在浏览网络博客时接触过),这种算法的最大缺点是延迟非常大

4.6、平台安全

主要划分为接口安全和内容安全,接口安全通过安全系统控制,内容安全通过权限系统控制。

安全系统包含两类安全处理措施:

  • 实时处理:根据发布微博频率、内容相似度、敏感词匹配等处理

  • 离线处理:离线分析处理


展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
9 收藏
0
分享
返回顶部
顶部