"\u003cp\u003e从老高的近期工作总结中看到：\u003c/p\u003e\n\u003cp\u003e目前的技术状况是基于自行设计的 PHP 框架，跑在 PHP 5.2 + MySQL 5.1 下，PHP 使用 Fastcgi 模式，WebServer 选择了 Nginx。搜索功能基于 Lucene 开发。缓存代理使用 Varnish。\u003c/p\u003e\n\u003cp\u003e对老高进行了一次非正式采访，聊了不少内容，整理了一下和大家分享。(谁是高春辉? 这个不要介绍了吧，请 Google! )\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e历史情况\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eFenng: 原来大约是用什么? 框架用的什么？\n高春辉: 你说老系统？Apache 1.3 , DB 是 MySQL 4.0。新框架是团队自己写的，定制了一些东西吧，主要强调的是性能和方便、简单。另外把针对 YSlow 的优化也做进去了。\nFenng: 单说现在用的框架，大约投入了多少个人/天 ?\n高春辉: 从全年开始考虑写，一直不断的写 — 具体时间不好说。反正是不少了 🙂\nFenng: 看了你 Blog 中的描述，有个小疑惑：没使用面向 DB 的 Cache 层?\n高春辉: 我文中说的 Data accessor 就算是了。目前是拿 PHP 做的，Client+Server 集成在一 …\u003c/p\u003e"

"\u003cp\u003e基于ID的分片机制实现存储的分布化会遇到一个问题：固定存储空间随着时间增加再次达到系统的空间/负载的瓶颈。观察了一下Flickr的图片存储 地址：好像是在定期启用新的集群，各个时期的域名分布如下：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003ca href=\"http://farm1.static.flickr.com\"\u003ehttp://farm1.static.flickr.com\u003c/a\u003e 2006年中以前；\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"http://farm2.static.flickr.com\"\u003ehttp://farm2.static.flickr.com\u003c/a\u003e 2006年底；\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"http://farm3.static.flickr.com\"\u003ehttp://farm3.static.flickr.com\u003c/a\u003e 2007年底；\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"http://farm4.static.flickr.com\"\u003ehttp://farm4.static.flickr.com\u003c/a\u003e 2008年底；\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003e\u003ca href=\"http://www.kuqin.com/shuping/20081003/20540.html\"\u003e《构建可扩展的Web站点》\u003c/a\u003e 上 没有提到这个策略，猜测Flickr应该是不断在启用新的服务器集群，当地一个集群用到90%的时候，开始启用下一个集群。一个用户的所有图片地址则存储 在数据库中：记录会包含当时的存储所在的集群：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003euser_foo – farm1.static……/20060124_003.jpg\u003c/p\u003e\n\u003cp\u003e\\ farm1.static……/20060324_005.jpg\u003c/p\u003e\n\u003cp\u003e\\ farm1.static……/20060824_021.jpg\u003c/p\u003e\n\u003cp\u003e\\ …\u003c/p\u003e\u003c/blockquote\u003e"

"\u003cp\u003e当Microsoft在PDC2008上携 \u003ca href=\"http://www.kuqin.com/system-analysis/20081030/25061.html\"\u003eAzure平台\u003c/a\u003e 驾 云而来时，天气预测注定将发生改变。将当前市场上分别来自Amazon、Google和Microsoft的三大主流产品作一比较会是一件非常有意思的事 儿。第一眼看上去的印象是它们彼此之间似乎实际上并不存在真正的相互竞争。\u003c/p\u003e\n\u003cp\u003eZiff兄弟投资的副总裁Michael J. Miller \u003ca href=\"http://blogs.pcmag.com/miller/2008/11/cloud_thinking_amazon_microsof.php\"\u003e对云计算的三大角逐者进行了比较\u003c/a\u003e，这是他关于Amazon EC2的发现：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e备受关注的云平台无疑就是\u003ca href=\"http://aws.amazon.com/\"\u003eAmazon Web服务\u003c/a\u003e了，它是多种工具 的集合，大部分都位于相当底层。其中又以Amazon弹性计算云(EC2)最为出众，这一Web服务能你将应用分配给任意多的“计算单元”。简单的说，一 个标准的单一实例包括了一个“虚拟核心”，1.7GB的内存，以及160GB的存储实例（只针对该对话的存储），价格为每小时10美分。在这个服务之上， 你可能会考虑使用该公司提供的“简单存储服务”(S3)，对于前50TB的数据，其价格是每GB每月15美分，之后价格递减，同时要收取一定的交易费用。 同时你也可能考虑使用该公司的“Simple DB”数据库，或者是用于存储消息的队列 …\u003c/p\u003e\u003c/blockquote\u003e"

"\u003cp\u003e\u003cstrong\u003e前言：\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e关于Digg的架构，之前 \u003ca href=\"http://www.dbanotes.net/\"\u003eFenng\u003c/a\u003e 已 经写过一篇 \u003ca href=\"http://www.kuqin.com/system-analysis/20090214/34906.html\"\u003eDigg 网站架构\u003c/a\u003e 的文章，Fenng在文章开头说“\u003cem\u003e越来越发现其实都是自我重复的劳动，后续的信息都是嚼别人剩下的甘蔗。\u003c/em\u003e”，其实是 Fenng过谦了，我就是从 \u003ca href=\"http://www.dbanotes.net/\"\u003eDBA notes\u003c/a\u003e 一点一滴开始学习的。\u003c/p\u003e\n\u003cp\u003e原文在 \u003ca href=\"http://highscalability.com/scaling-digg-and-other-web-applications\"\u003eScaling Digg and Other Web Applications\u003c/a\u003e， \u003ca href=\"http://highscalability.com/\"\u003eTodd Hoff\u003c/a\u003e 总能给我们带来一些有意思的文章。这里既不直译也不全译，保持原文骨干加上肤浅的理解。\u003c/p\u003e\n\u003cp\u003eDigg用户在3000W左右，网站每秒请求数达到13000个，规模算是很大了，Lamp（Linux+Apache+MySQL+PHP）结 构，Web2.0网站中钟情PHP的不少，国外的Facebook、Digg、Flickr…，国内的新浪博客、开心网、51.com等等，扩展的不是编程语言而是网站架构，因为编程语言从来都不会是网站瓶颈，每种语言都有自己适合做和不适合做的事情。喜欢比较语言快慢的可以看看 \u003ca href=\"http://shootout.alioth.debian.org/\"\u003ehttp://shootout.alioth.debian.org/\u003c/a\u003e， 看看而已不要用速度去衡量编程语言的优劣。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eDigg的扩展战略：\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e扩 …\u003c/li\u003e\u003c/ul\u003e"

"\u003cp\u003e本篇描述一下 \u003ca href=\"http://digg.com/\"\u003eDigg\u003c/a\u003e 的网站架构.\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003e国庆期间又收集了一些关于网站架构的信息。一直没有进行系统的整理。越来越发现其实都是自我重复的劳动，后续的信息都是嚼别人剩下的甘蔗。--by Fenng\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003eDigg 工程师采用 LAMP (Linux, Apache, MySQL and PHP) 模式。这个 Alexa 排名在 100 左右的、自我估价 1.5 亿美金的站点目前有超过 100 台的 PC 服务器(足够少了)，可以粗略分成三个部分：数据库服务器，Web 服务器，搜索服务器。\u003c/p\u003e\n\u003cp\u003e数据库方面，和其他成功的 Web 2.0 站点一样，也是 MySQL，不过 Digg 稍微”激进”一点，用 MySQL 5，而且号称从 MySQL 4 升级到 5 性能没有什么影响。 OLTP 应用用 InnoDB 引擎, OLAP 用 MyISAM。后端数据库的读比例达到 98%，写只有 2%，实际的读写比例应该高于这个数字，这应该是 Digg 在前端用 \u003ca href=\"http://www.danga.com/memcached/\"\u003eMemcached\u003c/a\u003e 以及 \u003ca href=\"http://php.net/apc\"\u003eAPC PHP accelerator\u003c/a\u003e / MCache 做缓存后的效果。在 IO 上似乎压力并不大。\u003c/p\u003e\n\u003cp\u003e数据库分割用 Sharding …\u003c/p\u003e"

"\u003cp\u003e很多人都觉得 eBay 在 \u003ca href=\"http://www.qconbeijing.com/\"\u003eQCon (北京)\u003c/a\u003e 上的技术\u003ca href=\"http://qconbeijing.com/Speaker.aspx?Id=8\"\u003e讲座\u003c/a\u003e不错，但对我来说，其实 冲击力没那么大了。eBay 一两年前就是这个 PPT 。不过还是比 Amazon 的 Jeff Barr 强了很多，以后要是开个什么会，你把 Jeff Barr 请来还讲那个销售文档，估计自己都不好意思。\u003c/p\u003e\n\u003cp\u003e不过，eBay 这次的PPT 总算还是有点更新的。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e1）数据分片(Partition Everything)\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e说是分区(Partition)，这里不能简单等同于 Oracle 的分区，理解成分片(Sharding)就好啦。可以参考一下我以前写的科普小文： \u003ca href=\"http://www.kuqin.com/database/20080825/15070.html\"\u003e开源数据库 Sharding 技术 (Share Nothing)\u003c/a\u003e。这里要强调一下的是，分片是在数据量的确有规模的时候才适合进行，如果单节点足以应付，那么还是不要冒 进。\u003c/p\u003e\n\u003cp\u003e从分片的模式上，eBay 主要根据功能切分(Functional Segmentation)和水平分割(负载均衡考虑)，作为推论，所有会话都是无状态性的。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e2）异步处理(Asynchrony Everywhere)\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e其实对于任何网站来说，过度追求”同步”化设计还是比较糟糕的做法。以 …\u003c/p\u003e"

"\u003cp\u003e这次 \u003ca href=\"http://www.qconbeijing.com/\"\u003eQCon (北京)会议\u003c/a\u003e网站架构案例分析这个 Track ，虽然话题不多，但课程设计时候考虑覆盖的面还是比较广的。作为视频网站代表，优酷带来了一场包含不少实战经验的技术分享。\u003ca href=\"http://www.qconbeijing.com/Speaker.aspx?Id=29\"\u003e邱丹\u003c/a\u003e(优酷网开发副总裁，核心架 构师)可能公司的事情比较忙，一直到第二天中午才赶到会场。还半开玩笑说，’怎么这么多人，还以为是小型的会议呢’…\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"http://blog.haohtml.com/wp-content/uploads/2010/06/youku.com_.jpg\"\u003e\u003cimg src=\"https://blogstatic.haohtml.com//uploads/2023/09/youku.com_.jpg\" alt=\"\"\u003e\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e缓存\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e缓存黄金原则：\u003cstrong\u003e让数据更靠近 CPU\u003c/strong\u003e。\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003eCPU--\u0026gt;CPU 一级缓存--\u0026gt;二级缓存--\u0026gt;内存--\u0026gt;硬盘--\u0026gt;LAN--\u0026gt;WAN\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e讲到了 Youku 自己的内部项目，针对大文件缓存的。目前开源软件中，Squid 的 write() 用户进程空间有消耗，Lighttpd 1.5 的 AIO(异步I/O) 读取文件到用户内存导致效率也比较低下。Youku 不用内存做缓存(避免内存拷贝，避免内存锁)。值得注意的是，缓存技术容易被滥用，也有副作用，比如接到老大哥通知要把某个视频撤下来，如果在缓存里是比 较麻烦的。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e数据库\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e优酷对数据库 Sharding 做了不少尝试，而且实现效果应该不错。DB 读写分离上有比较丰富的经验。\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"http://blog.haohtml.com/wp-content/uploads/2010/06/Youku_Sharding.png\"\u003e\u003cimg src=\"https://blogstatic.haohtml.com//uploads/2023/09/Youku_Sharding.png\" alt=\"\"\u003e\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e为了提升数据 …\u003c/p\u003e"

"\u003cp\u003e传统的文件同步方案有rsync(单向) 和 unison(双向)等，它们需要扫描所有文件后进行比对，差量传输。如果文件数量达到了百万甚至千万量级，扫描所有文件将非常耗时。而且正在发生变化的 往往是其中很少的一部分，这是非常低效的方式。\u003c/p\u003e\n\u003cp\u003e之前看了\u003ca href=\"http://s3.amazonaws.com/AllThingsDistributed/sosp/amazon-dynamo-sosp2007.pdf\"\u003eAmazon 的Dynamo的设计文档\u003c/a\u003e，它们每个节点的数据是通过Hash Tree来实现同步，既有通过日志来同步的软实时特点(msyql, bdb等)，也可以保证最终数据的一致性(rsync, unison等)。Hash Tree的大体思路是将所有数据存储成树状结构，每个节点的Hash是其所有子节点的Hash的Hash，叶子节点的Hash是其内容的Hash。这样一 旦某个节点发生变化，其Hash的变化会迅速传播到根节点。需要同步的系统只需要不断查询跟节点的hash，一旦有变化，顺着树状结构就能够在logN级 别的时间找到发生变化的内容，马上同步。\u003c/p\u003e\n\u003cp\u003e文件系统天然的是树状结构，尽管不是平衡的数。如果文件的修改时间是可靠的，可以表征文件的变化，那就可以用它作为文件的Hash值。另一方面，文 件的修改通常是按顺序执行的，后修改的文件比早修改的文件具有更大 …\u003c/p\u003e"

"\u003cp\u003e这次beta沙龙请了\u003ca href=\"http://www.paulgao.com.cn/\"\u003e高春辉\u003c/a\u003e的团队来讲他们的经验。本来我是 希望老高讲，不过他说最近的系统主要是许超前在带人开发，所以实际的演讲人是许超前。\u003c/p\u003e\n\u003cp\u003e国内最早让大家意识到网站的发展阶段的文档大概就是于敦德翻译的LiveJournal发展历程的ppt。这次许超前的演讲非常类似 LiveJournal的那篇。\u003c/p\u003e\n\u003cp\u003e手机之家用了7年时间，发展到1000万以上用户，3000万以上帖子，1.1TB附件，每天780万以上的PV这个规模。这个数字虽然比 不上大型互联网公司，但是对一个只有几个人的技术团队，已经是一个很令人骄傲的数字了。\u003c/p\u003e\n\u003cp\u003eLiveJournal在发展中一边用着开源软件，一边造轮子，最后造出来了memcached这个简单而强大的工具，最终成了这一代网站开发离不 开的东西。\u003c/p\u003e\n\u003cp\u003e这次演讲有意思的部分就是从memcached相关的事情开始的。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e一 关于memcached的应用和管理。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003ememcached确实是个简单，好用，见效快的东西。不过简单也有简单的问题，程序员各有各的习惯，结果导致key很不规范，用什么方式的都有。 这个问题恐怕用过memcached的人都深有体会。当然，用开发规范来限制程序员的行为是一 …\u003c/p\u003e"

"\u003cp\u003e在 QCon 2008 (旧金山站) 上Facebook 做的这个技术分享有不少值得借鉴的东西。所 以，暂停对 QCon 北京的回顾，临时插播一贴。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e设计原则\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e尽可能的使用开源软件，并且在需要优化的时候进行优化\u003c/li\u003e\n\u003cli\u003eUnix 哲学。包括，模块化原则；整合化原则；清晰化原则等\u003c/li\u003e\n\u003cli\u003e任何组件具备扩展性\u003c/li\u003e\n\u003cli\u003e最小化故障影响\u003c/li\u003e\n\u003cli\u003e简化，简化，简化！\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003e架构概览\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eFacebook 是 LAMP 的坚定支持者，也差不多是用 LAMP (或许用 LAM2P 更适合) 实现的最大的动态站点。\u003cimg src=\"http://www.kuqin.com/upimg/allimg/090412/2229360.png\" alt=\"Facebook Arch Overview.png\"\u003e\u003c/p\u003e\n\u003cp\u003e基础组件加上服务，中间用自己实现的一些工具进行粘合。其中关于运维细节的事情基本不会说出来的，这是很多公司的软实力所在。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003ePHP 经验\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e参见《 \u003ca href=\"http://www.kuqin.com/web/20080410/6398.html\"\u003eFacebook 的 PHP 性能与扩展性\u003c/a\u003e》\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eMySQL 经验\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e主要用于做 Key-Value 类型的存储操作，数据随机分布在多台逻辑实例上，访问多数基于全局 ID 。\u003c/li\u003e\n\u003cli\u003e逻辑实例分散在多台物理主机上(超过1800台)，负载均衡在物理层进行。\u003c/li\u003e\n\u003cli\u003e不做读复制。\u003c/li\u003e\n\u003cli\u003e尽量不做逻辑数据迁移(成本太高)。\u003c/li\u003e\n\u003cli\u003e不做 JOIN 操作 ( \u003ca href=\"http://www.kuqin.com/system-analysis/20090411/45329.html\"\u003e豆瓣在 QCon\u003c/a\u003e 上也阐述了这一点)。数据是随机分布的，关联操作反而带 …\u003c/li\u003e\u003c/ul\u003e"

"\u003cp\u003e根据Linda Rising的《Pattern Almanac》一书，已知的架构模式有七十多种。这是一个只多不少的统计，其中包括了很多通常认为是设计模式的模式，比如 Bridge，Facade，Interpreter，Mediator等模式通常认为是设计模式，但是在许多情况下，也可以作为架构模式出现，因此也常 常被当作架构模式。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eLayers架构模式\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e在收集到用户对软件的要求之后，架构设计就开始了。架构设计一个主要的目的，就是把系统划分成为很多”板块”。划分的方式通常有两种，一种是横向的划分， 一种是纵向划分。\u003c/p\u003e\n\u003cp\u003e横向划分将系统按照商业目的划分。比如一个书店的管理系统可以划分成为进货、销售、库存管理、员工管理等等。\u003c/p\u003e\n\u003cp\u003e纵向划分则不同，它按照抽象层次的高低，将系统划分成”层”，或叫Layer。比如一个公司的内网管理系统通常可以划分成为下面的几个Layer:\u003c/p\u003e\n\u003cp\u003e一、网页，也就是用户界面，负责显示数据、接受用户输入；\u003c/p\u003e\n\u003cp\u003e二、领域层，包括JavaBean或者COM对象、B2B服务等，封装了必要的商业逻辑，负责根据商业逻辑决定显示什么数据、以及如何根据用户输入的数据 进行计算；\u003c/p\u003e\n\u003cp\u003e三、数据库，负责存储数 …\u003c/p\u003e"

"\u003cp\u003e切分是最基本，且最多变的思路之一，说基本，是因为在学习程序设计的第一天就应该知道，说多变，是因为在未来的很多年里，你会不停的应用这个方法来 解决问题。不幸的是，切分这个思路并没有得到应有的重视。\u003c/p\u003e\n\u003cp\u003e大概是因为这个词比较土，说起来也比较普通，远不如并行，集群，负载平衡这些词听起来大。所以碰到一个问题的时候，往往被拿出来的解决方案会是以上 3个大词之一，很少有人去认真的考虑切分问题。但事实上，这3个大词所需要的技术，其实也是建立在良好可切分的系统之上的。\u003c/p\u003e\n\u003cp\u003e最近碰到了2个项目，都是典型案例。\u003c/p\u003e\n\u003cp\u003e案例1 ，小公司，发展的不错。一台服务器眼看不够用了，于是就买了第二台，希望能做一个”负载均衡”系统。很多人大概认为负载均衡，是类似自来水一样的技术，只 要打开笼头，清水就汩汩涌出。往往忘记了水龙头后面的水管和自来水公司。\u003c/p\u003e\n\u003cp\u003e一个服务器上放了很多个服务，是很难应用负载均衡这种技术的。必须先要把服务拆开，找到性能薄弱的点，对这个点进行负载均衡，才能得到比较好的效 果。否则很可能用了80%的力气，但是只得到20%的结果。\u003c/p\u003e\n\u003cp\u003e案例2，某外企。之前我们给他们做过咨询，解决了一次问题，上次我们找到了系统最慢的地方，去掉 …\u003c/p\u003e"

"\u003cp\u003e最近和几个朋友在谈到时下流行的Web 2.0，也提到了其中最重要的角色——架构师。多方各有争执，不外乎是因为背景和视角的缘故，包括架构一词，本身就从建筑学借鉴而来，至于架构师，则可以 简单地从建筑学的设计师来引申，不外乎就是设计结构，设计一个大楼的结构。回到软件本身，那就可以简单地理解为负责设计软件框架的人了。\u003c/p\u003e\n\u003cp\u003e我们没有讨论清楚架构师、软件架构师、系统架构师及其Web 架构师这些看似相同却有所区别的角色的关键，本身智者见智，仁者见仁，也不是一时半会能够说清楚的，最后我们讨论作为一个Web 2.0 网站架构师需要的一些基本的知识和能力，既然是个人看法，难免有失偏颇：\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e熟知你的业务模式和目标人群\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e这是最重要的，Web 2.0 本质上是以Web 作为平台的业务应用，如果不真正了解你的业务，不了解用户的核心需求，不了解你目标客户的典型行为，是很难做好网站的。从这个角度来讲，一个Web 架构师首先必须是一个出色的产品经理。大多时候，我们只要做到业务技术领先就足够了，一味地追求技术的先进性反倒会深陷泥潭。\u003c/p\u003e\n\u003cp\u003e在技术和业务之间找到一个平衡，也就意味着必须明白整个业务核心的竞争力在哪？目标人群基本诉求在 …\u003c/p\u003e"

"\u003cp\u003e\u003ca href=\"http://blog.evanweaver.com/about/\"\u003eEvan Weaver\u003c/a\u003e 是 \u003ca href=\"http://www.kuqin.com/shuoit/Twitter/\"\u003eTwitter\u003c/a\u003e 服务团队的总工程师，他的主要工作是 优化与伸缩性。在 \u003ca href=\"http://qconlondon.com/\"\u003eQCon London 2009\u003c/a\u003e 上，他谈到了Twitter的架构，特别是在过去一年当中为提升Web站点性能所执行的优化。\u003c/p\u003e\n\u003cp\u003eTwitter使用的大部分工具都是开源的。其结构是用Rails作前端，C，Scala和Java组成中间的业务层，使用MySQL存储数据。所 有的东西都保存在RAM里，而数据库只是用作备份。Rails前端处理展现，缓存组织，DB查询以及同步插入。这一前端主要由几部分客户服务粘合而成，大 部分是C写的：MySQL客户端，Memcached客户端，一个JSON端，以及其它。\u003c/p\u003e\n\u003cp\u003e中间件使用了Memcached，Varnish用于页面缓存，一个用Scala写成的MQ，Kestrel和一个Comet服务器也正在规划之 中，该服务器也是用Scala写成，当客户端想要跟踪大量的tweet时它就能派上用场。\u003c/p\u003e\n\u003cp\u003eTwitter是作为一个“内容管理平台而非消息管理平台”开始的，因此从一开始基于聚合读取的模型改变到现在的所有用户都需要更新最新tweet 的消息模型，需要许许多多的优化。这一改动主 …\u003c/p\u003e"

"\u003cp\u003e从20台服务器到5000台服务器，应该说，校内网的IT基础设施的变迁是与其自身的业务发展成 正比的，而每一次的业务突破实际上也是对数据中心的一个挑战。传统的IT基础建设模式，现在、将来又当如何适应SNS类网站的发展？从Csdn记者此次与 校内网技术总监黄晶的对话中，也许我们可以了解一二。\n\u003cstrong\u003e从20台到5000台服务器\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e作为校内网的CTO，黄晶对过去几年校内网IT基础建设的过程历历在目。\u003c/p\u003e\n\u003cp\u003e“如果要把这个历程分成几个阶段，那么在我看来，校内网的IT基础设施建设目前经历了三个阶段”。\u003c/p\u003e\n\u003cp\u003e黄晶对Csdn记者谈到，第一个阶段是校内网创业的阶段，那时候，校内网的主要推广对象是国内比较好的一些高校，但数量很有限，用户数不太多，访问量也不 大，因此，当时选择了一个IDC并租赁了20台左右的服务器。\u003c/p\u003e\n\u003cp\u003e“随着业务的发展，校内逐渐把业务覆盖到了全国，与此同时，数据量可以呈现几何式的增大，带宽与存储迎来了瓶颈，因此在那时候，公司开始寻找新的IT基础 架构解决方案，并因此而找到了世纪互联做服务器的托管，几年的时间，服务器的数量从几十台上升到了近5000台。”\u003c/p\u003e\n\u003cp\u003e“但问题也随之出现，虽然带宽够大，但是找IDC托管的这种 …\u003c/p\u003e"