易栈网-膘叔

好象这次KESO的《Google一次的能耗》引起了很多人的关注，特别是在QQ微勃上面，有人的转贴就是：不知道http://url.cn/0k4vVU消耗多少,硬件软件有重新设计过吗?|| 腾讯科技  keso炮轰人民网

KESO的原文不长，我这里稍转一下，三言二拍：Google一次的能耗：

人民网上有一篇文章，说每次Google搜索的能耗，相当于100瓦灯泡工作一小时。其中充斥着大量的错误，既有原文的错误（原文在此），也有翻译的错误。

比如，翻译中说，“谷歌数据中心拥有近100万台服务器，每台服务器每小时消耗大约1000瓦的电量”。瓦特是功率，不是电量，电量我们一般用度 （千瓦时）来表示。再比如，“这个搜索引擎每小时产生近1000万个搜索结果”，实际上，早在2001年，Google每天的搜索请求量就超过了1亿次， 今天这 一数字早已超过10亿次（Twitter的日查询次数，包括各种客户端的请求，都高达6亿次）。

上面是明显的错误，其他错误还包括，按每台服务器功耗1000瓦的标准计算Google服务器的能耗，也是相当不靠谱的。普通PC服务器的功耗，一般在400-500瓦。Google的服务器、机房、电源、甚至冷却系统，都是自己设计生产的，按照Google公开的数据，Google服务器的电能转换效率是业界最高的。

而且，把全部服务器的能耗，平均到每次查询上，也非常不靠谱。Google每天要存储20PB的UGC数据（相当于20,000TB，或者 20,000,000GB），假设每块硬盘的容量是1TB（1000GB），那么用户每天产生的内容要写满2万块硬盘。在Google庞大的数据中心中， 有大量服务器实际上是存储服务器。

按照Google自己的计算，一次搜索查询的能耗，大约只相当于0.0003度（千瓦时），或者1千焦（1千瓦时=3600千焦），如果是100瓦的灯泡，这些能量只能点亮11秒钟。

写到这里，我觉得这种计算其实挺无聊的。Google当然会想尽办法节省能源，毕竟它的百万规模的服务器数量，在节能上哪怕非常微不足道的一点小进步，都意味着巨大的资金节省。能源账到底该怎么算，恐怕不是个简单的算术题。

节能是必要的，也是可能的，但搜索技术带来的巨大的社会进步和其他损耗的减少，是在上面的计算中完全看不到的。能源账到底该怎么算，恐怕不是个简单的算术题。

--EOF--

转载的文章嘛。不多点评，不过我是知道国内大多数的机房，其实有很多都在空转着。大量的电力、网络都被IDC消耗掉了。不过想想也很正常，承租机柜后如果没有业务，机柜怎么办？关掉？而且，即使你用的电源低于标准的400W，也没有减少他们应收的费用。更加让人郁闷的是，国内很多大型网站的老总都是这么认为的：能用钱解决的问题就不是问题（比如，服务器、带宽等）。因此，说google的时候，考虑一下自己才是重要的。

国内，好象就听说阿里有自己的机房，不知道他们在缴纳每年的电费时，是否也在考虑着要节约电力？要思考如何改进架构？至于我们这些P民，用着租来的、托管的机器，或许，想的是真的要少一点吧？

标题这种话已经在被很多人所理解，现在大多数开发人员已经不再把语言当成障碍，而是把思想当成障碍，语言的跨度其实真的很容易解决，但思想不进步，你有着再好的语言又怎么样？即使你用的是所谓的自然语言（即平时生活中的语句），但只要你没有思想，没有逻辑，你又能写出什么样的程序？

以下内容来自老王参加的某大会的记录、摘要。我是看中其中的一小部分，觉得有感触。。原文在这里，点击进入：

部分我认为不错的精华，或者说是我关注的。。。

1、课程：失败来临的征兆（讲师：Michael Nvgard）这一切正是Michael Nvgard先生演讲的主旨：意外的问题总是在不经意间发生，要注意把它们的影响限制在局部，避免拖累整个应用。比如说在SOA中集成若干个服务时，应该 设置好各个服务的Timeout，避免其中一个服务崩溃连带整个系统等待。

2、课程：Twitter的可伸缩性数据架构（讲师：Nick Kallen）

Nick Kallen介绍了Twitter在处理海量数据时的经验，其实总结出来就三条：分区，索引，复制。

着重介绍了Tweets，Timelines，Social Graphs，Search Indices四个基本功能的实现：

Tweets比较简单，就是分区，虽然可以使用id或者user_id来分区，不过目前Twitter使用的是按time分区。

Timelines相对复杂了一些，最开始采用的方法是纯SQL的，大致如下：

这当然不是一个高效的解决方案，后来采用了被称作离线计算（Offline Computation）的解决方案，其思路大致就是每当发送一条推的时候，采用队列存储避免峰值瓶颈，同时向所有Followers分发此消息，然后每 个分发 终端在缓存中完成合并计算。乍一听起来这似乎也不是什么好的解决方案，一旦某人有非常多的Followers，即便分区，这个分发操作也会非常耗时，但按 Nick Kallen的介绍，Twitter确实是这么做的，细节操作有待研究。

剩下的问题不多说了，Nick Kallen给了PPT地址：http://www.slideshare.net/nkallen/q-con-3770885

3、课程：构建可扩展的微波系统（讲师：杨卫华）

杨卫华作为新浪微博的架构师，这次的PPT做得很酷，虽然在内容上和Twitter有些重复，但还是很不错。

提到了Memcached的evictions问题，给出了三个守则：

1：规划好cache的容量
2：将永久数据和临时性数据分开
3：不使用随机字符串做Key

至于原因，可以参考杨卫华的博客上的介绍：Memcached数据被踢(evictions>0)现象分析

4、课程：敏捷在中国（讲师：Tom Mellor） 编程工期的催促往往让程序员只考虑眼前的既得利益，却忽视了后期的风险。

5、课程：如何在团队中有效实施TDD（讲师：麦天志）在阐述为什么即便工期紧张也应该使用TDD的时候，他给了一个比喻：医生做手术的时间很紧张，但即便 这样，手术前清洗双手的工作程序也是必不可少的。在讲解重构时，他强调了TDD是重构的基础，只有这样才能保证重构没有改变现有的行为，否则就不是重构，而是重写。

最近javaeye发生一起小故障，是robbin自己说的：

在mikespook.com看到对待这个问题的分析时，突然想起桔子也遇到过类似的问题，所以把他们两个人的事情贴出来。

先上mikespook的：

再上桔子的，汗，突然发现桔子的博客上居然没有写，看来是上次在群里看到了，大意如下：

其实上面两个问题都差不多。都是在访问大的时候，缓存频繁生成造成的故障，这确实不容忽略，但如何解决真的是一个问题。很多时候在访问量不大时，我们都考虑使用文件来作为缓存存储。但真正访问量高了后，文件缓存不可避免的就带来IO的消耗，如何批量生成缓存？还是按次生成缓存？还是定有一定的策略？难道还要采用队列？那就夸张了。

所以，一个好的系统架构也是很需要的，不能因为一次宕机就永远起不来。我个人是偏向于队列生成缓存，这样就不用担心一次写入过多文件引起IO的崩溃。但队列是因为有延迟的，如果控制同样的内容不重复生成文件缓存，则需要另外考虑

这篇文章很有意思，以前注意过，但没仔细考虑过用来注入，或许就象王猛说的：