架构

无挑战,不工作之 -系统分析师招聘答案

caoz考核,一看意识,二看思路,三看方法

前言 : 其实考试这种东西本身是不平等的,因为出题人肯定有优势,所以有些人水平比caoz高很多,答caoz的题目也只能得到七八十分而已,如果换过来出 题,caoz可能及格都是问题,而且这些题目其实更适合面试进行,因为可以层层递进剖析问题,从一个大问题引申提出更多子问题,这是caoz面试常用的习 惯,很多趾高气扬的人进来,灰头土脸的出去,当然,还是那句话,考核本身是不平等的。也许您答的和caoz期望的相差不少,但是不代表caoz比你水平 高。

回过头来说,意识是第一位的

1:数据链接过多,这是最常见的问题,但是其实也是这里最重点的问题

子问题1,为什么提到步骤,很少有人告诉我,第一步是尽快临时恢复线上应用,这就是意识!

恢复线上应用有几种场景,最简单的是show processlist 然后kill掉阻塞的processlist,其次是重启数据库,如果数据库重启后又会快速堵塞,那么要尽快从前端代码中找到阻塞点,临时屏蔽掉某些导致 阻塞的功能,以及增加同时链接参数,为了保证在你彻底解决这个问题的这段时间里,你的前面网页是可以顺利打开的。

大型高性能网站的十项规则

在我们公司 ChinaNetCloud,见 过多种不同类型的网站和系统,有好也有差。其中有些系统拥有良好的服务器/网络架构,并且进行了合理的调整和监控 ;然而一般的系统都会有安全和性能上的 问题,不能良好运行,也无法变得更流行。

在中国, 开源的LAMP栈是最流行的网络架构,它使用PHP开发,运行在Apache服务器上,以MySQL作为数据库,所有这些都运行在Linux上。它是个可 靠的平台,运行良好,是现在全球最 流行的Internet系统架构。然而,我们很难对其规模进行正确的扩展并保持安全性,因为每个应用层都有其自身的问题、缺陷和最佳实践。我们的工作就是 帮助企业用最低的操作成本来创建并运行高性能的、可伸缩的、安全的系统,因此对于这类问题我们有很丰富的经验。

百万级高并发网站MySQL应用攻略

百万级高并发网站MySQL应用攻略

作者: 未知

  在长时间的网站开发过程中,能作一个百万IP的网站对我来说真是一个新的挑战,由于本人的水平有限,所以一直就职于一个小公司,在这里也只是抱 着重在参与的想法。在以后我所讲述到的内容知识点上如有不适之处请大家多多批评指教。

  在一开始接触PHP接触MYSQL的时候就听不少人说:“Mysql就跑跑一天几十万IP的小站还可以,要是几百万IP就不行了”,原话不记得 了,大体就是这个意思。一直也没有好的机会去验证这个说法,一是从没有接手过这么大流量的网站,二是平时工作也比较忙,懒得去管这些,反正现在用不着,抱 着这个想法把这个问题一直留到了最近,才把这个问题搞明白。

  就在前几天公司旗下一网站(由于这是公司的商业内容我就不说是那个网站了,免得有兄弟说是AD)以下简称A站,这A站在年后流量猛增从一天的七 八十万猛跑到了好几百万的IP,一天下来接近一千万的Pv让整个服务器在高压下超负荷的工作着,时不时的服务就出现当机。

  最首先反映出情况的是数据统计,一天下来一个数据也没有统计上,原来是mysql挂了。

  本文就围绕这个问题来讲讲我们公司几个技术人员的解决方案。

nginx图片服务器的架构方案

图片服务通常数据容量较大,而且访问也频繁,鉴于此,图片服务就会有两种问题,一是存储问题,二是访问量问题。
存储问题就是硬盘容量问题,花钱买硬盘就可以了,看似简单,但着实也是最苦的问题。按目前探索来看,最好的方式是:在任何时刻遇到硬盘空间不够时,买颗硬盘插上,最多改改配置,就能立刻利用;另外,硬盘要能充分利用,不然图片存储量大再加上备份,很恐怖,最好是每颗硬盘都用上100%的空间。
访问量也是个大问题,如果服务不允许防盗链,那么访问量会引起带宽、服务器压力等问题,有钱的话直接扔CDN,没钱或者有更多的钱,就自己做吧。根据垣古不变的真理“越老的图,访问量也相对较少”这一点,分成两大部分,一边处理最新的图片,一边处理老旧的图片。最新的图片访问量大,但存储量较少;老图片访问量低,但存储量大。
大概分析完了,开始制定方案。

一、拟定一个存储目录规则:
在现有的/a/b/abcde.jpg这样的hash方式下多加一个日期的目录变成:/200810/16/a/b/abcde.jpg或者/2008 /10/16/a/b/abcde.jpg。按日期制定这个目录规则后,就可以按年月来拆机器了。

二、分机器,分硬盘

校内相册发展过程及核心技术分析爆料

第一章 相册瓶颈所在
1.用户上传海量数据是一个头疼的事情,每天上千万的数量,又因为互联网的特殊性,会出现高峰期和低潮期,以每天 10,000,000张图片来计算,高的时候,每秒上传有可能会在上千张,而低的时候可忽略不计。
2.因为产品不同,往往上传一张原始的照片会需要压缩成四五张不同大小的图片。这个压缩过程相当消费cpu。
相信有同一问题的应该有:QQ空间,网易相册,新浪博客,flikr等等。

第二章 校内相册的发展和改革
第一阶段,原始社会。
在第一阶段,我们过着刀耕火种的生活,java代码上传+jmagick压缩,其结果就是,再多的服务器,也搞不定越来越多的访问量。

第二阶段,具有封建主义气息的资本主义社会。
这一阶段,我们痛定思痛啦,服务常常挂啊,怎么办?怎么办,当然是分布式处理,分 析下原因,原来挂是因为cpu太高,用户上传一图压成四图,太费劲了。干脆传到其他cpu多的机器去。
说时迟那时快,我们挽起袖子,一个分布式的上传压缩过程就出来了。。。
所使用的方法:

通过网页源代码看“饭否”的网站架构

饭否是一个我最近比较喜欢的应用,饭否网站的用户体验的确感觉比较用心,今天简单分析了一下网站的网页代码,感觉网页的布局十分清晰,Html也十分的干净,通过网页的源代码大概简单体会了一下网站的架构,网站的主要域名如下:
fanfou.com、wap.fanfou.com、static.fanfou.com、dev.fanfou.com、help.fanfou.com、avatar.fanfou.com、api.fanfou.com。

fanfou.com是网站的主域名,网站的前端应用主要集中在这个域名所在服务器上,wap.fanfou.com主要负责wap端的应用,static.fanfou.com为网站静态资源存放的服务器,主站用到的静态图片、js脚本、样式表、图标等资源都放到这个服务器上,dev.fanfou.com为后台提供开发的站点(使用了WordPress 2.2.3进行站点的搭建),同时也提供网站的站务日志等信息,help.fanfou.com为网站的帮助信息对应的服务器,avatar.fanfou.com为用户缩略图存储的站点,api.fanfou.com站点用来提供二次开发接口。

网站架构收集

http://www.hiadmin.com/网站架构收集

DBA notes上果然好东西很多
许多大型(只是访问量,而不是公司规模)的web 2.0的网站架构
上面都有
现在收集整理一下有关网站架构的资料,其中许多来自DBA notes
这种资料.向来可遇不可求啊

WikiPedia 技术架构学习分享
http://www.dbanotes.net/opensource/wikipedia_arch.html

YouTube 的架构扩展
http://www.dbanotes.net/opensource/youtube_web_arch.html

Internet Archive 的海量存储浅析
http://www.dbanotes.net/database/internet_archive_storage.html

LinkedIn 架构笔记
http://www.dbanotes.net/arch/linkedin.html

QQ游戏百万人同时在线服务器架构实现

    QQ游戏于前几日终于突破了百万人同时在线的关口,向着更为远大的目标迈进,这让其它众多传统的棋牌休闲游戏平台黯然失色,相比之下,联众似乎已经根本不 是QQ的对手,因为QQ除了这100万的游戏在线人数外,它还拥有3亿多的注册量(当然很多是重复注册的)以及QQ聊天软件900万的同时在线率,我们已 经可以预见未来由QQ构建起来的强大棋牌休闲游戏帝国。

那么,在技术上,QQ游戏到底是如何实现百万人同时在线并保持游戏高效率的呢?

同步内容