windows下安装ipython

Posted on

windows下安装ipython

分享到

百度分享

弧光守望者-itfanr

Google Reader QQ邮箱 鲜果 抓虾

订阅地址:

邮件订阅:

用户名:

密码:

找回密码

windows下安装ipython

分享到:更多0

2013-08-13 分类:Python1条评论63次浏览

看了好多博客和官方文档,感觉windows下安装ipython很复杂。后来发现其实很简单。

首先在python官网下载python installer。建议安装python 2.x版本,因为python 3.x版本和2.x版本不是一个体系,网上资料较少。安装后记得将python.exe所在目录设置为PATH路径。

然后下载ex_setup.py这个包管理工具,官网是https://pypi.python.org/pypi/ez_setup,但是建议下载这个。下载得到ez_setup.py文件。然后cd到该文件所在目录,然后执行: view source

1

python ez_setup.py

然后输入安装pip包管理工具

view source

1

easy_install pip

最后通过pip安装ipython:

view source

1

pip install ipython

在CMD命令行输入ipython

Enjoy it 。

如果是更新ipython,当然是先uninstall,然后install了 view source

1

pip uninstall ipython

建议下载console2 http://sourceforge.net/projects/console/ 替代windows自带的命令行。

Console is a Windows console window enhancement. Console features include: multiple tabs, text editor-like text selection, different background types, alpha and color-key transparency, configurable font, different window styles

参考:

[1]. http://www.v2ex.com/t/78747

本文作者:itfanr

分享到:更多0

继续查看有关 console2ez_setupipythonpippythonwindows 的文章

与本文相关的文章

  • 暂无相关文章!

喜欢取消喜欢

最新最早最热

moxie

ipython原来是这么个东西啊,我也装个试试

8月14日回复转发举报 1

社交帐号登录:

发布

弧光守望者-itfanr正在使用多说

  1. moxie on 2013 年 8 月 14 日 at 10:17 said:

ipython原来是这么个东西啊,我也装个试试

聚合文章

3+moxie

1+疯狂的眼球

1+summving

最新评论

© 2013 弧光守望者-itfanr 版权所有. Theme D7-Simple & 大前端. 由Wordpress内核驱动.

我在Oracle和IBM的面试经历讨论第3页

Posted on

我在Oracle和IBM的面试经历讨论第3页

您还未登录 ! 我的应用 登录 注册

JavaEye-最棒的软件开发交流社区

论坛首页招聘求职版职场话题

我在Oracle和IBM的面试经历

全部 企业点评 职场话题 求职经验 面试秘籍 招聘职位

myApps快速开发平台,配置即开发、所见即所得,节约85%工作量

« 上一页 1 2 3 下一页 » 浏览 5251 次 主题:我在Oracle和IBM的面试经历

精华帖 (0) :: 良好帖 (0) :: 隐藏帖 (0) 作者 正文 * tracyhuyan

  • 等级: 初级会员
  • tracyhuyan的博客
  • 文章: 64
  • 积分: 40
  • 来自: 深圳
  • 发表时间:16 小时前 最后修改:12 小时前

< > 猎头职位:LZ,英文面试的时候,用英语面技术?还是只是用英语谈话,非技术的东东 返回顶楼 回帖地址

0 0 请登录后投票 * yangstarfly

  • 等级: 四星会员
  • yangstarfly的博客
  • 文章: 88
  • 积分: 417
  • 来自: 北京
  • 发表时间:12 小时前

tracyhuyan 写道

LZ,英文面试的时候,用英语面技术?还是只是用英语谈话,非技术的东东 会用英语面技术,但不会问得太复杂 返回顶楼 回帖地址

0 0 请登录后投票 * onlylau

  • 等级: 初级会员
  • onlylau的博客
  • 文章: 4
  • 积分: 30
  • 来自: 江苏
  • 发表时间:11 小时前

这两个公司我都很向往呀,进哪个我都没意见,哈哈,关键是人家要不要我 看来我要好好练下我的内功的,加深下基础知识;还要再多加强下英语能力了,我的英文水平最多也就能看些简单的英文文章~ 顶个LZ,等你定下来了,希望能多提供些经验~ 返回顶楼 回帖地址

0 0 请登录后投票 * huhuanqadn

  • 等级: 一星会员
  • huhuanqadn的博客
  • 文章: 43
  • 积分: 110
  • 来自: 合肥
  • 发表时间:1 小时前

能进google最好,显然google已经不在中国了。 返回顶楼 回帖地址

0 0 请登录后投票 * Max_1106

  • 等级: 初级会员
  • Max_1106的博客
  • 文章: 210
  • 积分: 30
  • 来自: 深圳
  • 发表时间:1 小时前

这种大公司 技术+英语+学历 一个都不能少 返回顶楼 回帖地址

0 0 请登录后投票 * BloodSmith

  • 等级: 初级会员
  • BloodSmith的博客
  • 文章: 67
  • 积分: 30
  • 来自: 公安9课
  • 发表时间:36 分钟前

ibm还是很肥的啊 返回顶楼 回帖地址

0 0 请登录后投票 * 水痕2000

  • 等级: 初级会员
  • 水痕2000的博客
  • 文章: 63
  • 积分: 30
  • 来自: 杭州
  • 发表时间:27 分钟前

ibm band6是8.8k/月 属于养老工作. 一般只要生过孩子的女人(至少希望你5年不变动工作). 好像2000年band6就这个价格了..现在已经2010年了... band7需要3-4年左右 大概13k左右. 认识的同学两毕业同进的ibm的 成绩好的做的开发,成绩差的做的销售,起薪是一样的. 开发薪水基本没怎么变化,做销售的肥了好几圈了 返回顶楼 回帖地址

0 0 请登录后投票 * tracyhuyan

  • 等级: 初级会员
  • tracyhuyan的博客
  • 文章: 64
  • 积分: 40
  • 来自: 深圳
  • 发表时间:4 分钟前

yangstarfly 写道

tracyhuyan 写道

LZ,英文面试的时候,用英语面技术?还是只是用英语谈话,非技术的东东 会用英语面技术,但不会问得太复杂 哦,这样,thx 返回顶楼 回帖地址

0 0 请登录后投票

« 上一页 1 2 3 下一页 » 论坛首页招聘求职版职场话题 跳转论坛:Java编程和Java企业应用 Web前端技术 移动编程和手机应用开发 C/C++编程 Ruby编程 Python编程 PHP编程 Flash编程和RIA Microsoft .Net 综合技术 软件开发和项目管理 行业应用 入门讨论 招聘求职 海阔天空

© 2003-2010 JavaEye.com. 上海炯耐计算机软件有限公司版权所有 [ 沪ICP备05023328号 ]

多IDC的数据分布设计(一)

Posted on

多IDC的数据分布设计(一)

Tim[后端技术]

Tim's blog, 关于后端架构、互联网技术、分布式、大型网络应用、NoSQL、技术感悟等

Home | About | English version | 留言(Guestbook) | 订阅RSS Add to Google

Archive for the ‘分布式’ Category

Tuesday, Feb 2nd, 2010 by Tim | 13 Comments Filed under: 分布式 | Tags: 2PC, 3PC, consensus, paxos, Three-phase commit, Two-phase commit

上个月跟某个朋友谈及多IDC数据同时读写访问的问题(tweet),当时觉得有不少解决方案,但觉得思路还不够清晰。最近看了Google App Engine工程师Ryan Barrett介绍GAE后端数据服务的演讲稿Transactions Across Datacenters(视频),用Ryan的方法来分析这个问题后就豁然开朗。

按Ryan的方法,多IDC实现有以下几种思路。

一、Master/slave

这个是多机房数据访问最常用的方案,一般的需求用此方案即可。因此大家也经常提到“premature optimization is the root of all evil”。 优点:利用mysql replication即可实现,成熟稳定。 缺点:写操作存在单点故障,master坏掉之后slave不能写。另外slave的延迟也是个困扰人的小问题。

二、Multi-master

Multi-master指一个系统存在多个master, 每个master都具有read-write能力,需根据时间戳或业务逻辑合并版本。比如分布式版本管理系统git可以理解成multi-master模式。具备最终一致性。多版本数据修改可以借鉴Dynamo的vector clock等方法。

优点:解决了单点故障。 缺点:不易实现一致性,合并版本的逻辑复杂。

三、Two-phase commit(2PC)

Two-phase commit是一个比较简单的一致性算法。由于一致性算法通常用神话(如Paxos的The Part-Time Parliament论文)来比喻容易理解,下面也举个类似神话的例子。

某班要组织一个同学聚会,前提条件是所有参与者同意则活动举行,任意一人拒绝则活动取消。用2PC算法来执行过程如下

Phase 1

Prepare:组织者(coordinator)打电话给所有参与者(participant) ,同时告知参与者列表。 Proposal: 提出周六2pm-5pm举办活动。 Vote: participant需vote结果给coordinator:accept or reject。 Block: 如果accept, participant锁住周六2pm-5pm的时间,不再接受其他请求。

Phase 2

Commit: 如果所有参与者都同意,组织者coodinator通知所有参与者commit, 否则通知abort,participant解除锁定。

Failure 典型失败情况分析

Participant failure: 任一参与者无响应,coordinator直接执行abort Coordinator failure: Takeover: 如果participant一段时间没收到cooridnator确认(commit/abort),则认为coordinator不在了。这时候可自动成为Coordinator备份(watchdog) Query: watchdog根据phase 1接收的participant列表发起query Vote: 所有participant回复vote结果给watchdog, accept or reject Commit: 如果所有都同意,则commit, 否则abort。

优点:实现简单。 缺点:所有参与者需要阻塞(block),throughput低;无容错机制,一节点失败则整个事务失败。

四、Three-phase commit (3PC)

Three-phase commit是一个2PC的改进版。2PC有一些很明显的缺点,比如在coordinator做出commit决策并开始发送commit之后,某个participant突然crash,这时候没法abort transaction, 这时候集群内实际上就存在不一致的情况,crash恢复后的节点跟其他节点数据是不同的。因此3PC将2PC的commit的过程1分为2,分成preCommit及commit, 如图。 (图片来源:http://en.wikipedia.org/wiki/File:Three-phase_commit_diagram.png)

从图来看,cohorts(participant)收到preCommit之后,如果没收到commit, 默认也执行commit, 即图上的timeout cause commit。

如果coodinator发送了一半preCommit crash, watchdog接管之后通过query, 如果有任一节点收到commit, 或者全部节点收到preCommit, 则可继续commit, 否则abort。

优点:允许发生单点故障后继续达成一致。 缺点:网络分离问题,比如preCommit消息发送后突然两个机房断开,这时候coodinator所在机房会abort, 另外剩余replicas机房会commit。

五、Paxos

Google Chubby的作者Mike Burrows说过, “there is only one consensus protocol, and that’s Paxos” – all other approaches are just broken versions of Paxos. 意即“世上只有一种一致性算法,那就是Paxos”,所有其他一致性算法都是Paxos算法的不完整版。相比2PC/3PC, Paxos算法的改进

  • P1a. 每次Paxos实例执行都分配一个编号,编号需要递增,每个replica不接受比当前最大编号小的提案
  • P2. 一旦一个 value v 被replica通过,那么之后任何再批准的 value 必须是 v,即没有拜占庭将军(Byzantine)问题。拿上面请客的比喻来说,就是一个参与者一旦accept周六2pm-5pm的proposal, 就不能改变主意。以后不管谁来问都是accept这个value。
  • 一个proposal只需要多数派同意即可通过。因此比2PC/3PC更灵活,在一个2f+1个节点的集群中,允许有f个节点不可用。

另外Paxos还有很多约束的细节,特别是Google的chubby从工程实现的角度将Paxos的细节补充得非常完整。比如如何避免Byzantine问题,由于节点的持久存储可能会发生故障,Byzantine问题会导致Paxos算法P2约束失效。

以上几种方式原理比较如下

(图片来源:http://snarfed.org/space/transactions_across_datacenters_io.html)

后文会继续比较实践环境选取何种策略合适。

(PS: 写完后在Google Reader上发现本文跟王建硕最近发表的《关于两个机房的讨论》文章有点类似,特别是本文一、二方式。不过他的文章偏MySQL的实现,我的重点是一致性算法,大家可以有选择性的阅读。)

Wednesday, Sep 23rd, 2009 by Tim | 5 Comments Filed under: 分布式 | Tags: chubby, paxos, zookeeper

在分布式算法领域,有个非常重要的算法叫Paxos, 它的重要性有多高呢,Google的Chubby [1]中提到 all working protocols for asynchronous consensus we have so far encountered have Paxos at their core.

关于Paxos算法的详述在维基百科中有更多介绍,中文版介绍的是choose value的规则[2],英文版介绍的是Paxos 3 phase commit的流程[3],中文版不是从英文版翻译而是独立写的,所以非常具有互补性。Paxos算法是由Leslie Lamport提出的,他在Paxos Made Simple[4]中写道

The Paxos algorithm, when presented in plain English, is very simple.

当你研究了很长一段时间Paxos算法还是有点迷糊的时候,看到上面这句话可能会有点沮丧。但是公认的它的算法还是比较繁琐的,尤其是要用程序员严谨的思维将所有细节理清的时候,你的脑袋里更是会充满了问号。Leslie Lamport也是用了长达9年的时间来完善这个算法的理论。

实际上对于一般的开发人员,我们并不需要了解Paxos所有细节及如何实现,只需要知道Paxos是一个分布式选举算法就够了。本文主要介绍一下Paxos常用的应用场合,或许有一天当你的系统增大到一定规模,你知道有这样一个技术,可以帮助你正确及优雅的解决技术架构上一些难题。

  1. database replication, log replication等, 如bdb的数据复制就是使用paxos兼容的算法。Paxos最大的用途就是保持多个节点数据的一致性。

  2. naming service, 如大型系统内部通常存在多个接口服务相互调用。 1) 通常的实现是将服务的ip/hostname写死在配置中,当service发生故障时候,通过手工更改配置文件或者修改DNS指向的方法来解决。缺点是可维护性差,内部的单元越多,故障率越大。 2) LVS双机冗余的方式,缺点是所有单元需要双倍的资源投入。 通过Paxos算法来管理所有的naming服务,则可保证high available分配可用的service给client。象ZooKeeper还提供watch功能,即watch的对象发生了改变会自动发notification, 这样所有的client就可以使用一致的,高可用的接口。

3.config配置管理 1) 通常手工修改配置文件的方法,这样容易出错,也需要人工干预才能生效,所以节点的状态无法同时达到一致。 2) 大规模的应用都会实现自己的配置服务,比如用http web服务来实现配置中心化。它的缺点是更新后所有client无法立即得知,各节点加载的顺序无法保证,造成系统中的配置不是同一状态。

4.membership用户角色/access control list, 比如在权限设置中,用户一旦设置某项权限比如由管理员变成普通身份,这时应在所有的服务器上所有远程CDN立即生效,否则就会导致不能接受的后果。

  1. 号码分配。通常简单的解决方法是用数据库自增ID, 这导致数据库切分困难,或程序生成GUID, 这通常导致ID过长。更优雅的做法是利用paxos算法在多台replicas之间选择一个作为master, 通过master来分配号码。当master发生故障时,再用paxos选择另外一个master。

这里列举了一些常见的Paxos应用场合,对于类似上述的场合,如果用其它解决方案,一方面不能提供自动的高可用性方案,同时也远远没有Paxos实现简单及优雅。

Yahoo!开源的ZooKeeper [5]是一个开源的类Paxos实现。它的编程接口看起来很像一个可提供强一致性保证的分布式小文件系统。对上面所有的场合都可以适用。但可惜的是,ZooKeeper并不是遵循Paxos协议,而是基于自身设计并优化的一个2 phase commit的协议,因此它的理论[6]并未经过完全证明。但由于ZooKeeper在Yahoo!内部已经成功应用在HBase, Yahoo! Message Broker, Fetch Service of Yahoo! crawler等系统上,因此完全可以放心采用。

另外选择Paxos made live [7]中一段实现体会作为结尾。 / There are significant gaps between the description of the Paxos algorithm and the needs of a real-world system. In order to build a real-world system, an expert needs to use numerous ideas scattered in the literature and make several relatively small protocol extensions. The cumulative effort will be substantial and the final system will be based on an unproven protocol. / 由于chubby填补了Paxos论文中未提及的一些细节,所以最终的实现系统不是一个理论上完全经过验证的系统

/ The fault-tolerance computing community has not developed the tools to make it easy to implement their algorithms. / 分布式容错算法领域缺乏帮助算法实现的的配套工具, 比如编译领域尽管复杂,但是yacc, ANTLR等工具已经将这个领域的难度降到最低。

/ The fault-tolerance computing community has not paid enough attention to testing, a key ingredient for building fault-tolerant systems. / 分布式容错算法领域缺乏测试手段

这里要补充一个背景,就是要证明分布式容错算法的正确性通常比实现算法还困难,Google没法证明Chubby是可靠的,Yahoo!也不敢保证它的ZooKeeper理论正确性。大部分系统都是靠在实践中运行很长一段时间才能谨慎的表示,目前系统已经基本没有发现大的问题了。

Resources [1] The Chubby lock service for loosely-coupled distributed systems (PDF) [2] http://zh.wikipedia.org/wiki/Paxos%E7%AE%97%E6%B3%95 [3] http://en.wikipedia.org/wiki/Paxos_algorithm [4] Paxos Made Simple (PDF) [5] ZooKeeper [6] The life and times of a zookeeper [7] Paxos Made Live – An Engineering Perspective (PDF)

Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution 3.0 License

大型网站架构演变和知识体系

Posted on

大型网站架构演变和知识体系

BlueDavy之技术Blog

理论不懂就实践,实践不会就学理论!

大型网站架构演变和知识体系

之前也有一些介绍大型网站架构演变的文章,例如LiveJournal的、ebay的,都是非常值得参考的,不过感觉他们讲的更多的是每次演变的结果,而没有很详细的讲为什么需要做这样的演变,再加上近来感觉有不少同学都很难明白为什么一个网站需要那么复杂的技术,于是有了写这篇文章的想法,在这篇文章中 将阐述一个普通的网站发展成大型网站过程中的一种较为典型的架构演变历程和所需掌握的知识体系,希望能给想从事互联网行业的同学一点初步的概念,:),文中的不对之处也请各位多给点建议,让本文真正起到抛砖引玉的效果。

架构演变第一步:物理分离webserver和数据库

最开始,由于某些想法,于是在互联网上搭建了一个网站,这个时候甚至有可能主机都是租借的,但由于这篇文章我们只关注架构的演变历程,因此就假设这个时候 已经是托管了一台主机,并且有一定的带宽了,这个时候由于网站具备了一定的特色,吸引了部分人访问,逐渐你发现系统的压力越来越高,响应速度越来越慢,而这个时候比较明显的是数据库和应用互相影响,应用出问题了,数据库也很容易出现问题,而数据库出问题的时候,应用也容易出问题,于是进入了第一步演变阶段:将应用和数据库从物理上分离,变成了两台机器,这个时候技术上没有什么新的要求,但你发现确实起到效果了,系统又恢复到以前的响应速度了,并且支撑住了更高的流量,并且不会因为数据库和应用形成互相的影响。

看看这一步完成后系统的图示:

这一步涉及到了这些知识体系:

这一步架构演变对技术上的知识体系基本没有要求。

架构演变第二步:增加页面缓存

好景不长,随着访问的人越来越多,你发现响应速度又开始变慢了,查找原因,发现是访问数据库的操作太多,导致数据连接竞争激烈,所以响应变慢,但数据库连 接又不能开太多,否则数据库机器压力会很高,因此考虑采用缓存机制来减少数据库连接资源的竞争和对数据库读的压力,这个时候首先也许会选择采用squid 等类似的机制来将系统中相对静态的页面(例如一两天才会有更新的页面)进行缓存(当然,也可以采用将页面静态化的方案),这样程序上可以不做修改,就能够 很好的减少对webserver的压力以及减少数据库连接资源的竞争,OK,于是开始采用squid来做相对静态的页面的缓存。

看看这一步完成后系统的图示:

这一步涉及到了这些知识体系:

前端页面缓存技术,例如squid,如想用好的话还得深入掌握下squid的实现方式以及缓存的失效算法等。

架构演变第三步:增加页面片段缓存

增加了squid做缓存后,整体系统的速度确实是提升了,webserver的压力也开始下降了,但随着访问量的增加,发现系统又开始变的有些慢了,在尝 到了squid之类的动态缓存带来的好处后,开始想能不能让现在那些动态页面里相对静态的部分也缓存起来呢,因此考虑采用类似ESI之类的页面片段缓存策略,OK,于是开始采用ESI来做动态页面中相对静态的片段部分的缓存。

看看这一步完成后系统的图示:

这一步涉及到了这些知识体系:

页面片段缓存技术,例如ESI等,想用好的话同样需要掌握ESI的实现方式等;

架构演变第四步:数据缓存

在采用ESI之类的技术再次提高了系统的缓存效果后,系统的压力确实进一步降低了,但同样,随着访问量的增加,系统还是开始变慢,经过查找,可能会发现系 统中存在一些重复获取数据信息的地方,像获取用户信息等,这个时候开始考虑是不是可以将这些数据信息也缓存起来呢,于是将这些数据缓存到本地内存,改变完毕后,完全符合预期,系统的响应速度又恢复了,数据库的压力也再度降低了不少。

看看这一步完成后系统的图示:

这一步涉及到了这些知识体系:

缓存技术,包括像Map数据结构、缓存算法、所选用的框架本身的实现机制等。

架构演变第五步: 增加webserver

好景不长,发现随着系统访问量的再度增加,webserver机器的压力在高峰期会上升到比较高,这个时候开始考虑增加一台webserver,这也是为了同时解决可用性的问题,避免单台的webserver down机的话就没法使用了,在做了这些考虑后,决定增加一台webserver,增加一台webserver时,会碰到一些问题,典型的有: 1、如何让访问分配到这两台机器上,这个时候通常会考虑的方案是Apache自带的负载均衡方案,或LVS这类的软件负载均衡方案; 2、如何保持状态信息的同步,例如用户session等,这个时候会考虑的方案有写入数据库、写入存储、cookie或同步session信息等机制等; 3、如何保持数据缓存信息的同步,例如之前缓存的用户数据等,这个时候通常会考虑的机制有缓存同步或分布式缓存; 4、如何让上传文件这些类似的功能继续正常,这个时候通常会考虑的机制是使用共享文件系统或存储等; 在解决了这些问题后,终于是把webserver增加为了两台,系统终于是又恢复到了以往的速度。

看看这一步完成后系统的图示:

这一步涉及到了这些知识体系:

负载均衡技术(包括但不限于硬件负载均衡、软件负载均衡、负载算法、linux转发协议、所选用的技术的实现细节等)、主备技术(包括但不限于ARP欺骗、linux heart-beat等)、状态信息或缓存同步技术(包括但不限于Cookie技术、UDP协议、状态信息广播、所选用的缓存同步技术的实现细节等)、共享文件技术(包括但不限于NFS等)、存储技术(包括但不限于存储设备等)。

架构演变第六步:分库

享受了一段时间的系统访问量高速增长的幸福后,发现系统又开始变慢了,这次又是什么状况呢,经过查找,发现数据库写入、更新的这些操作的部分数据库连接的 资源竞争非常激烈,导致了系统变慢,这下怎么办呢,此时可选的方案有数据库集群和分库策略,集群方面像有些数据库支持的并不是很好,因此分库会成为比较普遍的策略,分库也就意味着要对原有程序进行修改,一通修改实现分库后,不错,目标达到了,系统恢复甚至速度比以前还快了。

看看这一步完成后系统的图示:

这一步涉及到了这些知识体系:

这一步更多的是需要从业务上做合理的划分,以实现分库,具体技术细节上没有其他的要求;

但同时随着数据量的增大和分库的进行,在数据库的设计、调优以及维护上需要做的更好,因此对这些方面的技术还是提出了很高的要求的。

架构演变第七步:分表、DAL和分布式缓存 随着系统的不断运行,数据量开始大幅度增长,这个时候发现分库后查询仍然会有些慢,于是按照分库的思想开始做分表的工作,当然,这不可避免的会需要对程序 进行一些修改,也许在这个时候就会发现应用自己要关心分库分表的规则等,还是有些复杂的,于是萌生能否增加一个通用的框架来实现分库分表的数据访问,这个在ebay的架构中对应的就是DAL,这个演变的过程相对而言需要花费较长的时间,当然,也有可能这个通用的框架会等到分表做完后才开始做,同时,在这个阶段可 能会发现之前的缓存同步方案出现问题,因为数据量太大,导致现在不太可能将缓存存在本地,然后同步的方式,需要采用分布式缓存方案了,于是,又是一通考察和折磨,终于是将大量的数据缓存转移到分布式缓存上了。

看看这一步完成后系统的图示:

这一步涉及到了这些知识体系:

分表更多的同样是业务上的划分,技术上涉及到的会有动态hash算法、consistent hash算法等;

DAL涉及到比较多的复杂技术,例如数据库连接的管理(超时、异常)、数据库操作的控制(超时、异常)、分库分表规则的封装等;

架构演变第八步:增加更多的webserver

在做完分库分表这些工作后,数据库上的压力已经降到比较低了,又开始过着每天看着访问量暴增的幸福生活了,突然有一天,发现系统的访问又开始有变慢的趋势 了,这个时候首先查看数据库,压力一切正常,之后查看webserver,发现apache阻塞了很多的请求,而应用服务器对每个请求也是比较快的,看来 是请求数太高导致需要排队等待,响应速度变慢,这还好办,一般来说,这个时候也会有些钱了,于是添加一些webserver服务器,在这个添加 webserver服务器的过程,有可能会出现几种挑战: 1、Apache的软负载或LVS软负载等无法承担巨大的web访问量(请求连接数、网络流量等)的调度了,这个时候如果经费允许的话,会采取的方案是购 买硬件负载,例如F5、Netsclar、Athelon之类的,如经费不允许的话,会采取的方案是将应用从逻辑上做一定的分类,然后分散到不同的软负载集群中; 2、原有的一些状态信息同步、文件共享等方案可能会出现瓶颈,需要进行改进,也许这个时候会根据情况编写符合网站业务需求的分布式文件系统等; 在做完这些工作后,开始进入一个看似完美的无限伸缩的时代,当网站流量增加时,应对的解决方案就是不断的添加webserver。

看看这一步完成后系统的图示:

这一步涉及到了这些知识体系:

到了这一步,随着机器数的不断增长、数据量的不断增长和对系统可用性的要求越来越高,这个时候要求对所采用的技术都要有更为深入的理解,并需要根据网站的需求来做更加定制性质的产品。

架构演变第九步:数据读写分离和廉价存储方案

突然有一天,发现这个完美的时代也要结束了,数据库的噩梦又一次出现在眼前了,由于添加的webserver太多了,导致数据库连接的资源还是不够用,而这个时候又已经分库分表了,开始分析数据库的压力状况,可能会发现数据库的读写比很高,这个时候通常会想到数据读写分离的方案,当然,这个方案要实现并不 容易,另外,可能会发现一些数据存储在数据库上有些浪费,或者说过于占用数据库资源,因此在这个阶段可能会形成的架构演变是实现数据读写分离,同时编写一些更为廉价的存储方案,例如BigTable这种。

看看这一步完成后系统的图示:

这一步涉及到了这些知识体系:

数据读写分离要求对数据库的复制、standby等策略有深入的掌握和理解,同时会要求具备自行实现的技术;

廉价存储方案要求对OS的文件存储有深入的掌握和理解,同时要求对采用的语言在文件这块的实现有深入的掌握。

架构演变第十步:进入大型分布式应用时代和廉价服务器群梦想时代

经过上面这个漫长而痛苦的过程,终于是再度迎来了完美的时代,不断的增加webserver就可以支撑越来越高的访问量了,对于大型网站而言,人气的重要毋 庸置疑,随着人气的越来越高,各种各样的功能需求也开始爆发性的增长,这个时候突然发现,原来部署在webserver上的那个web应用已经非常庞大 了,当多个团队都开始对其进行改动时,可真是相当的不方便,复用性也相当糟糕,基本是每个团队都做了或多或少重复的事情,而且部署和维护也是相当的麻烦, 因为庞大的应用包在N台机器上复制、启动都需要耗费不少的时间,出问题的时候也不是很好查,另外一个更糟糕的状况是很有可能会出现某个应用上的bug就导 致了全站都不可用,还有其他的像调优不好操作(因为机器上部署的应用什么都要做,根本就无法进行针对性的调优)等因素,根据这样的分析,开始痛下决心,将 系统根据职责进行拆分,于是一个大型的分布式应用就诞生了,通常,这个步骤需要耗费相当长的时间,因为会碰到很多的挑战: 1、拆成分布式后需要提供一个高性能、稳定的通信框架,并且需要支持多种不同的通信和远程调用方式; 2、将一个庞大的应用拆分需要耗费很长的时间,需要进行业务的整理和系统依赖关系的控制等; 3、如何运维(依赖管理、运行状况管理、错误追踪、调优、监控和报警等)好这个庞大的分布式应用。 经过这一步,差不多系统的架构进入相对稳定的阶段,同时也能开始采用大量的廉价机器来支撑着巨大的访问量和数据量,结合这套架构以及这么多次演变过程吸取的经验来采用其他各种各样的方法来支撑着越来越高的访问量。

看看这一步完成后系统的图示:

这一步涉及到了这些知识体系:

这一步涉及的知识体系非常的多,要求对通信、远程调用、消息机制等有深入的理解和掌握,要求的都是从理论、硬件级、操作系统级以及所采用的语言的实现都有清楚的理解。

运维这块涉及的知识体系也非常的多,多数情况下需要掌握分布式并行计算、报表、监控技术以及规则策略等等。

说起来确实不怎么费力,整个网站架构的经典演变过程都和上面比较的类似,当然,每步采取的方案,演变的步骤有可能有不同,另外,由于网站的业务不同,会有不同的专业技术的需求,这篇blog更多的是从架构的角度来讲解演变的过程,当然,其中还有很多的技术也未在此提及,像数据库集群、数据挖掘、搜索等,但在真实的演变过程中还会借助像提升硬件配置、网络环境、改造操作系统、CDN镜像等来支撑更大的流量,因此在真实的发展过程中还会有很多的不同,另外一个大型网站要做到的远远不仅仅上面这些,还有像安全、运维、运营、服务、存储等,要做好一个大型的网站真的很不容易,写这篇文章更多的是希望能够引出更多大型网站架构演变的介绍,:)。 ps:最后附上几篇LiveJournal架构演变的文章: 从LiveJournal后台发展看大规模网站性能优化方法 http://blog.zhangjianfeng.com/article/743
另外从这里:http://www.danga.com/words/大家可以找到更多关于现在LiveJournal网站架构的介绍。

posted on 2008-09-03 19:12 BlueDavy 阅读(57644) 评论(96) 编辑 收藏 所属分类: Internet

[

评论

]()

bluedavy 大哥的文章就是好,拜读过几篇了。 今天也沙发一下 回复 更多评论

好文!!另外想问一下你的图都是用什么软件画得? 回复 更多评论

很清晰,看来web也可以搞得很复杂:) 回复 更多评论

同上,拿什么做图示的? 回复 更多评论

@fisher ...visio 回复 更多评论

文路非常清晰,再展开下可以写本书了 回复 更多评论

拜读了 :) 回复 更多评论

写的真不错,长见识了。作者可以考虑出本书了!我说的是真话! 回复 更多评论

非常长见识,相信作者一定在这方面有很丰富的经验吧 回复 更多评论

写的不错。 不过有些图箭头的方向好像有问题~~ 回复 更多评论

@sopofo ^_^,是的,这里更多的是示意。 回复 更多评论

竟然知道后期要应对大流量,为何不在开始设计的时候就合理的划分模块呢,免得到最后再来做分布式。 回复 更多评论

@Iceskysl 这你就错了!开始的时候你不可能考虑这么多,无论从架构还是商业的角度你都应该遵循演进的过程。 回复 更多评论

长见识了,写的很好 回复 更多评论

总结得很好,赞一下。 回复 更多评论

不错 回复 更多评论

@Jack.Wang 把一些比较独立的功能拉出来,做成子系统,按照其需要单靠扩容,前期架构时也不难想到吧。 不是说多准确,多精确,但是有些东西还是可以提早拎出来的吧。 回复 更多评论

http://blog.sina.com.cn/s/blog_5b34bb430100aex5.html 都不知道哪个是原创的了 回复 更多评论

@Iceskysl 我想这位仁兄还需要理解下为什么Martin Flower老大会说在不需要分布式的情况下就不要去分布式,如果可以选择的话,我觉得没有一家互联网公司会采用分布式... 回复 更多评论

架构演变第十步:进入大型分布式应用时代和廉价服务器群梦想时代 不是这样吧,分布式及服务器集群就能解决大型互联网应用吗? 回复 更多评论

@hehe 这位同学,貌似没仔细看我blog中的最后部分。 “另外一个大型网站要做到的远远不仅仅上面这些,还有像安全、运维、运营、服务、存储等,要做好一个大型的网站真的很不容易” 如果你有什么想法,希望能写出来让大家也分享下。 回复 更多评论

不错,先学习了。 回复 更多评论

所有软件开发方法都要解决从需求到实现之间的转换问题。基于体系结构的软件开发包含以下几个主要阶段: 1)通过对特定领域应用软件进行分析,提炼出其中的稳定需求和易变需求,建立可重用的领域模型。依据领域模型和用户需求,产生应用系统的需求规格说明。 2)在领域模型的基础上,根据需求规格说明提炼出特定领域的软件体系结构。这是系统的高层设计,其目标是通过重用领域体系结构库中已有的高质量的体系结构,或生成最适合该用户需求的体系结构,并加以提炼入库,以备将来的重用,并在此体系结构的指导下,把系统逐步分解成相应的组件和连接件,直至组件 和连接件可以被设计模式和面向对象方法处理为止。 3)这个阶段主要解决具体组件和连接件的设计问题。通过重用可重用组件库中模式、对象和其它可重用的设计件,或重新设计的组件,并提炼入库;然后通过具体的编程实现,就可得到可运行的程序 回复 更多评论

应用出问题了,数据库也很容易出现问题,而数据库出问题的时候,应用也容易出问题 能具体说说出啥问题 回复 更多评论

写得不错。 我最近也在作相关方面的研究,不清楚对应到你上面阶段的那个部分,但是我的实现可能别有洞天。 我做web已经7年多了,最不能忍受的就是重复重复再重复,用了.net java之后我总于返回到了c时代,归结web应用其实就是数据+格式化,而xml+xslt恰恰就是这个模型,所以我的应用就是基于xml+xslt,并且做了一整套的技术论证,从SEO到换肤、多语言等高级特性都有了合理的解决方法,并且可以模块重用,做到数据跟界面的彻底分离,这样更有利于静态化,数据重用。 当然,实现的过程有阻碍,我已经做这套系统做了3年,废弃了一套java做得半成品的东西(我重写了jsp,还做了一个webserver和解释器,但是发现静态处理性能不行),现在总于有点眉目了,我的web server静态处理性能能大到nginx的120%,apache的200%(均是在300用户负载的测试下),数据库应用服务能达到15000RPS/S(静态文件23000左右,测试是在单机情况下,cpu Q6600 4核,2G内存,1个主线程,4个应用线程测试),代理性能是静态性能的接近50%,这几乎成为极限了,这为我的模型奠定了基础。 完成后系统本身就自带分布式文件系统、负载均衡、缓存系统,应用是基于配置的数据管理器,可以将数据库、静态文件、prama、服务器变量等等通过数据管理器按照用户权限发送给可解析xml的客户端,对于SEO、非xslt解析支持的浏览器等等全部采用在服务器端合成输出。界面则全部由xslt完成。 这样就能保证90%的请求能到到亚静态文件的处理速度,系统还在完善中,采用c在linux下编写的,希望有空共同探讨。 回复 更多评论

http://highscalability.com/7-stages-scaling-web-apps 回复 更多评论

大哥写的文章太精彩了。 希望可以对每个步骤做个深入研究 回复 更多评论

好文! 回复 更多评论

不错,不错 回复 更多评论

支持多写写这样的文章。 回复 更多评论

3个月后我会很需要这文章!努力! 回复 更多评论

@Iceskysl 呵呵,我觉得这个演变几乎都是互联网的演变史了,已经不光是技术层面的东西了。 就像我们知道以后屏幕都是触摸的,也没有谁现在写程序把这个考虑进去。 回复 更多评论

就要这样的文章,谢谢了 回复 更多评论

学习了,好文章,谢谢. 回复 更多评论

清楚 回复 更多评论

学习了,好文章,谢谢 回复 更多评论

哇塞,太有才了,对你佩服的五体投地啊。 看君一片文,胜编十年程! 回复 更多评论

说的太好了,如果我们公司的网站能按这个思路做下来就好了,这实际的一个问题就是投入产出比,网站发展到什么规模,上什么设备,在哪里上设备,这些必须有个明确的思路。像我们公司的网站,投入总是大于产出,就是网站没有达到这个规模,可偏要上一些高端的设备,唉。 回复 更多评论

@nongmin 呵呵,有钱的公司,羡慕 回复 更多评论

看完了文章之后才发现 原来是B大师写的 拜一下B大师 Orz…… 回复 更多评论

实践出真知阿 回复 更多评论

最后岂不是Cloud Compute了? 回复 更多评论

真理啊,我先收藏了,每天睡觉前看一遍! 回复 更多评论

开大家智慧之先河 回复 更多评论

看帖,留名 ^_^ 回复 更多评论

好贴.从别处看到贴子的推荐.很不错.分布式的想听全些. 回复 更多评论

爆强,从来没看过关于网站架构的这么强的帖子!! 回复 更多评论

相当不错的,思路很清晰,很好理解,能更加深入将每一个具体的实例就更好了。谢! 回复 更多评论

说的太好了,如果我们公司的网站能按这个思路做下来就好了,这实际的一个问题就是投入产出比,网站发展到什么规模,上什么设备,在哪里上设备,这些必须有个明确的思路。像我们公司的网站,投入总是大于产出,就是网站没有达到这个规模,可偏要上一些高端的设备,唉 回复 更多评论

小虾路过 拜读了 虽然很多不懂 但思路的清晰却是十分惊人的 回复 更多评论

拜读了 虽然很多不懂 回复 更多评论

不错 回复 更多评论

@lingxiao 前辈的所下的功夫值得钦佩! 回复 更多评论

十分不错.支持 回复 更多评论

新的一天开始了。我要学习大型网站架构演变和知识体系啦 回复 更多评论

新的一天开始了。 回复 更多评论

拜读了,学习中。这应该就是立志做成一个大型Web2.0应用需要走过的里程碑,反过来说,如果有幸能够走到第十步,应该也算得上是一个比较成熟的Web2.0应用了。我最好还是从起步开始吧。 回复 更多评论

总结的很清晰。不过网站架构的发展往往不是按部就班,有可能在头一两个阶段就采用分布式cache,应用服务器水平扩展,数据库分库 回复 更多评论

很舒心的从头到尾看完了,如西湖灌顶啊,兄弟,我把这篇文章永远收藏在硬盘里:) 回复 更多评论

好文!!!行云流水一样,舒服! 只不过有些介绍的过分简单. 回复 更多评论

好文,值得自己好好深究。。。。。。 回复 更多评论

不错哦 回复 更多评论

分析的过程很透彻,演化的过比较细腻,一次只进化一点,希望与博主交流。我设计程序结构的时候,前几步是直接进化来的,跳跃很强,希望重点讨论后几部的进化过程。 回复 更多评论

当我们演化到第十步后,我们从front-end到back-end似乎都有了可以扩展和提高性能的方法,但还有一个问题: 动态内容的如何在不同地理位置分布来减少网络带来的延迟. CDN通过备份似乎比较好的解决了静态内容的发布,但动态的实时的数据又该如何处理呢? 回复 更多评论

@Jim 顶,:),通常来说,动态的实时数据更多的公司只能是依靠建立异地数据中心甚至是应用中心来提升。 回复 更多评论

@lingxiao 怎么做到的,,我刚接触这块不久,,有好多东西都没有好的解决,看完你们所说,我忽然觉得自已还是刚起步,,好多东西要学习,实践。 回复 更多评论

可以加我QQ:517305903 MSN:huyaoniu@hotmail.com 回复 更多评论

好贴,让我长见识了,本人刚接触这方面的东西,感觉还有好多东西要学习。 回复 更多评论

好东西,这样的贴本想只有在培训中可以看到。 回复 更多评论

不错,经验丰富啊!希望前辈多多赐教! 回复 更多评论

太感谢了,这样的文章我找了很长时间,终于找到,这帮我理清了这方面的学习路线。 回复 更多评论

这篇网站算是很深刻了,但是还远远不够细节,只有宏观指导价值。期盼在新书中能够有效提供一些更加实战、细节的内容。 回复 更多评论

很好的文章,写得很清晰,我也是做大型网站的,文章中说的那些问题很多我都遇到过,很有感触。有些技术我们已经采用了,有些没有用,有些是第一次听说,开了眼界,决定收藏这篇文章了。 不知BlueDavy能否提供各种技术更加深入的介绍,想有一个全面深入的了解,谢谢。 回复 更多评论

提个并发问题, 1000人或者更多 同时进行读写操作,应该如何入手呀?软件哪方面?硬件又哪方面呢? 回复 更多评论

@suyiming99 个人看法,这个还抽象了点?读写比差不多的话会比较麻烦,基本上只能按用户把读写的压力分解开,但这要看使用场景是否允许分开,至少写是肯定要分开的。 回复 更多评论

提示: 用户被禁止或删除 内容自动屏蔽 回复 更多评论

@Jack.Wang 很有道理, 回复 更多评论

很有道理,开始设计的时候考虑的可能多是成本之类的问题,现在的企业在看到利润之前谁会保证给你多少money用来实现这么庞大的架构。 回复 更多评论

好文章,受益匪浅 回复 更多评论

@ronghao 很多软件都可以的呀。 比如PS,FW等等 回复 更多评论

说得不错. 回复 更多评论

不错的文章,转了。 回复 更多评论

有两张图重复了 回复 更多评论

真的是受益匪浅啊 回复 更多评论

@lingxiao 你写成这样的,全xlst解析,估计也只能自己用了。 让其他人看懂,能么?怀疑 回复 更多评论

@lingxiao 又过去两年了,不知你的工作成果完成没有? 回复 更多评论

我公司正在做大型教育云,需要大型网站架构师,高薪聘请。联系电话13651262860 肖女士 回复 更多评论

极品文章,不得不顶 回复 更多评论

ESI 现在,这种技术,还有在用? 回复 更多评论

是好朋友推荐的。非常喜欢。受教了~ 回复 更多评论

群上聊天进来的学习了 回复 更多评论

mark ... 回复 更多评论

抽丝剥茧,一层层分析得透彻,非常好的文章。不故作高深,看得舒畅、明白。佩服! 回复 更多评论

确实非常不错,适合精度。 回复 更多评论

写出来的这些,这说明从小到大都经历了一边!有实践,有理论,好文章! 回复 更多评论

请大帅帮我解决一下我的小站问题. 下面是我的小站:http://www.zrpmw.com/ http://www.yitaoman.com/ 回复 更多评论

来看晚了点,学习良多! 回复 更多评论 新用户注册 刷新评论列表

推荐购买云服务器(15%返利+最高千元奖金) 博客园 博问 IT新闻 Java程序员招聘 标题 请输入标题 姓名 请输入你的姓名 主页 请输入验证码 验证码 /* 内容(请不要发表任何与政治相关的内容) 请输入评论内容 Remember Me? 登录 [使用Ctrl+Enter键可以直接提交] 网站导航:

博客园 IT新闻 知识库 C++博客 程序员招聘 管理 相关文章:

feedsky 抓虾 google reader 鲜果

导航

统计

  • 随笔 - 294
  • 文章 - 2
  • 评论 - 2068
  • 引用 - 1

随笔分类

随笔档案

文章档案

Blogger's

搜索

*

最新评论

阅读排行榜

评论排行榜

YouTube架构学习体会

Posted on

YouTube架构学习体会 - IT青藤屋 - 青藤园

Skip to main content.

IT青藤屋

Article date: 关注架构、关注前端、关注生活,愿天下的程序员像常青藤一样绿意盎然、自强不息 Navigation:

今天让我感到了知识产权对作者的重要性,博客中的文章如果没有特殊说明,均为原创或者翻译,转载请注明原文出处。另外,在我博客中的一些文章,或许有意无意侵犯了您的知识产权,如果您发现了,请及时发邮件联系我,我将立即作出处理。我的邮箱:

sxwgf.com@gmail.com

谢谢!

feedsky 抓虾 google reader netvibes 鲜果 有道 QQ邮箱

如果能成为巨人,我愿意献出肩膀 王国峰 2011年毕业于 中国计量学院

我的博客园 Email联系我

文章分类

文章归档

阅读排行

我的书屋

友情链接

YouTube架构学习体会

这几天一直在关注和学习一些大型网站的架构,希望有一天自己也能设计一个高并发、高容错的系统并能应用在实践上。今天在网上找架构相关的资料时,看到一个被和谐的视频网站YouTube的架构分析,看了以后觉得自己又向架构走近了一步,于是赶快拿出来与大家一起分享。

YouTube发展迅速,每天超过1亿的视频点击量,但只有很少人在维护站点和确保伸缩性。这点和PlentyOfFish类似,少数人维护庞大系统。是什么原因呢?放心绝对不是靠人品,也不是靠寂寞,下面就来看看YouTube的整体技术架构吧。

平台


1

2 3

4 5

6 Apache

Python Linux(SuSe)

MySQL psyco,一个动态的Python到C的编译器

lighttpd代替Apache做视频查看

状态


1

2 3

4 5

6 支持每天超过1亿的视频点击量

成立于2005年2月 于2006年3月达到每天3千万的视频点击量

于2006年7月达到每天1亿的视频点击量 2个系统管理员,2个伸缩性软件架构师

2个软件开发工程师,2个网络工程师,1个DBA

Web服务器


1

2 3

4 5

6 7

8 9

10 11

12 13

14 151,NetScaler用于负载均衡和静态内容缓存

2,使用mod_fast_cgi运行Apache 3,使用一个Python应用服务器来处理请求的路由

4,应用服务器与多个数据库和其他信息源交互来获取数据和格式化html页面 5,一般可以通过添加更多的机器来在Web层提高伸缩性

6,Python的Web层代码通常不是性能瓶颈,大部分时间阻塞在RPC 7,Python允许快速而灵活的开发和部署

8,通常每个页面服务少于100毫秒的时间 9,使用psyco(一个类似于JIT编译器的动态的Python到C的编译器)来优化内部循环

10,对于像加密等密集型CPU活动,使用C扩展 11,对于一些开销昂贵的块使用预先生成并缓存的html

12,数据库里使用行级缓存 13,缓存完整的Python对象

14,有些数据被计算出来并发送给各个程序,所以这些值缓存在本地内存中。这是个使用不当的策略。

应用服务器里最快的缓存将预先计算的值发送给所有服务器也花不了多少时间。只需弄一个代理来监听更改,预计算,然后发送。

视频服务


1

2 3

4 5

6 7

8 9

10 11

12 13

14 15

16 17

18 1,花费包括带宽,硬件和能源消耗

2,每个视频由一个迷你集群来host,每个视频被超过一台机器持有 3,使用一个集群意味着:

-更多的硬盘来持有内容意味着更快的速度

-failover。如果一台机器出故障了,另外的机器可以继续服务

-在线备份 4,使用lighttpd作为Web服务器来提供视频服务:

-Apache开销太大

-使用epoll来等待多个fds

-从单进程配置转变为多进程配置来处理更多的连接 5,大部分流行的内容移到CDN:

-CDN在多个地方备份内容,这样内容离用户更近的机会就会更高

-CDN机器经常内存不足,因为内容太流行以致很少有内容进出内存的颠簸

6,不太流行的内容(每天1-20浏览次数)在许多colo站点使用YouTube服务器

-长尾效应。一个视频可以有多个播放,但是许多视频正在播放。随机硬盘块被访问

-在这种情况下缓存不会很好,所以花钱在更多的缓存上可能没太大意义。

-调节RAID控制并注意其他低级问题

-调节每台机器上的内存,不要太多也不要太少

视频服务关键点

1

2 3

4 51,保持简单和廉价

2,保持简单网络路径,在内容和用户间不要有太多设备 3,使用常用硬件,昂贵的硬件很难找到帮助文档

4,使用简单而常见的工具,使用构建在Linux里或之上的大部分工具 5,很好的处理随机查找(SATA,tweaks)缩略图服务

1

2 3

4 5

6 7

8 9

10 11

12 13

14 15

16 171,做到高效令人惊奇的难

2,每个视频大概4张缩略图,所以缩略图比视频多很多 3,缩略图仅仅host在几个机器上

4,持有一些小东西所遇到的问题:

-OS级别的大量的硬盘查找和inode和页面缓存问题

-单目录文件限制,特别是Ext3,后来移到多分层的结构。内核2.6的最近改进可能让 Ext3允许大目录,但在一个文件系统里存储大量文件不是个好主意

-每秒大量的请求,因为Web页面可能在页面上显示60个缩略图

-在这种高负载下Apache表现的非常糟糕

-在Apache前端使用squid,这种方式工作了一段时间,但是由于负载继续增加而以失败告终。它让每秒300个请求变为20个

-尝试使用lighttpd但是由于使用单线程它陷于困境。遇到多进程的问题,因为它们各自保持自己单独的缓存

-如此多的图片以致一台新机器只能接管24小时

-重启机器需要6-10小时来缓存 5,为了解决所有这些问题YouTube开始使用Google的BigTable,一个分布式数据存储:

-避免小文件问题,因为它将文件收集到一起

-快,错误容忍

-更低的延迟,因为它使用分布式多级缓存,该缓存与多个不同collocation站点工作

-更多信息参考Google Architecture,GoogleTalk Architecture和BigTable

数据库

1

2 3

4 5

6 7

8 9

10 11

12 13

14 15

16 171,早期

-使用MySQL来存储元数据,如用户,tags和描述

-使用一整个10硬盘的RAID 10来存储数据

-依赖于信用卡所以YouTube租用硬件

-YouTube经过一个常见的革命:单服务器,然后单master和多read slaves,然后数据库分区,然后sharding方式

-痛苦与备份延迟。master数据库是多线程的并且运行在一个大机器上所以它可以处理许多工作,slaves是单线程的并且通常运行在小一些的服务器上并且备份是异步的,所以slaves会远远落后于master

-更新引起缓存失效,硬盘的慢I/O导致慢备份

-使用备份架构需要花费大量的money来获得增加的写性能

-YouTube的一个解决方案是通过把数据分成两个集群来将传输分出优先次序:一个视频查看池和一个一般的集群

2,后期

-数据库分区

-分成shards,不同的用户指定到不同的shards

-扩散读写

-更好的缓存位置意味着更少的IO

-导致硬件减少30%

-备份延迟降低到0

-现在可以任意提升数据库的伸缩性数据中心策略

1

2 3

4 5

6 7

8 1,依赖于信用卡,所以最初只能使用受管主机提供商

2,受管主机提供商不能提供伸缩性,不能控制硬件或使用良好的网络协议 3,YouTube改为使用colocation arrangement。现在YouTube可以自定义所有东西并且协定自己的契约

4,使用5到6个数据中心加CDN 5,视频来自任意的数据中心,不是最近的匹配或其他什么。如果一个视频足够流行则移到CDN

6,依赖于视频带宽而不是真正的延迟。可以来自任何colo 7,图片延迟很严重,特别是当一个页面有60张图片时

8,使用BigTable将图片备份到不同的数据中心,代码查看谁是最近的学到的东西

1

2 3

4 5

6 7

8 9

10 111,Stall for time。创造性和风险性的技巧让你在短期内解决问题而同时你会发现长期的解决方案

2,Proioritize。找出你的服务中核心的东西并对你的资源分出优先级别 3,Pick your battles。别怕将你的核心服务分出去。YouTube使用CDN来分布它们最流行的内容。创建自己的网络将花费太多时间和太多money

4,Keep it simple!简单允许你更快的重新架构来回应问题 5,Shard。Sharding帮助隔离存储,CPU,内存和IO,不仅仅是获得更多的写性能

6,Constant iteration on bottlenecks:

-软件:DB,缓存

-OS:硬盘I/O

-硬件:内存,RAID

7,You succeed as a team。拥有一个跨越条律的了解整个系统并知道系统内部是什么样的团队,如安装打印机,安装机器,安装网络等等的人。

With a good team all things are possible。

分享到: QQ空间 新浪微博 人人网 更多 6 标签: 高性能, 架构, YouTube, 视频

Posted by ivy @ 2011-3-6 20:53:24 阅读(6410) 评论(2) 上一篇:【IE6.0 Bug总结之二】双倍边距(margin)的bug 下一篇:WikiPedia技术架构学习笔记

Feedback

  1. 回复 2011-10-28 14:45:36 by pc
  2. 回复 2013-1-24 14:43:45 by Godaddy 优惠码 没图片看不懂啊 你还可以输入600/600个字符 发表评论

称呼: (必填) 登录 | 开通博客 邮箱: (选填) 你的邮箱地址不会被公开

网站: (选填) ")")")

验证码: (必填) 看不清换一张 看不清楚换一张

Copyright © ivy 2011 . Powered by 青藤园 Courtesy of Open Web Design & Hotels - Dubai