Twitter 和 Digg 对数据存储引擎的需求相当独特：写操作密集，基本无修改需求，读操作则多数是分散多次读取汇总展示(想象一下你 Twitter页面上同时显示好友们的 Tweet 内容)。对 MySQL 来说，Sharding 后几乎是被当作简单的存储引擎来用的，即使是加上 Memcached ，对数据读取开销相当大(Refer)，因为这时候即使是最合理用索引，I/O开销也不是最优的--走的是索引范围扫描嘛。Cassandra 则相当于预存了计算结果，这要得益于其 Flexible schema 特性，按照既定规则写入，读取直接取预排序的范围键值结果(这其实是偏 OLAP 的应用，而非 OLTP)。

Twitter 和 Digg 这两家网站的数据结构其实并不复杂，尤其是 Twitter ，相当的简约（当然并不简单）。或许有人说，把 Cassandra 开源的 Facebook 不也在用呢吗 ? Facebook 数据结构不复杂么？没错，Facebook 数据结构很复杂，不过使用 Cassandra 的场景其实和 Twitter / Digg 几乎一致的---只是用在 inbox 这个地方的数据处理而已。

不要迷恋 Cassandra ，如果应用场景不合适，那么对你来说永远都只是个传说。。

--EOF--

• 1、适当放弃一致性
• 2、备份和隔离解决稳定性问题
• 3、分割和异步解决性能问题(类似 eBay 的 Asynchrony Everywhere)
• 4、自动化降低人力成本(类似 eBay 的 Automate Everything)
• 5、产品化管理

在这里不妨对比一下 eBay 的架构经验：

• 1、 Partition Everything
• 2、 Asynchrony Everywhere
• 3、 Automate Everything
• 4、 Remember Everything Fails
• 5、 Embrace Inconsistency
• 6、 Expect (R)evolution
• 7、 Dependencies Matter
• 8、 Be Authoritative
• 9、 Never Enough Data
• 10、Custom Infrastructure

关于一致性，可以延伸阅读 Amazon CTO 的大作 Eventually Consistent。此外，强调了"放弃集中的紧耦合处理"的原则。"备份"这里可以理解为"提供可用的副本"。"分割"是说水平拆分。

架构这东西说起来大致原则，其实都是类似的，但是具体如何在一些通用原则上做到运用自如，是很难的事情。前几天我还感慨，很多架构师对与"异步"与"批量处理"所能带来的益处的理解仍然相去甚远。

--EOF--

在 MySQL Conf 2009 上，SmugMug 的 Don MacAskill 做了一次关于SmugMug 网站架构的分享。

SmugMug 整个网站采用 LAMP 架构(其实也有 OpenSolaris)，300 多台 4 核（或更多）的服务器（大多是 AMD 的 CPU） ，分散在四个机房，两个运营的人员。SmugMug 充分运用了云计算服务，是 Amazon 的一个大客户，图片和视频总计达到了 PB 级，托管在 Amazon S3 上，图片和视频的处理也在 Amazon EC2 上。使用了 Akamai 的服务做前端的 CDN 加速，主要是 JavaScript/CSS 等文件的加速，此外，DNS 加速也带来了很好的收益。

结构化数据放在 MySQL 中，存储引擎多数用的 InnoDB，数据超过 2TB 的空间，数据库服务器为 4 核或更高配置，内存多达 64GB。缓存方面，用了 Memcached 做加速，有 1TB 的数据在这里面，平均命中率达到 96%。Memcached 里面尽量存放 MySQL 行数据，减小对 DB 的冲击。数据库设计思路是尽量做垂直分区，没有 Sharding。不过在反范式(denormalized)方面做得比较彻底，不用表连接(JOIN)方法者复杂的查询。多数查询依赖主键，更新或者删除数据也是单行，依赖主键。InnoDB 引擎打了 Percona 的 Patch，并发能力也有了很大增强。

对 DB 的数据完整性与写能力的要求高，而对于读的扩展性还是相对比较好解决。Linux 上的文件系统是 SmugMug 不太满意的地方，备份也成问题。ZFS 倒是能满足相关的需求，可惜不支持 Linux(妈的，早该支持 Linux了)。所以他们迁移到了 OpenSolaris 上。另外，对于复制中可能出现的风险，尝试了第三方提供的一些 Patch (参考 Google 发布的 MySQL Patch)。

采用 OpenSolaris 后，MySQL 放在 Sun Sushi Toro(Storage 7410，这个东西也支持 SSD ) 上，走 NFSv3 协议。写到这里，发现 SmugMug 的解决方案非常不具有通用行，看起来 Sun 是给了他们不小的硬件优惠，否则一般情况下不会有人这么搞的，用 NFS 协议走数据库，除非是测试环境或者是复制(我怀疑只是 Slave 端通过 NFS 走)，产品上真的有人跑么?

网站架构的进化，其实也是选定一个方向(比如用开源工具解决)，然后一直试错的过程。

--EOF--

Image via CrunchBase

学习了一下 Flickr 的运维工程师 John Allspaw 的这个Operational Efficiency Hacks 讲座内容。做一点笔记。

现在 Flickr 的数据相比2007年的时候真是有了显著的增长：

• 24 TB 的 MySQL 数据
• 每秒钟 MySQL 有 3.2 万次写操作
• 每秒钟 MySQL 有 12万次读操作
• 图片容量 6 PB
• 每天要用掉 10TB 存储
• 超过 15000 个服务监控点

在 2004 年的时候 ，Flickr 使用 ImageMagick (version 6.1.9)之后转移到 GraphicsMagick，我还以为是因为版权问题，现在知道这样做是因为速度，换用 GraphicsMagick 处理速度提升了 15%，而 ImageMagick 功能尽管强大，但都是 Flickr 用不到的功能。如无必要，勿增实体啊。GraphicsMagick 在并行方面(OpenMP)的支持也很不错(参考)。

除了技术手段的优化，Flickr 充分利用硬件本身的更新换代带来的好处，曾经用 18 台新机器替换掉原来的 67 台 Web 服务器，用 8 台新机器替换掉原来的 23 台图片处理的机器。无论从机架占用还是电力使用都节省了很多，而整理处理能力并没有削弱。我们总说摩尔定律，但是恐怕很少有人真的享受到摩尔定律带来的好处。Flickr 的做法是很值得学习的一个地方。精兵简政，不要只冲着人下手，动手"裁"掉机器，也会省钱嘛...

Flickr 技术团队随着网站的快速发展并没有增加大量人手，个人生产力的产出是相当的高。如何做到的呢？给出了四个非常有趣的原则：

• 使得机器自动构建 (Teach machines to build themselves)
• 使得机器自监控(Teach machines to watch themselves)
• 使得机器自修复(Teach machines to fix themselves)
• 通过流程减少 MTTR (Reduce MTTR by streamlining)

自动购建上，Flickr 使用了 OpsCode 、Puppet 以及 System Imager/Configurator 等。或许这几个工具值得我们关注一下。

Flickr 团队内部沟通工具也挺有意思，除了内部的 IRC 用于讨论之外，还利用 Yahoo! Messenger 的 IM Bot 记录更多的系统变化，并且，重要的是，将这些信息弄到搜索引擎里面 ... "信息查找"，是国内多数团队交流工具忽视的地方。

最后感慨一下 Flickr 技术团队仍然是非常有活力的团队。最近的另一个消息是国内的 Yupoo.com 原创业团队也即将重装上阵，重新接管 Yupoo 网站，要知道 Flickr 仍然是最有影响力的网站之一，所以，有理由期待 Yupoo 团队的精彩。

--EOF--

目前这棵摇钱树程序代码量有 550 万行之多，程序开发人员有 32 位，当然都是顶级工程师。平台服务部有 245 人，其中 QA 部门自从游戏上线后处理了 18 万个 BUG，惊人！程序差不多似乎千锤百炼了。

《魔兽世界》目前使用大约 13250 台刀片服务器 ，75000 个核的CPU ，内存使用超过 112TB 。服务器数其实并不是特别庞大(国内有些游戏公司，比如盛大，服务器数量也差不多这样)。 不过相信随着接下来几款重量级游戏升级版本的推出，服务器数量会暴增。数据大约有 1.3 PB。服务器分布在 10 个 IDC ，不到 70 个人运营，人力产出很惊人。维护战网的人有 150 个左右。这里面有个有趣的观点是，游戏公司对于服务的可用性要求的看法与电子商务公司的并非一致，只要不是每周都有问题，一个月遇到一次问题似乎不大。算不上致命的问题，应该是用户忠诚度更高的缘故吧。看看国内的戏剧性起伏就知道了。

另外，据我了解，魔兽计费的数据库是采用的 Oracle RDBMS 。2006 年的时候大概是跑在 RedHat 上，单个 DB 超过 1T 的数据，且据说要迁移到 HP 平台。但还不了解如何跨多个 IDC 同步 DB 数据，或许简单的分片就成了，这是面向游戏的应用设计上唯一不费力的地方。

Note: 先大致描述个轮廓，等以后了解更多再逐渐补充。

--EOF--

• GDC Austin: An Inside Look At The Universe Of Warcraft
• Blizzard outlines massive effort behind World of Warcraft
• Iceland: New Hot Spot for Data Centers?
• Refer Solidot

程立在 SOA 功底深厚。上次在 InfoQ QCon 会议上程立的话题也是有关 SOA。本次演讲内容侧重与上次侧重点不同。只是因为会议时间有限，所以有几页没有完全展开来讲，稍稍有点遗憾。

感谢程立。大家针对该 PPT 有任何问题的话，请留言或者发邮件给我，我将第一时间转给他。

关于 PPT 作者：

程立是支付宝公司的首席架构师。他从2004年起参与支付宝与淘宝网的建设，2005年正式成为支付宝人，随着支付宝的业务与技术的成长，从开发工程师、架构师到首席架构师一路走来，全身心投入并见证了支付宝业务与系统发展的完整过程。

支付宝一直在招聘软件架构师，我们是 Java 开发环境。如果您对支付宝感兴趣，并且想让自己做的东西服务于两亿多的用户，不妨联系我们或者直接发简历到: dbanotes@gmail.com 。

--EOF--

3PAR 在 1999 年成立，几个创始人主要出自 Sun ，前身叫作 3PARdata ， 2008 年上市。要知道在存储技术领域竞争还是比较激烈的，EMC / HDS 等控制着高端存储的主要市场，3PAR 能突破技术壁垒并最后成功上市，没两把刷子那是绝对做不到的。

InSpire 硬件结构

3PAR 背板采用全网状的连接结构，每个控制器节点之间高速直连。因为是全网状的，所以基本上一个链路坏掉只影响直连的两个节点的通信，对其它节点无影响。每个控制器节点内置一块硬盘，用于操作系统安装。控制器节点最多可以扩展到 8 个，是 3PAR 存储最核心的组件。

相比之下，HDS 架构采用全光线交换方式（Universal Star Network），而 EMC 是采用直连矩阵方式(新一代产品采用虚拟矩阵架构--Virtual Matrix ，其实已经放弃了直连矩阵架构了)。这些连接方式的孰优孰劣历来是厂商攻击竞争对手的着眼点，能否最大限度发挥性能是用户最需要关心的。

3PAR 针对 I/O 指令和数据移动使用不同的计算芯片。I/O 指令(元数据/控制Cache)用 Intel 的芯片，而 数据移动/Cache 则使用专门设计的 ASIC 芯片来完成。

因为有专门的硬件 ASIC 芯片用于 RAID 5 XOR 校验，3PAR 号称有了其第三代 ASIC 芯片，实现的 RAID 5 是业界最快的，甚至 SATA 盘也能有不错的性能表现。(从 Oracle 公司测试的数据来看，和 RAID 10 速度的确相差无几。)

InForm 操作系统软件与虚拟化

3PAR 的操作系统叫 InForm，最初就是面向层次化的设计。与其他存储不同的是，3PAR 所有磁盘被分成 256MB 统一大小的小盘(Chunklet)，可以根据需要用多个 Chunklet 组成 RAIDlet(逻辑磁盘)。因为这个独特的设计方式，3PAR 是可以很容易做到不同容量的磁盘混用，同一个 RAID 组里都可以有不同大小、不同转速的磁盘混用，这是其他存储做不到的。而且，所有的磁盘都可以利用，因为Hotspare Chunklet 以更小的单位分散在不同的磁盘上，也不再需要单独留热备盘。空间利用率可以更充分一些。　

多说一句，有这个冗余机制，3PAR 更换磁盘也是与众不同：直接抽磁盘盒子(一个盒子可是四块磁盘啊)，我当初看到 3PAR 技术人员这么操作真是着实吓了一跳。

因为固定大小的 Chunklet 的存在，可以将 I/O 更为均匀的分散到多个磁盘上。

对于熟悉Oracle 的朋友来说，会发现这和 ASM 的思想非常接近。因而也可以和 Oracle 数据库进行无缝集成：

因为软件做得非常具有易用性，日常管理与维护远远没有其他高端存储那么复杂，新增磁盘这种事情，都是一行命令之后底层自动处理。其实在 Thin Provisioning 方面 3PAR 也是很值得一说的，比一些厂商的伪 Thin Provisioning 具体多了。限于篇幅，不赘述。

3PAR 在美国有很多金融证券行业的客户，也有 Web 2.0 行业的客户--MySpace 。在保证 I/O 响应在 10ms 以内的前提下，3PAR 的 IOPS 能力非常优异(这才是卖点，不难理解其客户多集中在证券、金融领域)。虽然有些厂商号称能得到更高的 IOPS ，但那是在 I/O 响应时间很差的情况下的数据。要说明的是，现在随着一些存储厂商在高端服务器上也支持 SSD ，未来几年如何还要再看。

前两年 3PAR 推行所谓 Utility Storage(功用存储) 理念，现在貌似改成敏捷存储了。说实话，我觉得敏捷存储真的挺适合的，3PAR 命令行批量创建 LUN 真的很让人感觉舒服。当然，也在宣传云存储和绿色存储的理念，那是题外话了。

3PAR 原来只做中高端市场，只有 T 这一个系列，现在也开始关注中低端市场了，推出了 F 系列的产品。软硬件体系基本没变，倒是没仔细看过。

(Note: 相关图片主要来自 3PAR 公开资料.)

--EOF--

国内很多互联网公司关心 IDC 电力问题，可能有一部分是受了一些美国公司(尤以 Google 为代表)的影响。根据美国环境保护署的预测数据，到了 2011 年，美国数据中心消耗的电力将达到 1000 亿千瓦--这个数字够惊人的，这个问题如果放到美国的大环境上来看可能又不算什么，因为这个数字占美国总耗电量的比例 大约是 2.625%。那么中国呢? 考虑到中美能源利用效率的差异，我想现在数据中心用电量绝对不会超过 1%。Google 这类公司强调节能、绿色 IDC 之类的说法有他们的理由，且不说提高企业形象 -- 在欧美如果大企业不提倡环保，还不被那些环保组织骂死 ? 另外，省钱也的确是硬道理。此外，有一大票鼓吹绿色 IT 的家伙是各色商业公司，当然，宣传的目的是为了多购买他们的"更加省电"的产品。

中美电力使用的一个巨大差异是，美国工业用电与商业用电相对比较便宜，而居民用电反而比较贵。在中国倒是相反，居民用电相对便宜，而工业用电和商业用电是比较贵的(前不久的发改委才要求工业、商用同价格，参考)。考虑到地域差异，以及各种因素，美国居民用电平均大约 10 美分左右(信息来源)，而国内的价格，是一笔糊涂账，我所居住的杭州，正常时段的价格要超过 0.55 元，而且根据用电量大小、时间、类型等等有不同的计算价格，以我这个智商恐怕算不清楚的。不管怎么样，中美的居民用电价格是相差不大的，考虑到中美人民的收入，这里面实际差异还是很大的。(国内在 2008 年 7 月 1 日曾经提过一次电价，每千瓦时提价 2 分 5 厘-- 看似很小的涨价? 这意味着每年就可以多收近千亿的人民币。嗯，有点跑题了。) 限于这多少算技术贴，其他层面的东西就不说了。

工业用电价格贵，那么似乎的确应该节电了? 在目前国内，有一些数据中心的确已经面临电力问题，但这些问题集中在 IDC 如何抢到电力资源(毕竟不同地区电力资源分配不均衡)，而不是如何少用电，更为关键的是，你少用你那么一点点电(本来就没多用多少)，可能真的解决不了什么问题，因为如果收费的标准不根据你用了多少电来衡量 -- 体现到经济效益上来也就不会有多大，要是新闻联播每天少播 5 分钟，那全国要节省多少电阿... 很少有 IDC 根据电力对用户收费，更多还是根据物理空间、网络带宽等指标收费。作为用户一厢情愿的考虑 IDC 的问题乃至环保，或许还有点早(不是说不重要，而是这个问题不是我们最迫切的事情，当然，有这样的想法还是好的，是值得肯定的)。个人觉得提升计算性能充分发挥机器能力或是提供更好的产品给用户，可能也会节省大量资源，产生更大的经济效益。既然丁磊都说了"企业最大的慈善就是把产品做好"，我们可以套用一句，做好产品、给用户提供更好的体验也是环保...

对了，我那句武断的话是(洁本)：

三年内，中国网络公司不用担心电力太贵；五年之内，不需要讨论环保问题。

不是这方面专家，引用的数据或许有误，当然，我的结论也明显有问题，您就对付着看吧。

--EOF--

• 附1、中国电力平衡表(2008) 。缺电还是不缺电，一目了然。

电这个问题，如果 IDC 抢到的少，即使你用的少，别人也同样会用得多。经济因素影响真的不是那么大。

更新一下结论，IDC 如果抢不到电力，别的说什么都是收效甚微的事情。

Twitter 运维团队的职责：

• 软件性能(后端) Software Performance (back-end)
• 可用性 Availability
• 容量规划 Capacity Planning (metrics-driven)
• 配置管理 Configuration Management

看完这个接近 50 页的 PDF ，除了满足我们一小部分技术窥探的癖好，或许也可以学到点什么。

不重复发明轮子

对于监控，Twitter 用的就是 RRDtool，Ganglia、MRTG 这些已经成为很多网站标准配备的组件。而不是自己写一大堆功能重复的东西。值得注意的是， Twitter 也一直在用 Google Analytics 进行业务分析。

不重复发明轮子，可以打磨轮子，比进行如一些功能脚本定制之类的工作。

发明不重复的轮子

Twitter 开源了他们自己用的一个 Apache 模块 mod_memcache_block（a distributed IP blocking system），这个模块根据 HTTP 代码请求限制访问频率。熟悉 Twitter 的朋友会知道这是针对第三方应用程序的必须的一个功能，否则的话，会产生类似 DDos 的效果 :) John Adams 说这个模块是他多年以来就期待的东西，我相信，如果有人已经做了同样的事情，他们肯定不会自己再写一个。

尽可能的自动化

无论是配置管理还是针对各项功能的"开关"，都尽可能的自动化。依赖于人来控制一些事情容易"规范"，但是流程冗杂，节奏变慢。

更好的理解硬件

拥抱新技术体系，使用更有经济效益的硬件(比如对 8 核 CPU 的选型与更换)会带来更好的收益。而这个要建立在对硬件体系的正确理解上才行。

另外几句话要记住：

• Disk is the new Tape. (内存是新类型的磁盘. 磁盘是新类型的磁带)
• Kill long running queries before they kill you. (问题是如何提前发现? 有效的监控!)
• Use metrics to make decisions, not guesses.
• "Cache Everything!" not the best policy

或许还应该学到更多...

--EOF--

在 1987 年，Jim Gray 与 Gianfranco Putzolu 发表了这个"五分钟法则"的观点，简而言之，如果一条记录频繁被访问，就应该放到内存里，否则的话就应该待在硬盘上按需要再访问。这个临界点就是五分钟。看上去像一条经验性的法则，实际上五分钟的评估标准是根据投入成本判断的，根据当时的硬件发展水准，在内存中保持 1KB 的数据成本相当于硬盘中存储同样大小数据 400 秒的开销(接近五分钟)。这个法则在 1997 年左右的时候进行过一次回顾，证实了五分钟法则依然有效（硬盘、内存实际上没有质的飞跃)，而这次的回顾则是针对 SSD 这个"新的旧硬件"可能带来的影响。

随着闪存时代的来临，五分钟法则一分为二：是把 SSD 当成较慢的内存（extended buffer pool ）使用还是当成较快的硬盘（extended disk）使用。小内存页在内存和闪存之间的移动对比大内存页在闪存和磁盘之间的移动。在这个法则首次提出的 20 年之后，在闪存时代，5 分钟法则依然有效，只不过适合更大的内存页(适合 64KB 的页，这个页大小的变化恰恰体现了计算机硬件工艺的发展，以及带宽、延时)。

根据数据结构和数据特点的不同，对于文件系统来说, 操作系统倾向于将 SSD 当作瞬时内存(cache)来使用。而对于数据库，倾向于将 SSD 当作一致性存储来用。

这是一篇非常重要的文章(所以，建议读一下原文），其中对于数据库一节的描述尤其有趣（针对 DB 也有个五分钟)。限于篇幅，就不罗嗦了。

--EOF--

其实现在很多公司可能都面临着这个抽象架构图中的类似问题。以 Hadoop 作为后端的计算集群，计算得出来的数据如果要反向推到前面去，用什么方式存储更为恰当? 再放到 DB 里面的话，构建索引是麻烦事；放到 Memcached 之类的 Key-Value 分布式系统中，毕竟只是在内存里，数据又容易丢。Voldemort 算是一个不错的改良方案。

值得借鉴的几点:

• 键(Key)结构的设计，有点技巧；
• 架构师熟知硬件结构是有用的。越大的系统越是如此。
• 用好并行。Amdahl 定律以后出现的场合会更多。

关于 key-value 应用的解决方案又多了一种。LinkedIn 对此应用案例也还在发展中。如果业务类型类似，不妨关注一下。

--EOF--

如果站点起步阶段可能就是一台机器(或是一台虚拟机，比如 JobsDigg.com )，这个时候，去关注什么数据拆分啊，负载均衡啊，都是没影子的事情。很多大站点的经验绝不能照搬，辩证的参考才是硬道理。

拥抱熟知的技术

动手构建站点的时候，不要到处去问别人该用什么，什么熟悉用什么，如果用自己不擅长的技术手段来写网站，等你写完，黄花菜可能都凉了。所以，有现成的软件组件可用，就不要自己重新发明轮子。人家说 Python 牛，但自己只懂 PHP ，那就 PHP 好了，如果熟悉 .net ?，那也不错。用烂技术不是丢人的事情，把好技术用烂才丢人。

架构层次清晰化

起步的阶段应该清楚的确定下来架构的层次。如果都搅和在一起，业务一旦扩增开来，如果原有的一堆东西拆不开就是非常痛苦的事情。

Web Server <--> (AppServer)<-->Cache(eg. Memcached)<-->DB

层次清晰化的一个体现是(以 LAMP 架构为例)：即使只有一台机器，也应该起个 Memcached 的实例，效果的确非常好--一般人儿我不告诉他...不要把什么都压到 DB 上，DB 一旦 I/O 压力走到磁盘上，问题要暴露出来是很快的。没错，DB 本身也会利用自己的 Cache，但 DB 的Cache 和 Memcached 设计出发点毕竟不一样。

数据冗余? 有必要

很多人并不是数据库设计专家，如果应用要自己设计表结构什么的，基本都是临时抱佛脚，但三个范式很多人倒是记得牢，这是大多数小型 Web 站点遇到的一个头疼事儿，一个小小的应用搞了几十个表... 忘掉范式这个玩意儿! 记住，尽可能的冗余数据，你在数据层陷入的时间越多，你在产品上投入的就会越少。用户更关心的是产品的设计。

前端优化很重要

因为流量低，访客可能也不多，这时候值得注意的是页面不要太大，多数流量低的站点吃亏就在于一个页面动辄几兆(我前两天看到一个Startup的首页有4M之大,可谓惊人)，用户看个页面半分钟都打不开，你说咋发展? 先把基本的条件满足，再去研究前端优化。

功能增加要谨慎

不是有个 80/20 原则么? 把最重要的精力放在最能给你带来商业价值的地方。有些花里胡哨的功能带来很大的开销，反而收效甚微。记住，小站点，最有价值的是业务模式，而不是你的技术有多牛。技术是为业务服务的，不要炫技。

有些网站不停的添加功能，恰恰是把这些新功能变成了压死自己的稻草。

从开始考虑性能

这一点是可选的，但也重要。设计应用的时候在开始就应考虑 Profile 这件事情。一套应用能否在后期进行有效优化和扩展，很大的程度限制在是否有比较合适的 Profile 机制上。需要补充的是，对性能的考虑必然要把有关的历史数据考虑进来。另请参见网站运维之道的容量规划以及其它小帖子。

好架构不是设计出来的

这是最后要补充的一点。好的架构和最初的设计有关系，但最重要的是发展中的演化：

发展-->发现问题-->反馈-->解决问题(执行力)--> 改进->进化到下一阶段--新问题出现(循环)

有些站点到了某个阶段停足不前，可能卡在执行力这个地方，来自用户的反馈意见上来了之后，没有驱动力去做改进。最后也是死猪不怕开水烫了。最怕听到的就是"业务不允许"的托词，试想如果不改进业务都没了，那业务还允许么? 其实就是一层心理障碍。

这篇文章有浓重的山寨风格，所以，你不要太认真。如果在用短、平、快的方式构建某些山寨网站的话，可参考其中对你有益的点，不赞同的地方可以直接忽视掉，就没必要费力留言进行争论了。

--EOF--

• 好的业务模式(产品) + 很好的技术 = 大赚钱
• 好的业务模式(产品) + 能用的技术 = 也赚钱
• 差的业务模式(产品) + 好的技术 = 赚吆喝(现在的SNS就差不多这样了)
• 差的业务模式(产品) + 差的技术 = 自己浪费资源

不过，eBay 这次的PPT 总算还是有点更新的。

1）数据分片(Partition Everything)

说是分区(Partition)，这里不能简单等同于 Oracle 的分区，理解成分片(Sharding)就好啦。可以参考一下我以前写的科普小文：开源数据库 Sharding 技术 (Share Nothing)。这里要强调一下的是，分片是在数据量的确有规模的时候才适合进行，如果单节点足以应付，那么还是不要冒进。

从分片的模式上，eBay 主要根据功能切分(Functional Segmentation)和水平分割(负载均衡考虑)，作为推论，所有会话都是无状态性的。

2）异步处理(Asynchrony Everywhere)

其实对于任何网站来说，过度追求"同步"化设计还是比较糟糕的做法。以用户能观察到的数据为视角进行设计，中间可以最大限度用异步来完成。

eBay 的举例的模式有两个，一个是事件队列(Event Queue)，另一个是信息分发(Message Multicast)。前者基本上是个生产者--消费者的模型。后者主要用在搜索的架构上。

注意到图中的消息总线，这才是 eBay 整个架构中的动脉，估计轻易不会批露技术细节

3）自动化(Automate Everything)

这里的自动化举了两个例子，一个是针对运维方面的，另外举了关于机器学习的东西，这是演讲者 Randy Shoup 的强项所在。

eBay 的自动化，在一年前的另一篇文章里可以窥测一点东西。只是这篇文章当初没有被更多人重视，参见：eclipse at eBay。可以看到 eBay 能在自动化方面做得这么好(起码敢出来讲)不是一朝一夕之功。

4）故障检测与回溯(Remember Everything Fails)

更好的失败检测机制: 监控每天超过 2TB 的日志，根据日志中的相关事件得出判断或者预警。这个看起来简单，但实现起来还是需要一点技巧和策略的，重要的是，需要不断根据结果的反馈去改进。

完美回滚: 任何服务都通过服务配置中的标记来识别，无痛回滚。(个人感觉这个非常有难度，尤其是升级的时候)

优雅降级(Graceful Degradation)：能够相对容易的对应用标记"Marks down（下线）"

5）拥抱不一致性(Embrace Inconsistency)

举了 CAP 原则，程立将其形象描述为帽子戏法，非常准确。说起一致性，自从 Amazon CTO Werner Vogels的 Eventually Consistent 一出，基本上不需要我废话了，这就是事务处理的九阴真经，大家回家慢慢参详好了。

eBay 也有自己的绝对准则: 绝对没有分布式事务(两阶段提交), 通过状态机与操作顺序最小化不一致性，通过异步事件(消息总线?)达到最终一致性。

--EOF--

另外小道消息：Amazon CTO Werner Vogels 可能会参加六月份在杭州举办的侠客行大会。

以前的老帖子：eBay 的Scalability最佳实践

缓存

缓存黄金原则：让数据更靠近 CPU。

CPU-->CPU 一级缓存-->二级缓存-->内存-->硬盘-->LAN-->WAN

讲到了 Youku 自己的内部项目，针对大文件缓存的。目前开源软件中，Squid 的 write() 用户进程空间有消耗，Lighttpd 1.5 的 AIO(异步I/O) 读取文件到用户内存导致效率也比较低下。Youku 不用内存做缓存(避免内存拷贝，避免内存锁)。值得注意的是，缓存技术容易被滥用，也有副作用，比如接到老大哥通知要把某个视频撤下来，如果在缓存里是比较麻烦的。

数据库

优酷对数据库 Sharding 做了不少尝试，而且实现效果应该不错。DB 读写分离上有比较丰富的经验。

为了提升数据库 I/O 能力，启用了 SSD 。6 块 SSD 做 RAID 。我在 Twitter 上发了一则 Youku 使用了 SSD 的消息，很多朋友以为是用来存储视频文件，这里需要澄清一下--只是局部使用。

网络吞吐量优化

这是我强烈要求加上来的一节内容。网络优化，视频网站肯定都做得不错。这一节的关键词是 "事件(event)驱动"，令人深刻的一句话是 "ePoll 推动当今 Web" ，的确，现在很多比较热的 Web 组件都是以 ePoll 为卖点。

延伸阅读: The C10K problem (我一直想翻译一下这个页面，苦于腾不出时间) 与 Libevent 如果做互联网，遇到扩展性问题，这两个信息点还是避不过去的。

最后一个例子是针对 Memcached 的 Agent 的，这一点和 Facebook 架构中的 Memcached 处理可以对照来看。

演讲结束的时候，有人提问优酷对视频缓存上有什么特别的地方? 回答是一个大视频可能分成多个小文件，这样缓冲的时候就效果更好一点--(并行啦)...其实访问优酷的确比土豆快那么一点点。

--EOF--

PPT 过几天 InfoQ 中文站会发布。稍安勿躁。

设计原则

• 尽可能的使用开源软件，并且在需要优化的时候进行优化
• Unix 哲学。包括，模块化原则；整合化原则；清晰化原则等
• 任何组件具备扩展性
• 最小化故障影响
• 简化，简化，简化！

架构概览

Facebook 是 LAMP 的坚定支持者，也差不多是用 LAMP (或许用 LAM²P 更适合) 实现的最大的动态站点。

基础组件加上服务，中间用自己实现的一些工具进行粘合。其中关于运维细节的事情基本不会说出来的，这是很多公司的软实力所在。

PHP 经验

参见《Facebook 的 PHP 性能与扩展性》

MySQL 经验

• 主要用于做 Key-Value 类型的存储操作，数据随机分布在多台逻辑实例上，访问多数基于全局 ID 。
• 逻辑实例分散在多台物理主机上(超过1800台)，负载均衡在物理层进行。
• 不做读复制。
• 尽量不做逻辑数据迁移(成本太高)。
• 不做 JOIN 操作 (豆瓣在 QCon 上也阐述了这一点)。数据是随机分布的，关联操作反而带来了极大的复杂度。
• 对于数据访问，主要的操作集中在最新的数据上，针对这部分做优化，旧的数据进行归档。
• 在中心 DB 绝不存储非静态数据。
• 使用服务或者 Memcached 进行全局查询。

Memcached 经验

参见我以前的笔记：Facebook 的 Memcached 扩展经验。Facebook 对 Memcached 做了不小的改进。另外，顺便说一下，前两天 Memcached 刚在 1.2.7 发布几天之后又发布了新版本 1.2.8，修正了一些问题。

一个比较有价值的是关于个人页面数据的获取的描述。这个就完全是需要做单页面 Benchmark 的细致活儿了，可能还需要产品经理能够理解工程师的"抵抗"。

• 获取个人信息数据：通过Cache，隐性通过用户所在的 DB 获取(基于 User-ID 获知 DB)
• 获取朋友连接信息：通过Cache，否则的话通过DB(基于 User-ID 获知 DB)
• 并行抓取每个朋友的 10个照片相册 ID ，从Cache抓取，如果失效，再从 DB 抓取(基于相册 ID)
• 并行抓取最近相册中的照片数据
• 运行PHP 把整个业务逻辑跑出来
• 返回数据给用户

然后是对 Facebook 非 LAMP 体系的东西做了一番介绍，基本上也开源了。最后参考两个架构图。

Facebook NewsFeed 的架构示意图

Facebook 搜索功能的架构示意图

管中窥豹，盲人摸象而已。

--EOF--