QCon会议笔记-架构案例和实践(理论不懂就实践)

QCon会议笔记（架构案例&实践篇）

rouse整理 2009-4-13

有关大容量高并发网站架构，我参加了ebay、淘宝、优酷三家的架构实践演讲，豆瓣网和淘宝的演讲同时举行，鱼掌不可兼得，由于淘宝网属首次介绍架构，而豆瓣以前有了解，且网上资料较多，故没有参加豆瓣网的演讲，事后了解到这次豆瓣网的架构讲的比较细，不能不说是一个遗憾。现分别介绍：

《来自eBay的教训——可扩展站点的最佳实践》

Randy Shoup eBay市场架构组的杰出架构师

ebay提到了构建大型高容量系统的原则和实践，集中阐述了实现可扩展性的5个架构原则：

1、分割（按功能分离、水平切割、无状态化）

2、异步（事件队列、消息多播）

3、自动化（适应性配置、机器学习---在恰当的时间适当的地方推出合适的内容）

4、关注异常（异常捕捉、回滚、优雅降级、记录所有的错误、当系统出现严重的错误的时发消息出来，可以通过订阅消息来实现错误修正等，有点类似erLang的容错）

5、拥抱非一致性（选择合适的一致性精度--以牺牲不必要的实时一致性换取分布计算、避免分布事务）

在阐述上面五个基本原则时Randy Shoup始终遵循一个原理：对一个数据系统，下面的三个属性永远只有两个可以同时拥有：

1、数据在任何时候都是一致的（实时一致性）

2、数据是分开保存的（数据是分散的）

3、系统在某些部分（例如硬件故障）发生错误的时候仍能正常工作（容灾容错）

例如，ebay的数据是分散的（因为要做数据分片），系统有容错的需求（因为ebay有很多的服务器，几乎每时每刻都有这台或那台服务器出问题）因此就只能牺牲数据的非必要实时一致性来保证后面两个特性。

由此想到上次产品经理提出的对种子短信进行实时统计的需求，当时经评估建议只做到非实时一致性（最终一致性）：在某用户发送种子短信时，只显示对该种子短信统计的局部一致性，即用户自己操作且能感受到这个变化，其它用户的操作不即使反馈到这个用户的视图中，但在下次登录时，该用户可以感受到全局一致性。这种思想应该是与ebay的架构原则是一致的。

作为一个有着大量交易行为的的电子商务网站，ebay不使用分布式事务，对于非分布式的也用的很少，仅仅在拍卖交易这一处使用（这儿要求实时一致性）。后来在淘宝的演讲中，我们得知淘宝也是基本上也不使用事务。

看来英雄所见略同，大型电子商务系统，需要谨慎的使用事务。电子商务系统追求的是最终一致性（eventually consistency）而不是实时一致性（immediately consistency），最终一致性不需要采用数据库的事务的方式来实现，而可以采用类似于现在银行的支付系统的定期对账的方式来实现。ebay认为，就算是银行的金融系统，也是不需要实现实时一致性的。

从三家的的演讲中，可以总结出构建大容量系统的共同的“模式”就是分片和异步。ebay 还提到一点就是将一切都自动化（automate everything），其他两家好像都没有提到这点。

《基于Java构建的淘宝》

岳旭强，淘宝网技术专家

第一阶段LAMP架构，交易系统还是在一个开源的项目上改的。最初只用了一台服务器，目前还供奉着。-----典型的开源山寨版网站、两层集中式架构

第二阶段随着业务发展，首先出现瓶颈的是mysql，那时候的mysql master-slaver架构不成熟，延迟厉害，不能适应业务发展，后来改为oracle。-----高级两层集中式架构

第三阶段业务继续发展，开发团队逐渐增大，php在并行开发方面表现出劣势，且php面向对象开发不够彻底，缺乏开发工具，也不容易实现长连接，导致oracle的连接过多，就将php改为java。使用java后，应用服务器使用weblogic。----J2EE架构（三层集中式架构）

第四阶段业务发展迅猛，淘宝的更新类业务操作比重较大，oracle也出现了瓶颈，遂将oracle按功能实现分库分表，架构上同时增加数据透明访问层，实现对应用层的透明访问。----三层分布式架构

第五阶段又局部使用mysql，jboss。---有返璞归真的迹象，可能是开源项目的稳定性和功能得到诸多成功网站的实践和宣传，重获信心。

点评：从淘宝网的架构历程可以看到，每次架构都是由于为了适应业务的发展而作的调整。虽然有被动适应之嫌，但也不能不说每次架构调整都有很强的针对性，且很好的解决了问题。有意思的是淘宝网经历了一个从简单到复杂再到简约的过程。可以看到其受业界技术的思潮影响较大。从建站初期的以快速搭建为目的，即选用了LAMP，后来J2EE炒得很热，淘宝也难独善其身，加入了J2EE的浪潮之中，结果发现EJB等技术的艰涩难驾驭，后来选择了简约之路，构建了自己的轻量级MVC框架，可谓遵循了“核心代码必须自己实现”的原则。到目前，又逐步使用mysql和jboss，是与开源社区活跃和开源项目发展迅速分不开的。

提问阶段，当问到容灾措施时，以不便透露为由搪塞过去，感觉对技术细节还是比较谨慎。

《从优酷网谈大型网站架构》

邱丹(优酷网开发副总裁，核心架构师)

结构是典型的LAMP，由于视频网站对技术的要求有些不同，他们在mysql的使用(分库、分表、复制等)、大文件的分布式存储、缓存、网络流量控制上的经验非常丰富，并且做的也挺不错，绝对的互联网型技术代表：简单实用。

缓存

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

CPU =》CPU 一级缓存=》二级缓存=》内存=》硬盘=》LAN =》W AN

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

接着谈到视频业务的“长尾效应”，即一个视频的访问热度与视频的新旧没有很大关系，有时候很久远的视频也被用户翻出来看，意味着优酷网的数据区分在线、离线的意义不大，视频文件不能归档，优酷网对视频信息也会区别对待，只是区分的标准在于访问热度。访问频率高的视频会根据访问用户地址在各CDN站点间重新分布，并且会存放在SAS硬盘上，而冷门视频则会存放在速率稍慢的SATA硬盘上。表明优酷网采用了两级缓存技术，热点视频放在一级缓存里，其它放在二级缓存里。

数据库

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

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

网络吞吐量优化