![](https://csdnimg.cn/release/download_crawler_static/86343246/bg3.jpg)
技术基本上不会出错。
另外基础服务 DB 冷热分离多维度拆分,在微博里面我们是按照时间拆分的,但是一个
大型的系统里面有很多业务需要有不同的考虑。比如说私信这个就不能按照时间来拆分,这
个按照 UID 来拆分可能更简单。然后我们突出存储还做了一个去中心化,就是用户上传图片
的速度会极大的提高,另外察看其他用户的图片速度也会极大的提高。另外是动态内容支持
多 IDC 同时更新,这个是在国内比较新颖的。
下面给大家介绍一下新浪微博怎么样打造一个高性能架构。到目前为止有五千万用户使
用新浪微博,最高发表 3000 条以上每秒,然后一个明星用户发表的话,会被几百万用户同
时读到。这些问题的本质是我们架构需要考虑高访问量、海量数据的情况下三个问题。易于
扩展、低延迟、高可用和异地分布。我们每天有数十亿次外部网页以及 API 接口的需求,我
们知道微博的特点是用户请求是无法 cache 的。因此面对这个需求我们怎么样扩展?几点思
路。第一我们的模块设计上要去状态,我们任意一个单元可以支持任意节点。另外是去中心
化,避免单点及瓶颈。另外是可线性扩展。最后一个是减少模块。
我们要做一个高性能的系统,要具备一个低延迟、高实时性,微博要做到高实时性这是
核心的价值,实时性的核心就是让数据离 CPU 最近(me:就是使得数据离用户最近),避免
磁盘的 IO。我们看淘宝核心系统专家余锋说过的一句话“CPU 访问 L1 就像从书桌拿一本书,
L2 是从书架拿一本书,L3 是从客厅桌子上拿一本书,访问主存就像骑车去社区图书馆拿一
书”。我们微博如果要做到非常实时的话,我们就需要把数据尽量离 CPU 节点最近。所以我
们看一下 cache 设计里面怎么达到这个目标。首先 INBOX,这个数据我们需要放在一个最快
的地方,因为用户随时访问。OutBOX 里面的最近发表就是 L1cache,还有一个是中期的,这
个因为访问少一点,它可以被踢。最后一部分内容体有三部分。L0 是本地的,我们需要把
一些经常访问的,比如说明星发表微博的内容体本地化,因为它被访问的概率非常大。然后
L1 里面存放着最近发表的,还有一个是中期的。我们通常用 L2 就可以了,L1 我们可以理解
成它就是一个存储。
一个好的架构还需要具备高可用性。我们看一下业界的指标,S3 是 99.9%,EC2 是
99.5%,我们另外一个同行 Face book 在这方面它是没有承诺的,就是接口可用写。微博平
台目前承诺的是 99.95%,就是说一天 365 天故障率应该小于 9 个小时。这个怎么达到?第
一我们要做容量规划,第二个是要做好监控以及入口的管理,就是说有些服务如果访问量过
了的话,我们要有一个开关可以拦住他(me:消息队列)。我们通过这个图表可以清楚的看
到,比如说我们要做 L1 的 cache,我们剩余空间有多少,比如说 80%,就说明这个数据有可
能会丢失,有可能会对我们的系统造成影响。
另外一个层面就是接口监控,我们目前有多个维度的接口监控,包括访问错误失败率。
然后要做架构,给大家一个很重要的经验分享,就是说监控的指标尽量量化(me:什么都最
好量化,google 的任何工作都需要量化的分析)。比如说他延迟 30 秒是小问题,如果是延迟
10 分钟我们就要立即采取措施了,就是所有可以量化的指标都要量化。
然后我们看监控怎么样更好的做?我们看亚马逊的 VP 说过的一句话,就是说监控系统
确实特别好,可以立即告诉我们哪里有故障,但是有 20%的概率我们人是会出错的。所以我
们一个大型系统就应该要为自动化设计,就是说尽可能的将一些运作自动化。比如说发布安
装、服务、启用、停止。我们再看另外一句,Google 的工程师是怎么做的。他是这么做的,
比如说第一周是处理线上的业务,这一周他处理了很多事情,处理了很多系统的情况,剩下
的系统问题是不需要他做的,他只要把这一周碰到的情况用程序的方法来解决,下次再碰到
这种情况很简单的一个按钮就可以处理了。我们目前也在向自动化这方面努力,就是我们的
工具在持续增加。
另外一个异地分布,在国内网络环境下,比如说 IDC 灾难(me:容灾措施,多机部署,