本来觉得这个博客应该只关注于web技术，只讨论些wordpress，各种前端技术，乃至互联网公司发展方式的问题。但转念想来此博客关注度又不高，便违背SEO专注的精神也不会有啥流量损失。何况一个人还是把技术问题分在几个博客说也未免太夸张，这个博客既然是技术博客，自然应该什么技术问题都可以在这里畅所欲言。

于是决定把自己种种技术相关的文章都搬迁到这里，以丰富这个站点的内容，而关键的是要开始记录自己至今参加的第一个需要编码的多人合作项目历程。希望能够坚持每周写一篇，把从需求到设计到最后编码遇到的种种问题与思考都记录下来。

项目组由一个博士，一个准博士，包括本人在内的三个硕士组成。准博士算是项目负责人，但是具体经验不足，还是需要博士进行辅助。发过来的项目要求只有简单几句，概括说来就是实现一个key-value存储系统，key为两种定长，value只有8字节整数。总规模可以达到20亿条记录，10次找key只准1次io，最多利用总数据量5%的缓存。

这要求很是古怪，目前kv存储系统设计都会大量利用内存来做缓存，甚至很多都是所谓“内存数据库”。这里却对内存使用要求如此严格，但又要达到寻找key时90%的命中率，简直是不可能完成的任务。而且对性能还没有提成明确要求，已经可想见最终要求之苛刻。

调研从系统与测试方面进行，选择了最简单的hashdb与同样以节约内存闻名的tokyo cabinet，hashdb不到500行代码，自然只是大概学习一下。而就资料来看tokyo cabinet也只是面对千万级别的设计，在到达上亿数据时性能会急剧下降。

而后发现使用在工业环境的tokyo cabinet其实现居然如此简单，而且只能将数据存在一个文件中，很明显限制了最大存储的数据量，这彻底颠覆了本人对其的印象。测试下来自然性能也没传说中的那么牛，而且明显到达上亿级别测试结果不会好，一时全组陷入沮丧当中。

后来再多方考察使用TC做后端存储的flare等设计思路，才突然想到不应该将TC看成一个完整的系统，而应该视为一个最底层的存储引擎。这个引擎足够简单，但是足够好用，你可以在上面开发更多东西。一个文件并非对应一个TC数据库管理系统，而是只对应一个数据库，甚至一个表，比如可以将20亿数据拆分成几个TC数据库来存，这样就能存储在多个文件中(就是说DBA还得弄分片分表，TC使用类似innobase的file_per_table设置)，也就可以扩展最大存储数据量了。当然性能如何，能否满足本项目苛刻的要求又是另一个话题，但是工业环境下是可以这样使用TC的。所以工业环境下使用软件不应该被限制住思维，一个不够，多搞几个，完成任务就行。

回到项目上，显然TC的hash引擎设计使用mmap来进行性能优化不适合本项目，再看B+树引擎设计也同一般B+树类似，没看出特色来，所以架构设计方面仍然是一筹莫展，只期待下周的需求讨论华为方能够更明确设计目的与要求。老师自然不满意这种简单的设计，要求我们看看更先进的系统，但是能用的kv系统真的不多，Berkerly DB算是最大而全的吧，可以了解一下架构设计，但对项目感觉帮助不大。

说到需求讨论，本人准备了各种问题，从系统基于的设备到可靠性与可扩展性要求乃至是否并发访问，结果博士来了句“问这些不相关的干什么，其实对方真正只是要一个能够管理大数据量而同时节省内存的算法而已”，仔细一看发过来的需求，还真是如此。所以项目需求最需要明确的是这个系统是用来干什么的，如果是一个为了算法测试用的原型系统，考虑那么多工程问题干什么呢？也许是本人太想鼓捣个工业环境用的系统玩玩了吧，以致忽略了对方提出项目的真实目的。所以需求明确是最必要的，而问出系统使用验收的环境是更关键的。

这是本人2011年10月的一篇读书笔记，当时对互联网的理解自然有限，倒是能结合这篇做个比较。

读《浪潮之巅》帮助我梳理整个计算机发展的规矩，只要读这种梳理路线的书就会有n多想法被串在一起，许多当时觉得有记录必要但却慢慢淡忘的思想也逐渐浮出，真心希望自己能多碰到些这种书。

1.作者从google出来却放弃去百度而选择了腾讯，这说明了一个态度：1.百度搜索霸主地位已经成熟，根据规律，其在搜索上的发展必然停止，而需要寻找新的盈利点。所以作者的搜索技术在百度是发挥不了作用的。2.作者认为百度找不到新的盈利点，他否定了百度作为技术公司的身份，认为其仅是一个互联网公司，存在转型困难的问题。这也是有一定道理的，尽管目前百度仍然是三巨头中最强调技术的公司，但百度盈利模式却放弃了技术路线，竞价排名让人工代替了自动化技术，这种矛盾性让作者从中看出公司基因的问题。3.作者说腾讯和淘宝将逐渐蚕食百度的搜索份额，但这与他所说的霸主规律相矛盾，显然这只是作者的一厢情愿。由1的证据完全可以推翻3的说法。

2.目前腾讯的主攻发展方向是霸占桌面，以此继续巩固扩大自己的im优势。显然腾讯调整了原来希望霸占操作系统的心思，因为仔细分析就能发现那个其实迟早要被浏览器霸占，而浏览器大战腾讯tt没有丝毫转化优势，于是干脆放弃改为霸占用户的片段时间（即桌面）为此推出Q+并改变了webQQ的发展方向。由需要探索需要服务定制的一站式服务系统，改为一目了然扁平的桌面。

原来总是不解为啥q+或webQQ桌面上要默认放那么多应用，现在更是推出常用网站功能，一打开满屏幕各种大众网站密密麻麻。其实这既是跟其战略制定相符合，而战略制定更是和中国用户习惯相适应。这点听了周鸿祎的分析才真正弄明白，中国大多数用户尤其是使用qq客户端的都是没有细分能力的，他们不喜欢探索更讨厌定制。即使给他们一站式服务系统，他们也搞不懂到底怎么用。而让他们用的最好的方法就是推送，他们不是懒得考虑自己需要什么吗，那就一股脑都给他们。所以腾讯放弃了系统，选择了桌面；放弃了分类，选择了扁平。

3.腾讯微博明显干不过新浪微博，但腾讯还是在搞；腾讯朋友更是彻底失败，但还是反复在搞，目前甚至不惜使用最后绝招与im绑定。显然这是需找新盈利模式的无奈，目前世界成功模式有搜索，电子商务，web2.0社交平台（facebook，或twitter），前面俩个腾讯也在积极的做，但由于霸主规律，基本无望。社交方面腾讯是霸主，更有优势，但转向web2.0平台却不那么容易。好不容易在3Q大战后意识到不做成平台不行了，全力去促成，无奈目前两种平台都弄不起来。

4.比腾讯朋友更有用户基础的Qzone也在改版，而且极其诡异的同时向两个方向努力，一方面是向社交平台转变，这当然是弥补腾讯朋友失败的无奈之举；一方面又得适应博客先轻博客转型的世界潮流，而问题在于信息爆炸的社交平台与小资情调信息极少的轻博客从设计本质上就是矛盾的。腾讯朋友的失败其实也是虚拟关系的qq号网络和真实信息的社交网络两者设计本质矛盾的产物。现在的腾讯其实在痛苦的转型期，所以才弄出桌面战略以此来进一步弥补平台的问题，既然平台建不出来，只好把im也往平台转。第一入口浏览器不成，只好选第二入口桌面。我原来也只想到了第二入口桌面，觉得以后肯定会有越来越多的公司抢这个，却没有想到浏览器，再看google的思路，发现确实有境界理解上的差距啊！

5.腾讯这几条线都没有放弃，社交网络甚至采取得是齐头并进的模式，看来战略仍然是不断模仿直至对方找不到盈利来源拖垮为止。无奈新浪不吃这套，而且大有反抢qq社交关系的架势。微博本就很容易使用，和qq一样可以是虚拟身份也可以是真实身份（这点在中国很关键），而且最关键的是脱离平台限制，完全可以想象qq的危险境地。所幸对手是新浪，没啥创新能力与技术储备，否则其放弃平台专做统一接口，那将是对qq一次毁灭的打击。