1。交换链接                      点击侧栏里的申请链接，或直接回复此文。p.s. 我不喜欢搞商业、SEO、摘抄等无聊站点。
2。可以注册一个帐号          这样评论留言就不用输入验证码。有些日志只有登录后才能看到。
3。使用GoogleReader订阅  猛击此链接。注意，是https的，不要用http。
4。需要单独联系的            发邮件至 i [#at] felix021.com

---

boluor推荐给我的。难得有这么完整地总结大规模数据处理题目的文章，一定要收藏下来。

zz from http://www.douban.com/note/52434859/

1.Bloom filter

适用范围：可以用来实现数据字典，进行数据的判重，或者集合求交集

基本原理及要点：
对于原理来说很简单，位数组+k个独立hash函数。将hash函数对应的值的位数组置1，查找时如果发现所有hash函数对应位都是1说明存在，很明显这个过程并不保证查找的结果是100%正确的。同时也不支持删除一个已经插入的关键字，因为该关键字对应的位会牵动到其他的关键字。所以一个简单的改进就是 counting Bloom filter，用一个counter数组代替位数组，就可以支持删除了。

还有一个比较重要的问题，如何根据输入元素个数n，确定位数组m的大小及hash函数个数。当hash函数个数k=(ln2)*(m/n)时错误率最小。在错误率不大于E的情况下，m至少要等于n*lg(1/E)才能表示任意n个元素的集合。但m还应该更大些，因为还要保证bit数组里至少一半为 0，则m应该>=nlg(1/E)*lge 大概就是nlg(1/E)1.44倍(lg表示以2为底的对数)。

举个例子我们假设错误率为0.01，则此时m应大概是n的13倍。这样k大概是8个。

注意这里m与n的单位不同，m是bit为单位，而n则是以元素个数为单位(准确的说是不同元素的个数)。通常单个元素的长度都是有很多bit的。所以使用bloom filter内存上通常都是节省的。

扩展：
Bloom filter将集合中的元素映射到位数组中，用k（k为哈希函数个数）个映射位是否全1表示元素在不在这个集合中。Counting bloom filter（CBF）将位数组中的每一位扩展为一个counter，从而支持了元素的删除操作。Spectral Bloom Filter（SBF）将其与集合元素的出现次数关联。SBF采用counter中的最小值来近似表示元素的出现频率。

问题实例：给你A,B两个文件，各存放50亿条URL，每条URL占用64字节，内存限制是4G，让你找出A,B文件共同的URL。如果是三个乃至n个文件呢？

根据这个问题我们来计算下内存的占用，4G=2^32大概是40亿*8大概是340亿，n=50亿，如果按出错率0.01算需要的大概是650亿个bit。现在可用的是340亿，相差并不多，这样可能会使出错率上升些。另外如果这些urlip是一一对应的，就可以转换成ip，则大大简单了。

2.Hashing

适用范围：快速查找，删除的基本数据结构，通常需要总数据量可以放入内存

基本原理及要点：
hash函数选择，针对字符串，整数，排列，具体相应的hash方法。
碰撞处理，一种是open hashing，也称为拉链法；另一种就是closed hashing，也称开地址法，opened addressing。

扩展：
d-left hashing中的d是多个的意思，我们先简化这个问题，看一看2-left hashing。2-left hashing指的是将一个哈希表分成长度相等的两半，分别叫做T1和T2，给T1和T2分别配备一个哈希函数，h1和h2。在存储一个新的key时，同时用两个哈希函数进行计算，得出两个地址h1[key]和h2[key]。这时需要检查T1中的h1[key]位置和T2中的h2[key]位置，哪一个位置已经存储的（有碰撞的）key比较多，然后将新key存储在负载少的位置。如果两边一样多，比如两个位置都为空或者都存储了一个key，就把新key 存储在左边的T1子表中，2-left也由此而来。在查找一个key时，必须进行两次hash，同时查找两个位置。

问题实例：
1).海量日志数据，提取出某日访问百度次数最多的那个IP。

IP的数目还是有限的，最多2^32个，所以可以考虑使用hash将ip直接存入内存，然后进行统计。

3.bit-map

适用范围：可进行数据的快速查找，判重，删除，一般来说数据范围是int的10倍以下

基本原理及要点：使用bit数组来表示某些元素是否存在，比如8位电话号码

扩展：bloom filter可以看做是对bit-map的扩展

问题实例：

1)已知某个文件内包含一些电话号码，每个号码为8位数字，统计不同号码的个数。

8位最多99 999 999，大概需要99m个bit，大概10几m字节的内存即可。

2)2.5亿个整数中找出不重复的整数的个数，内存空间不足以容纳这2.5亿个整数。

将bit-map扩展一下，用2bit表示一个数即可，0表示未出现，1表示出现一次，2表示出现2次及以上。或者我们不用2bit来进行表示，我们用两个bit-map即可模拟实现这个2bit-map。

4.堆

适用范围：海量数据前n大，并且n比较小，堆可以放入内存

基本原理及要点：最大堆求前n小，最小堆求前n大。方法，比如求前n小，我们比较当前元素与最大堆里的最大元素，如果它小于最大元素，则应该替换那个最大元素。这样最后得到的n个元素就是最小的n个。适合大数据量，求前n小，n的大小比较小的情况，这样可以扫描一遍即可得到所有的前n元素，效率很高。

扩展：双堆，一个最大堆与一个最小堆结合，可以用来维护中位数。

问题实例：
1)100w个数中找最大的前100个数。

用一个100个元素大小的最小堆即可。

5.双层桶划分

适用范围：第k大，中位数，不重复或重复的数字

基本原理及要点：因为元素范围很大，不能利用直接寻址表，所以通过多次划分，逐步确定范围，然后最后在一个可以接受的范围内进行。可以通过多次缩小，双层只是一个例子。

扩展：

问题实例：
1).2.5亿个整数中找出不重复的整数的个数，内存空间不足以容纳这2.5亿个整数。

有点像鸽巢原理，整数个数为2^32,也就是，我们可以将这2^32个数，划分为2^8个区域(比如用单个文件代表一个区域)，然后将数据分离到不同的区域，然后不同的区域在利用bitmap就可以直接解决了。也就是说只要有足够的磁盘空间，就可以很方便的解决。

2).5亿个int找它们的中位数。

这个例子比上面那个更明显。首先我们将int划分为2^16个区域，然后读取数据统计落到各个区域里的数的个数，之后我们根据统计结果就可以判断中位数落到那个区域，同时知道这个区域中的第几大数刚好是中位数。然后第二次扫描我们只统计落在这个区域中的那些数就可以了。

实际上，如果不是int是int64，我们可以经过3次这样的划分即可降低到可以接受的程度。即可以先将int64分成2^24个区域，然后确定区域的第几大数，在将该区域分成2^20个子区域，然后确定是子区域的第几大数，然后子区域里的数的个数只有2^20，就可以直接利用direct addr table进行统计了。

6.数据库索引

适用范围：大数据量的增删改查

基本原理及要点：利用数据的设计实现方法，对海量数据的增删改查进行处理。
扩展：
问题实例：


7.倒排索引(Inverted index)

适用范围：搜索引擎，关键字查询

基本原理及要点：为何叫倒排索引？一种索引方法，被用来存储在全文搜索下某个单词在一个文档或者一组文档中的存储位置的映射。

以英文为例，下面是要被索引的文本：
T0 = "it is what it is"
T1 = "what is it"
T2 = "it is a banana"
我们就能得到下面的反向文件索引：
"a":      {2}
"banana": {2}
"is":     {0, 1, 2}
"it":     {0, 1, 2}
"what":   {0, 1}
检索的条件"what", "is" 和 "it" 将对应集合的交集。

正向索引开发出来用来存储每个文档的单词的列表。正向索引的查询往往满足每个文档有序频繁的全文查询和每个单词在校验文档中的验证这样的查询。在正向索引中，文档占据了中心的位置，每个文档指向了一个它所包含的索引项的序列。也就是说文档指向了它包含的那些单词，而反向索引则是单词指向了包含它的文档，很容易看到这个反向的关系。

扩展：

问题实例：文档检索系统，查询那些文件包含了某单词，比如常见的学术论文的关键字搜索。

8.外排序

适用范围：大数据的排序，去重

基本原理及要点：外排序的归并方法，置换选择 败者树原理，最优归并树

扩展：

问题实例：
1).有一个1G大小的一个文件，里面每一行是一个词，词的大小不超过16个字节，内存限制大小是1M。返回频数最高的100个词。

这个数据具有很明显的特点，词的大小为16个字节，但是内存只有1m做hash有些不够，所以可以用来排序。内存可以当输入缓冲区使用。

9.trie树

适用范围：数据量大，重复多，但是数据种类小可以放入内存

基本原理及要点：实现方式，节点孩子的表示方式

扩展：压缩实现。

问题实例：
1).有10个文件，每个文件1G，每个文件的每一行都存放的是用户的query，每个文件的query都可能重复。要你按照query的频度排序 。

2).1000万字符串，其中有些是相同的(重复),需要把重复的全部去掉，保留没有重复的字符串。请问怎么设计和实现？

3).寻找热门查询：查询串的重复度比较高，虽然总数是1千万，但如果除去重复后，不超过3百万个，每个不超过255字节。

10.分布式处理 mapreduce

适用范围：数据量大，但是数据种类小可以放入内存

基本原理及要点：将数据交给不同的机器去处理，数据划分，结果归约。

扩展：

问题实例：

1).The canonical example application of MapReduce is a process to count the appearances of

each different word in a set of documents:
void map(String name, String document):
  // name: document name
  // document: document contents
  for each word w in document:
    EmitIntermediate(w, 1);

void reduce(String word, Iterator partialCounts):
  // key: a word
  // values: a list of aggregated partial counts
  int result = 0;
  for each v in partialCounts:
    result += ParseInt(v);
  Emit(result);
Here, each document is split in words, and each word is counted initially with a "1" value by

the Map function, using the word as the result key. The framework puts together all the pairs

with the same key and feeds them to the same call to Reduce, thus this function just needs to

sum all of its input values to find the total appearances of that word.

2).海量数据分布在100台电脑中，想个办法高效统计出这批数据的TOP10。

3).一共有N个机器，每个机器上有N个数。每个机器最多存O(N)个数并对它们操作。如何找到N^2个数的中数(median)？


经典问题分析

上千万or亿数据（有重复），统计其中出现次数最多的前N个数据,分两种情况：可一次读入内存，不可一次读入。

可用思路：trie树+堆，数据库索引，划分子集分别统计，hash，分布式计算，近似统计，外排序

所谓的是否能一次读入内存，实际上应该指去除重复后的数据量。如果去重后数据可以放入内存，我们可以为数据建立字典，比如通过 map，hashmap，trie，然后直接进行统计即可。当然在更新每条数据的出现次数的时候，我们可以利用一个堆来维护出现次数最多的前N个数据，当然这样导致维护次数增加，不如完全统计后在求前N大效率高。

如果数据无法放入内存。一方面我们可以考虑上面的字典方法能否被改进以适应这种情形，可以做的改变就是将字典存放到硬盘上，而不是内存，这可以参考数据库的存储方法。

当然还有更好的方法，就是可以采用分布式计算，基本上就是map-reduce过程，首先可以根据数据值或者把数据hash(md5)后的值，将数据按照范围划分到不同的机子，最好可以让数据划分后可以一次读入内存，这样不同的机子负责处理各种的数值范围，实际上就是map。得到结果后，各个机子只需拿出各自的出现次数最多的前N个数据，然后汇总，选出所有的数据中出现次数最多的前N个数据，这实际上就是reduce过程。

实际上可能想直接将数据均分到不同的机子上进行处理，这样是无法得到正确的解的。因为一个数据可能被均分到不同的机子上，而另一个则可能完全聚集到一个机子上，同时还可能存在具有相同数目的数据。比如我们要找出现次数最多的前100个，我们将1000万的数据分布到10台机器上，找到每台出现次数最多的前 100个，归并之后这样不能保证找到真正的第100个，因为比如出现次数最多的第100个可能有1万个，但是它被分到了10台机子，这样在每台上只有1千个，假设这些机子排名在1000个之前的那些都是单独分布在一台机子上的，比如有1001个，这样本来具有1万个的这个就会被淘汰，即使我们让每台机子选出出现次数最多的1000个再归并，仍然会出错，因为可能存在大量个数为1001个的发生聚集。因此不能将数据随便均分到不同机子上，而是要根据hash 后的值将它们映射到不同的机子上处理，让不同的机器处理一个数值范围。

而外排序的方法会消耗大量的IO，效率不会很高。而上面的分布式方法，也可以用于单机版本，也就是将总的数据根据值的范围，划分成多个不同的子文件，然后逐个处理。处理完毕之后再对这些单词的及其出现频率进行一个归并。实际上就可以利用一个外排序的归并过程。

另外还可以考虑近似计算，也就是我们可以通过结合自然语言属性，只将那些真正实际中出现最多的那些词作为一个字典，使得这个规模可以放入内存。

---

RT @acumon: #share 那一刻，我很想和所爱的人，一起看斗转星移，看云卷云舒…… http://v.youku.com/v_show/id_XMTM3MDQwMjI0.html

---

《让爱如此简单》

爱是无声的语言
时刻温暖在你我的心间
爱是希望的火焰
你我就能点燃这世界

无论世界多么大
爱的声音却处处生根发芽
无论梦想多么远
一路爱的光芒  照亮每双期待的眼

让爱如此简单  你我将她心与心相传
不冷落每一份温暖  哪怕相隔万水千山
让爱如此简单 你我将她的心愿实现
不熄灭每一次点燃  梦不再遥远

让爱如此简单

---

据说过些时间会出T-Shirt，到时候搞一件~~

p.s. 这是第1800篇日志了。我是一个勤奋的blogger, 虽然经常zz和发口水文....

---

更多内容，参见laruence大牛的这篇： http://www.laruence.com/2009/07/23/994.html

这么短一段代码，有这么多考究的地方，很值得学习：
1. 5381
2. hash << 5 + hash  --> hash * 33 (times 33算法)
3. -= 8
4. switch, break
...

---

前面发了一篇赞百度的日志，然后就有同学说我是百度的枪手了（当然这位同学只是开玩笑），
然后还有同学义愤填膺地想跟我理论，说百度怎么怎么地。
最近和sandy聊天的时候，sandy还说，我受百度的影响非常大。
的确挺大。
入职两个月，感觉我对百度的看法变了很多。
要我说，百度的确是一个值得令人尊敬、爱戴的公司。

估计又有人要以为我是百度的枪手在这里发软文了。
没办法，网上枪手太多了，没有几句话是真正可信的。
所以我也不指望别人相信我下面要说的，也不打算给这篇文章的评论作出任何回复。

我只是想写一篇日志而已。
如果谁固执地认为百度就是一个垃圾公司，那么也不必往下看了，免得不痛快。

--------华丽的分割线--------

百度十年了。这十年，有人叫座有人骂，创造过各种奇迹，陷入过各种危机。
在中国这样一个特殊的社会里做搜索、贴吧、知道这样开放的东西，能坚持下来，很不容易。

曾经有一段时间，我是把百度贴吧当作我的个人博客来用的，后来逐渐发现帖子被和谐的概率越来越高。混迹于贴吧的同学都知道，这种情况很多。“一楼喂百度”，“抽风”之类都是常见用语。那一阵我对百度颇有微词，最终导致我更换阵地，才有了这个博客。回头想想，那时候还是脑袋太简单，河蟹这种生物，不是百度可以控制的，百度也是受害者。Google也一样。不过这些都是没什么，网民们遇到这种情况，没法对着ZF发牢骚，只能在直接肇事者的地盘上发发牢骚骂几句，再正常不过。发完牢骚，想想也就认了，该怎么还怎么。

回到重点，从我所了解到的情况来看，百度的名声臭在三种/件事情上：
1。不给钱做竞价就封站。这个骂名百度是背了很久了，网络上各大中小网站站长似乎颇有怨言。
2。三鹿奶粉的那次公关危机
3。竞价排名广告的竞价规则，让某些用户、企业很不爽，甚至受到伤害（比如去年那个癌症的事情，还有今年那个大众搬场）

===
1。不给钱做竞价就封站。
    这个问题闹了很久了，甚至Robin都出面，给百度所有员工发了一封邮件，说“媒体所报道的不给钱就封站的事，我们从来没有干过，以后也不会干，请大家放心”。

    去年看到Robin这封信的时候，我也是比较怀疑的。但是在百度实习了两个月，亲身体验百度“简单可依赖”的公司文化、用户至上的理念，还认识了不少热心、真诚的同事（不止是电子商务部门的），让我从心底里拒绝相信“不给钱就封站”这种说法。这样一帮可爱可敬的百度同学，怎么可能作出那种无耻的事情？

    然后我专门去查了一下。最典型的是“反垄断第一案”全民医药网告百度的闹剧了，最后结果是百度给出了全民医药网的作弊证据。对于其他被封站的情况，由于没有闹大，找不到什么资料，不适合评论。是真的因为不给钱而封站（这个我绝不相信），还是因为网站作弊（SEO产业有多火热，尤其在05年以前那样赤裸裸的作弊有多严重，稍微注意过的应该都感受颇深），还是因为网上枪手太多狂发软文（这个是共识了，无奈吧），都有可能。

    但是问题在于，广大网民是严重信息不对称的，一旦有个站长由于某种原因被百度封了导致自己利益受损，在网上发一个帖子，就能导致网民群情
激愤，网民以愤青，百度就倒霉了（这种事情可以和错误人肉事件对比一下）。Google也没少经历这种郁闷，有些站长的Adsense广告被别人恶意点击封站，也被骂得狗血淋头，可是问题不一定出在Google身上（当然，可以算上Google算法的问题）。

===
2。三鹿奶粉公关危机。
    这件事情太扯了，300w就让百度删东西？那些FQ的都是不用脑子的。对于百度来说，300w，和企业名声，哪个重要？这个非常明白的事情。

    就事论事地说，当时百度搜三鹿的结果的确比google少了一大截，这是大家都知道的事情。找出当时的数据来看看：“以9月13日21点的搜索结果为例：“三鹿奶粉事件”百度搜索的相关相关网页约78100篇，而谷歌则有270000项符合查询结果；“三鹿奶粉事件”百度找到相关新闻约3450篇，而谷歌资讯搜索约有4740项（呵呵按一条1万元算得收1000多万元呢！）。无论是新闻或网页，谷歌的结果都大大高于百度的结果，结果背后的东西是什么呢？一个是不能肯定的，百度与三鹿之间是否达成了某种协议；一个却是肯定的，百度搜索引擎的力量远远不及谷歌。”

    但是大家都忽略了另外两个更重要的事实：
    a) 如果你去百度google搜“笨蛋”，百度出了2200w个结果，google出了170w个，结果，可是一直往後翻，最后用户能看到多少条记录？百度是76页*10个/页，Google是100页*10个/页。也就是说，用户最多也就是看到1000个搜索结果，前面提到的百度7.8w，谷哥27w，对用户来说有什么区别？更可笑的是后面那个“肯定”，一看就是说话不经过大脑。（是不是笨蛋们集体给钱给google减少搜索结果呢？）
    b) 搜索引擎能找到的数量并不能反映其算法的质量，更重要的是搜索结果的相关性。如果搜索出来的结果按照相关性排序，相关性考前的排在前面，那么就能够最大限度地满足用户的需要。这也正是a)条中百度google最多都没提供1000条以后的原因。再去翻翻以前的记录，有说到百度屏蔽了负面新闻吗？新闻里没有条。而且就我当时的使用来看，也是没有的。

    至于三鹿的那个公关稿，说不定三鹿真的有出，但是也可能是被伪造（最近网络上“被”动句用得真多），就算真的有出，也没有确凿的证据证明百度签了它，收了钱，封锁了消息。没脑子的FQ们就这样狂骂百度，百度实在很委屈。

    然后来从我的理解上简单分析一下那些愤青的心理：300W，对于普通个人而言真不是小数目吧，以前买彩票日思夜想中个头奖，那也就是500w，扣税了就是400w。这么一算，如果有人给"我"300w让我删掉一些搜索结果，那"我"还是会比较愿意收人钱财替人消灾的吧。那如果"我"都愿意这么做了，百度这么做也很"合理"（根本就没觉得300w对于百度只是个小数目）。但是这件事情本身是不对的，我也就想想，百度还真做了，该骂。（本段纯属玩笑，嗯）

===
3。竞价排名的事情
    首先得承认，百度搜索推广经典版（也就是俗称的“竞价排名”系统）算法的确不合适，基本原则就是给钱高就往前排（简直跟武大评奖学金时的活动分似的），不过好在从这个月开始(2009.12.01)，搜索推广专业版（凤巢）全面启用，算法换成了全新的，不会再出现这个诟病了。这是百度作出的努力，希望能受到网民和广大企业的认可吧。
    
    然后说说前面提到的两件事情。

    一是去年那个“根治癌症”的事情。这的确有百度的错，以至于Robin都站出来公开认错了。但是这又不能全怪百度。Google的竞价也曾经出过假发票的事情，只是没有被炒起来而已。说到底这个问题来自于国人的劣根性。

    记得有人说过，无论多么健全多么法制的制度在中国都是没用的，因为中国人太能使小聪明了，总能无孔不入地找出体制中的漏洞，并利用之。所以国内甚至出现了“骗子太多，傻子都不够了”的局面（虽然有点夸张）。在国外电视购物是商家非常好的销售渠道，在国内却被“八心八剑”、499元超值上网本等内容占据。这种事情发展到网络上，本来非常有利于合法经营的商家推广自己商品的渠道，就被骗子用来推销他们的骗局。百度有，Google也有，将来如果其他渠道发展壮大了，必然也会有。为什么百度上面就是比Google多？这就和Windows平台病毒比Linux平台多是一个道理的，不想多说。最后百度开除了那些业务员，未来的发展必然会更健康。

    二是今年的大众搬场这一类的事情。这问题就是出在搜索经典版上面了，貌似百度也的确败诉了。不过幸运的是，凤巢系统全面启用，这种事情已经成为历史了。在这里我特别点出另外2件事情。一个是申通和申通e物流。显然后面那个是李鬼，被百度打压了，于是有很长一段时间，他的页面上放了一句话：“百度你个大坏蛋，百度一下没有我的网站，还说什么‘百度一下，你就知道’baidu.com真的很垃圾”，可见有多无耻。另外一个是kaixin001.com和kaixin.com，网民公认的开心网是前者（虽然域名看起来更山寨），所以kaixin.com被百度死死压在下面了（关于此事更详细的可以看caoz的百度空间那篇“流氓有文化，果然很可怕”）。

    由于这样的事情通常闹得比较大，所以大家都觉得竞价排名这样不好，那样也不好。这就像大家觉得城管可恶，因为城管可恶面给人印象很深，让人带上有色眼镜，忽略了城管在维护城市环境中作出的贡献。竞价排名，从另一个角度讲，是符合了用户的搜索需求。的确有很多搜索请求中包含的词（比如律师，牙医，还有一些比如设备名称、产品型号等等）本身就意味着用户有相应的消费需求，如果能让用户看到相应的广告找到其相应的服务，不是正好各取所需么。

    不论是对人还是对于一个公司，苛求不犯错是不可能的事情。想起网上有个反百度联盟（其实也有反Google联盟）。这个网站初衷是可能是好的，但是最后结果是聚集了一堆人，想收集百度的各种罪证，最后把百度弄死。百度没有屏蔽这个网站，现在搜一下也还能看到，但是好像已经打不开了，通过快照可以看到，这个网站里面的内容有多烂，充斥着因为利益受损就破口大骂完全不注意素质的人。我觉得这些人真可悲。

====
    正所谓树大招风，百度在国内搜索市场上处于事实上的垄断地位，招来非议是非常正常的事情。但是有些非议是过于无耻了。

    百度作为一个非常注重社会责任的公司，有专门的CSR部门（CSR=Corporate-Social-Responsibility，企业社会责任），在CSR部门和其他各个部门同学的合作下做了非常多有益社会的事情。比如说四川地震的营救信息（贴吧、搜索）、捐款；绵竹年画的销售（首页logo）；对柑橘事件的帮助（蛆虫谣传）；还有百度·小桔灯-最大的互联网公益助学平台（http://light.baidu.com）。。。

    大家或许知道百度推出了老年搜索（http://123.baidu.com/），像这种专门针对老年人的东西，由一帮年轻人来做，如果不慢工出细活，怎能做得好？几十个工程师历经半年时间做出来了，广受老年人好评。然后有人说了，百度这什么烂公司，就这个东西也要几十个人做半年。对于这种人，我真恨不得送一些cnbeta上面的文明用语给他。

    今年百度又搞了一个情系e乡的活动，旨在号召大学生帮助家乡的发展，目前做的非常好，有一个团队做的是秭归脐橙的项目，从8月份开始到现在，“与去年同期相比，今年销售脐橙是去年的5倍多（今年已卖出50多万斤，而去年同期仅为10万斤左右）。其中部分外地的大客户是通过大学生的网上宣传而联系到秭归当地的”。

====
    再谈谈某些人眼里对百度和Google的对比。有人就是非要认为Google提出了Don't be evil，就真的一件坏事也没干，哪怕是不太好的事情。今年6月份Google涉黄的事情，这个不好说，存在争议。就说说最近吧，“谷歌封掉古巴一系列服务”，甚至连Google地图都封掉了。古巴《起义青年报》对此指责说,此举与谷歌公司方便人类获取信息的“宗旨”背道而驰,使谷歌加入了美国对古巴的封锁政策之中。再比如Google Dictionary 正式发布，原先answers.com的排名马上就被挤下去了，虽然Dictionary的内容现在还比不上answers.com。如果Google完全奉行了Don't be evil的原则，还有很多事情是不应该发生的。还有Google声称不干预搜索结果，这里引用caoz的博客的一段话：
    当然，Google本质上是个好公司，我也非常喜欢Google的很多产品，特别是我觉得Google有很多产品是革命性的。

....

发现这个话题写不完，就这么烂尾吧，嗯。

---

在EB的Hi群里大家聊到了CSRF攻击的问题。

关于CSRF攻击，网上资料很多，简单说几句：现在很多网站对提交的请求不检查来源，攻击者可以简单地构造一个页面，页面包含一个大小为0x0的iframe，内含一个修改管理员密码或者创建新特权用户或为现有用户提升权限的表单，当页面载入的时候由javascript控制该表单post到abc.com的某个页面。然后攻击者将此url发送给abc.com的管理员，引诱其点击，如果管理员此时已经登录，就会在管理员不知情的情况下获得权限。具体的原理，如果不很了解，建议先学习一下HTTP协议，重点是GET/POST，Cookie/Sessoin，Referer。解决的办法比如限制referer，或者增加页面校验码等。

看了一下这个Bo-blog(2.1.0)，居然没有这个检查。。。囧。想起2.1.1，这个版本推出挺久了，因为2.1.0有些BUG折磨了我挺久（最近解决了一个，下载的问题，还有一个是rss在google reader总是少一篇），于是就去下了新版本在本地搭起来。看了一下，发现没有什么大的改动，对CSRF的攻击也完全不设防。而且由于现在这个版本我自己改了好多地方，比如根据IP直接显示地址，以及评论留言的邮件通知等，如果升级了还得重新改，太麻烦，所以完全没有升级的动力。到Bo-blog的bbs去提了个BUG报告。Bo-Blog的更新实在太少。。

@1:00 p.s. 已经修改，增加了检查POST时的Referer，GET就不检查了，这个。。真不能检查。。验证码就先不做了，每个页面都要去加，真不爽。这时候觉得bo-blog统一入口的原则真好，改动只有一个地方，加了几行就OK~

---