IT牛人博客聚合

Intel的Nehalem是一个空前成功的设计。做架构最重要的本事就是学会做折衷（Tradeoff）。 Nehalem的Lead Architect Glenn Hinton在Stanford ee380这门课上详细讲解了Nehalem设计时的几个关键选择，特此分享给大家。

Intel’s Nehalem family of CPUs span from large multi-socket 32 core/64 thread systems to ultra small form factor laptops. What were some of the key tradeoffs in architecting and dev

查看全文: http://www.udpwork.com/item/7191.html

我喜欢写一些小工具来简化我的工作，通常是一些小组件。利用这些小工具我可以提高自己代码的可读性，同时维持我的 DRY (Don't Repeat Yourself) 洁癖。工具对我来说很重要，因为时间对我来说很宝贵。能够用工具自动化完成的事情绝对不手工反复操作，能够用工具避免人为错误的地方一定让工具来确保质量。使用工具节省下来的时间用于玩游戏的话，绝对是值得的！

过去我主要做工具给自己用，或者是给自己所在的团队使用，所以觉得自己就是用户，自己设计产品给自己用肯定是没问题的。然而做工具给更多人用呢？看起来就不那么容易了。之前在百度经历过 Tangram 的需求分析与设计阶段，每个产品线都派出了前端工程师代表参与需求评审，通过多轮的辩论

查看全文: http://www.udpwork.com/item/6461.html

现在开始补日志，逐步的扫清以前写了一半的和“欠账未还的”。半年之前开的头，今天先把NUMA说完。

PC硬件结构近5年的最大变化是多核CPU在PC上的普及，多核最常用的SMP微架构：

多个CPU之间是平等的，无主从关系（对比IBM Cell）；

多个CPU平等的访问系统内存，也就是说内存是统一结构、统一寻址的（UMA，Uniform Memory Architecture）;

CPU到CPU的访问必须通过系统总线。

结构如图所示：

SMP的问题主要在CPU和内存之间的通信延迟较大、通信带宽受限于系统总线带宽，同时总线带宽会成为整个系统的瓶颈。

由此应运而生了NUMA架构：

NUMA（Non-Uniform Memory

查看全文: http://www.udpwork.com/item/5833.html

近两年的网游开发暂时告一段落，这段有时间总结一下。

试图从四个方面聊聊MMORPG的软件架构，：

整体构架

服务器端架构

3D引擎

游戏逻辑

要说的东西很多，其中也有很多不是我所擅长的，尽力而为吧。

查看全文: http://www.udpwork.com/item/5835.html

From various readings and conversations I had, my understanding of Facebook’s current architecture is:

* Web front-end written in PHP. Facebook’s HipHop [1] then converts it to C++ and compiles it using g++, thus providing a high performance templating and Web logic execution layer

* Business logic is exp

查看全文: http://www.udpwork.com/item/5889.html

上个月Jeff Dean在Standford的Computer Systems Colloquium (EE380)这门讨论课上详细讲了讲Google的系统架构发展过程，因为这是份很新的资料，所以特意把它的Slide下下来与大家分享一下。这门课是Standford的讲座课程，每一节课都由不同的顶级工程师/科学家/投资人前来讲授IT行业的最新动向，非常非常有料，绝对值得深挖。这门课的每节课都是带视频的，Jeff Dean的这个讲座的录像在这里。想要下载该视频的同学可以去这里（要会功夫，你懂的）。

这个讲座的主要内容包括：

• Evolution of various systems at Google

– computing h

查看全文: http://www.udpwork.com/item/3656.html

SQL Azure简介

SQL Azure是Azure存储平台的逻辑数据库，物理数据库仍然是SQL Server。一个物理的SQL Server被分成多个逻辑分片(partition)，每一个分片成为一个SQL Azure实例，在分布式系统中也经常被称作子表(tablet)。和大多数分布式存储系统一样，SQL Azure的数据存储三个副本，同一个时刻一个副本为Primary，提供读写服务，其它副本为Secondary，可以提供最终一致性的读服务。每一个SQL Azure实例的允许的最大数据量可以为1GB或者5GB(Web Edition)，10GB, 20GB, 30GB, 40GB或者50GB(Business Edition)

查看全文: http://www.udpwork.com/item/4071.html

目前，知名度比较高的通用存储系统包括：Google GFS&Bigtable，Amazon Dynamo，Microsoft Azure存储系统及Yahoo PNUTS。其中，GFS&Bigtable，Azure存储系统及Yahoo PNUTS都有总控节点，Amazon Dynamo采用去中心化的P2P设计。

Amazon Dynamo看起来很优美，比如Dynamo论文中提到的技术比较酷，Dynamo没有中心节点，可以支持更大的系统规模。然而，Dynamo不是我心目中的理想架构，因为Dynamo有一致性的问题，系统设计复杂但解决的问题有限。如果需要保证一致性，就必须要求同一时刻对同一份数据只有一个更新节点，D

查看全文: http://www.udpwork.com/item/4072.html

Scalable System Design Patterns 一文概括了几种常见的系统设计模式。配图很漂亮，我就索性摘过来，推荐感兴趣的继续围观其博客。

1、Load Balancer

该模式中，一个分发器基于某种策略确定由哪个worker实例处理请求。应用最好是无状态的，以使任何一个worker实例都能同等处理请求。大量的网站都会用到负载均衡器这个模式的。

2、Scatter and Gather

该模式中，分发器将请求转发给多个worker实例，每个worker实例处理完返回给分发器，分发器将worker们返回的结果再加工后再返回给客户端。以搜索为例，通常得AS、BS架构就是这种典型模式。

3、Result Cach

查看全文: http://www.udpwork.com/item/3081.html

highscalability.com上的Playfish’s Social Gaming Architecture – 50 Million Monthly Users and Growing是篇很不错的大杂烩，内容涉及全球第二大social game公司Playfish的技术架构、产品设计、团队协作、产品运营等诸多经验之谈，尤其对初创团队很有借鉴意义。我这里还只是对文中提到的一些技术经验做些汇总，也推荐大家去浏览原文，重点看看自己感兴趣的段落。但说起架构的事情，其实看多了，往往都是大方向上相似，细节上有自己的考量和特点，以形成自己的架构风格。

SOA

SOA在企业应用中热火朝天，但在互联网应用中SOA

查看全文: http://www.udpwork.com/item/2823.html

Top 10 Performance Problems taken from Zappos, Monster, Thomson and Co 一文总结了一些关于性能问题方面的经验，虽然不是很“新奇”，但也算是中规中矩的有借鉴意义，这里分享之。没有对原文做完全的翻译，也欢迎大家直接看看原文，本文转过来还夹杂了一些个人理解，有理解不当的地方也望指正。

1、Too Many Database Calls

这一问题是说在一次请求/事务处理过程中有太多次的数据库调用。典型的情景是：

1）请求了不必要的数据，比如程序员们为图省事而”select * ”出不必要的字段数据。

2）相同的数据被请求多次。这通常出现在同一事务中，彼此独立的组件

查看全文: http://www.udpwork.com/item/2026.html

在highscalability.com上翻看最新的文章，一文 The Four Meta Secrets of Scaling at Facebook 很不错。下面做些简要的中文介绍并续上自己的解读。Facebook的规模及技术水平不消我多说，其对开源社区的贡献更是有目共睹。“The Four Meta Secrets of Scaling at Facebook”不是关于Facebook的技术架构方面的细节，而是在扩展并发展Facebook这样的大规模高复杂增长速度快的网站过程中，积累的4点有借鉴意义的观点。

1、 Scaling takes Iteration

Facebook也是从小网站发展起来的，尽管它的发展速度快

查看全文: http://www.udpwork.com/item/1808.html

本文是Ebay的架构师在2008年发表给ACM的文章,是一篇解释BASE原则,或者说最终一致性的经典文章. 文中Dan讨论了BASE与ACID原则的基本差异, 以及如何设计大型网站以满足不断增长的可伸缩性需求,期间如何对业务做调整与折衷. 以及一些具体的折衷技术的介绍.

原文链接: BASE: An Acid Alternative

Pdf下载链接: Base

在对数据库进行分区后,为了可用性(Availability)牺牲部分一致性(Consistency)可以显著的提升系统的可伸缩性(Scalability).

By DAN PRITCHETT, EBAY ,Translated by Jametong

Web应用在过

查看全文: http://www.udpwork.com/item/1663.html

上周在公司内给Team兄弟的分享, 比较简单.

Oracle数据库体系结构简介.ppt
View more presentations from james tong.

No related posts.

查看全文: http://www.udpwork.com/item/1520.html

今天分享的网站架构来自于Sify.com Architecture - A Portal at 3900 Requests Per Second（该标题有标题党嫌疑），对英文熟稔并不屑于我的中文简述的可以跳过该文。Sify.com是印度的一家portal网站，应该是信息集成类网站。它给出的月pv是1.5亿次，每秒请求数是3900次（应该是针对所有服务的页面请求，包括异步的，并且是高峰的，否则就和pv对不上了）。按规模来说，算是个中等规模的网站，不过它的架构却是很值得说道的。

网站架构

1、为了节约机器资源并最大化利用机器资源，Sify.com也广泛采用了虚拟机。对于同一服务，Sify.com将其部署在多台机器上，使一台机器挂掉后

查看全文: http://www.udpwork.com/item/1643.html

Poppen.de是德国的一家婚姻中介网站，对于该网站的统计数字有：1）2.000.000的用户数，2）20.000的并发用户数，3）每天产生300.000的私信，4）250.000的日登录用户数。这样的网站也就是个中型规模的网站，下面看看这个网站在技术应用及经验方面带来的东西。

原文链接：http://highscalability.com/blog/2010/4/12/poppende-architecture.html

Nginx

Poppen.de使用nginx作为web server，包括静态请求和动态请求。特别的，Poppen.de通过nginx来直接从memcache中获取缓存的动态页面内容而不需要经过PHP，一

查看全文: http://www.udpwork.com/item/1648.html