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 的消息，很多朋友以为是用来存储视频文件，这里需要澄清一下--只是局部使用。

网络吞吐量优化
这一节的关键词是 "事件(event)驱动"，令人深刻的一句话是 "ePoll 推动当今 Web" ，的确，现在很多比较热的 Web 组件都是以ePoll 为卖点。

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

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

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

-----而听完淘宝架构后回来综合会议室时，刚好听到豆瓣架构演讲的提问阶段，谈到豆瓣的文件存储系统也是将一个大文件分成文件块存储，以实现并行读写的效率，每个文件块存放到三个不同的设备上，也实现容错性。

这个架构思想和腾讯的也差不错。

由于优酷网的业务特点是视频分享，业务比较简单，架构重点也在充分挖掘视频播放的性能上，主要体现在CDN和存储优化上。

从网上资料了解到优酷网采用服务器直连式存储（DAS）架构，即一台服务器只连接一台存储阵列。

优酷网目前有数千台服务器。

用户访问量持续成倍增长，对系统的性能、成本和可扩展性都造成了很大压力。

采用DAS存储可以更好地满足对性能的需要。

如果采用SAN存储，不仅成本增加会十分明显，而且在系统变得日益庞大时，性能也会出现瓶颈。

不采用RAID技术，而且能够提供更好的I/O性能。

优酷网采用了自建的内容分发网络（CDN）技术，所有视频在不同的城市都有副本，不用担心数据的安全性。

即使某地的一段视频发生了损坏，用户也可由实时的调度系统引导至其他CDN站点进行视频浏览。

在优酷网的内容分发网络中，局部失效不影响整体访问，实际上比存储网络的安全性更高。

我们的邮件可不能采取这个存储策略，用户邮件和视频文件是不同安全级别的文件，显然用户邮件文件必须要用高可靠的存储。