唐福林-博客雨

网上大家都在流传 如何更好的实现一个 12306 ，作为一个技术人员，碰到如此难得的机会，忍不住也想跟着忽悠一把。

纯粹从技术角度出发，来设计一个架构和实现方案是非常容易的。但我相信，真实的 12306 的架构师，需要考虑的不仅仅是技术实现，还有数不清的历史包袱，现实约束，甚至人为限制。所以，这里的描述，只是技术人员关起们来，自己的 YY ，大家姑且看看就行，别太当真。

12306 当前的问题，无非是僧多粥少加定时放票引起秒杀效应，造成拥堵。只要解决了这个问题，大家的意见就不会那么强烈了。

首先来看僧多粥少的问题。车票一共就那么多张，这个系统只需要考虑如何将这些票安全，公平的卖出去。至于是不是还有人没有买上票，这就不用技术人员考虑了。所以，我们的问题其实只有一个：如何解决拥堵问题。

在这个神奇的国度，每个地方都有拥堵问题，公交站台，景区门口，银行柜台，甚至食堂窗口，大家都用同一种办法来解决这个问题：排队。所以我一直很纳闷，12306 为什么一开始没有实现排队的功能，是领导拍了脑袋？还是有其它不为人知的原因？

废话少扯，还是说正经的吧。

Redis 用在这里，不仅仅是一个 NoSQL 存储工具，简直是一个完美的解决方案。下面我就来详细描述一下我想象中的一个架构：

1. LVS 接入，同时将 https 协议转成 http 协议。 按照网上流传的 2kw 的预算，F5 恐怕是用不起了，不过也没事，LVS 加硬件 SSL 卡，50w 预算绝对拿下。

2. varnish 反向代理。cache 住大部分的静态资源，每台机器 3w/s 的 rps 应该可以比较轻松的应对。即使按照 30w/s 的峰值能力计算，也就 10 台机器，30w 预算

3. Nginx 服务静态资源，有 2 台足够，6w 预算

4. Tomcat 服务动态请求，这个量会比较大。但可以从这几个方面入手去减少资源消耗：第一，使用 ajax 请求，而不是页面刷新，减少单个请求的 size；第二，做好频率检测和控制，对于部分用工具来刷的用户，甚至可以采取惩罚措施，以减少无谓的资源消耗。保守估计，20 台机器左右，这个数字要看领导们对于“用户体验”的要求程度。

5. Redis 服务器，96G / 台，价格也就 3w 出头。预算 10 台，将 2kw 注册用户全部加载到内存，将 2k 车次全部加载到内存，将每个车次的每个座位的状态都加载到内存，将每个在线用户都加载到内存，应该都还有内存剩余。为什么要写磁盘呢？大不了给 Redis 服务器配置双电源，再配一个电池！

6. DB 服务器。最重要的 db 服务器，“铁道部”的系统，如果不是 DB2 那就应该是 Orcale 了，应该是连硬件到软件一起买的解决方案吧。这个我没有用过，甚至都没有见过，所以不好估计预算了。如果用我们比较熟悉的 mysql，用户系统应该是一个单独的库；车次信息应该是一个单独的库，而且基本上是只读；车票信息应该有区分当前库和历史库，当前库用来存未售出的车票信息，或者近期刚刚售出的车票信息，数据量小，支持快速读写，以及更新，历史库用来存历史上的车票信息，存档性质；订单信息单独一个库，读写量都不会太大。除了车票信息的当前库建议用 SSD ，其它的库采用普通的硬件就行，预算不会超过 5w/台，按照 1M3S 的标准配置，总体的机器台数在 20 以内，预算 100w 左右。值得一提的是，车票信息的当前库，需要按照车次（甚至是车次+日期）进行分库分表。想提高实时性，提升用户体验，减少投诉？增加当前库的机器投入即可。

硬件设备应该就是这样了，接下来说说一些值得一提的实现细节。

当前 12306 系统一个很受人诟病的实现就是无法登录。用户打开登录页，输入了用户名密码，还耐心的填好了验证码，点击提交，再耐心的等了 30 秒，结果，弹出一个无比丑陋的对话框，说“当前访问用户过多，请稍后尝试”，太坑人了！以至于某公司甚至给做了一个“12306登录助手”出来。让用户登录进来，给他们能买到票的希望，是减少投诉的一个很重要的方面。这个其实一点也不难：将用户信息都加载到 Redis 内存，简单点，key 就是 email，value 就是密码加密串（亲，不能是明文哦！），用 cookie 而不是 session 进行身份验证，用 ajax 而不是刷新页面的方式提交数据和返回应答，这么一来，即使 2 kw 用户同时都登录进来，也只需要三五台 tomcat ，20分钟就搞定了。

用户登陆进来之后，不能立即就给出太多的输入框，让用户输入查询，那样对系统的消耗比较大，不划算。应该先让用户通过出发站和到站，查询好车次（单独的车次信息库，全部加载到内存供查询），选择好乘车日期，然后——点击“取号”按钮，拿一个号，进行排队。是不是很熟悉？去银行开卡，汇款啥的，不都是这么办的么！将每个“车次+发车日期”作为一个单独的队列进行排队，其实就是将火车站售票窗口给移动到互联网页面上而已！想提升用户体验？那就每个登录用户可以同时排 3 个队吧，比如我，想买 18 号或者 19 号的 K21，那我就同时在 “K21+18号发车” 和 “K21+19号发车” 2 个队伍里排着好了。

用户既然已经在排队了，那后台处理就很灵活了：根据 db 的承载能力，将用户有序的带到查余票和下订单的页面（后面命名为 “售票厅” 吧）即可。用户在排队页，用 ajax 请求定期轮询，server 端返回有 3 种：当还没有轮到该用户时，返回当前队列前面还有多少人，这个车次还剩多少张卧铺，多少张硬座等等，当然，这些信息都不是实时更新的，而是定期由后台线程或进程进行更新。读取的时候，只是一个缓存 get 操作而已。另一种就是已经轮到该用户，这个时候，给一个30秒或者60秒的订票时间窗口，要求在这个时间内完成查询和下单操作：查询的时候并不做任何的 lock 操作，而是仅仅显示 db select 的结果（这个地方，可能需要 select master 库），填写完票数，点击提交的时候，才做真正的 lock，随机选择座位，update db，update redis 。这个步骤是直接操作 db，不做任何的缓存，但因为是根据 db 的能力放进来的量，所以性能风险反而最小。还有一种状态，就是该用户的号已经过期，或者订票时间窗口过期，很简单，重新取号，重新排队。

具体到 Redis 操作，大约会是这样：

用户：key 为 user:abc@test.com ，value 就是 md5(email + password) ，用户登陆的时候，只需要做一次 get ，即可验证登陆是否成功。

用户参与排队的时候，给用户分配一个 token，token 中建议包含加入排队的时间。

为每个“车次+日期”建立一个队列：key 为 train:queue:k21:20120118 , value 是一个 list ，用户点击“排队”按钮，加入队尾，用 lpush token，后台进程根据 db 负载，从队伍头取出一个用户带入查票和下单页面用 rpop token 即可。后台一个定时任务，定期扫描队伍，更新每个人前面的人数，供查询使用。

为每个“车次+日期”建立一个“售票厅”：key 为 train:selling:k21:20120118 , value 是一个 hash ，field 即 token，value 为过期时间。后台进程定期从队列中 rpop 出一个或多个用户，hset 到 hash 里。并且还需要一个后台进程，定期从售票厅里清除出过期的 token

用户在排队页面，使用 token 作为参数来查询自己的状态：首先 hget 售票厅，确认是否已经轮到自己了，如果没有，则再获取前面还有多少人，预估还需要排队多久，车次还剩下多少票等等信息。如果已经轮到自己，则显示“下一步”按钮，将用户带到售票厅。这一步需要做好安全验证，防止有人采取技术手段绕过排队，直接进入售票厅。

如果不希望用户不停的按刷新按钮，消耗服务器资源？那就来一招狠的：用户每次刷新，则将他在排队中的位置往后排一个！不过采取这样的措施之前，别忘了在醒目位置提醒用户“注意节约我们的带宽资源”！

用户真正下单买票，这是纯粹的业务逻辑，这里就不再细说。下单买票完成后，记得更新一下余票信息缓存即可。

这样的系统很难做么？难，也不难。有的地方因为业务逻辑太复杂，不得不做一些改变，比如亚马逊为了应对圣诞购物季，建了一块云，比如淘宝为了双11双12的秒杀，买了一堆的机器；也有的地方因为各种其它的原因，无法做到完美，比如 12306，比如新浪微博。不过无论现实如何，在我们技术人员的心里，永远保留着一颗追求完美的心，永远保留一股追求更好的劲头，就够了。

谨以此献给我在 12306 上失败的购票经历，和明天的 K21 旅程。

新年快乐！

第一次在公司过元旦。如果运气不好，真被要求值班，那么大年夜可能也要跟今晚一样，在公司守着了。

2011 年过去了，2012 年到来了。2011 年总会过去的，2012 年总会到来的。

这一年，见证了新浪微博从 v3 到 v4 ，从一个奇迹到另一个奇迹的变迁。从 Qcon hangzhou 回来后，把自己的微博（@唐福林）签名改成了 “微博开放平台，伪架构师，兼职客服，负责 t.cn 短链，关注粉丝，分组和计数器。短链不能点击，关注，粉丝不对，分组错乱，数字不准都可以直接找我” ，从工程师到架构师，我终于能够跨过自己心里的那道坎。

2012 年，我将要更多的承担起架构师的职责，从自己接需求，自己出方案，自己写代码，自己上线，自己维护模块，渐渐转变成：把控大的方向，维护整体架构，推行最佳实践，完善流程和工具链，营造总结分享的气氛，为整体系统和团队带来更大的价值。技术人员成长到一定程度，总要从“技”走向“术”，最终从“术”上升到“道”。

这一年，与 @leeyanva 共同走过，有风雨，更有彩虹和阳光。清明去了一趟黄山和婺源，夏天学会了滑游龙板 ，去了无数次后海，秋天的时候，在北戴河补了一个婚纱照（海边），十一回家足足掰了6天的玉米 （玉米地照片）。最后，春节，回湖南，到时候看看是一起去桂林转转，还是去舜皇山国家森林公园看看。

这一年，进电影院看了不少电影，几乎包括了所有感兴趣的大片，有的是用工会发的电影卡，也有的是自己团购的电影票。

这一年，公司组织去了一次白洋淀，还去了一次坝上草原 。但因为都不许带家属，所以玩的都不是特别尽兴。三国杀，划船，骑马，晒太阳。

一年了，在“北京还将拥堵 ”系统里排队抽签，却一致没有抽中，所以一直没能拥有自己的车。

一年了，终于攒出一点首付，再四处借一点，准备出手买房，然后准备要小孩。

一年了，身边还发生了很多很多事情，有些记下了，也有些已经遗忘。

那末，就这样吧。

再见，2011 。

你好，2012 。

2011 年 元旦时的对比

2011年12月3日，LLVM 3.0正式版发布，完整支持所有ISO C++标准和大部分C++ 0x的新特性， 这对于一个短短几年的全新项目来说非常不易。

开发者的惊愕

在2011年WWDC（苹果全球开发者大会）的一场与Objective-C相关的讲座上，开发者的人生观被颠覆了。

作为一个开发者，管理好自己程序所使用的内存是天经地义的事，好比人们在溜狗时必须清理狗的排泄物一样（美国随处可见“Clean up after your dogs”的标志）。在本科阶段上C语言的课程时，教授们会向学生反复强调：如果使用malloc函数申请了一块内存，使用完后必须再使用free函数把申请的内存还给系统——如果不还，会造成“内存泄漏”的结果。这对于Hello World可能还不算严重，但对于庞大的程序或是长时间运行的服务器程序，泄内存是致命的。如果没记住，自己还清理了两次，造成的结果则严重得多——直接导致程序崩溃。

Objective-C有类似malloc/free的对子，叫alloc/dealloc，这种原始的方式如同管理C内存一样困难。所以Objective-C中的内存管理又增加了“引用计数”的方法，也就是如果一个物件被别的物件引用一次，则引用计数加一；如果不再被该物件引用，则引用计数减一；当引用计数减至零时，则系统自动清掉该物件所占的内存。具体来说，如果我们有一个字符串，当建立时，需要使用alloc方法来申请内存，引用计数则变成了一；然后被其他物件引用时，需要用retain方法去增加它的引用计数，变成二。当它和刚才引用的物件脱离关联时，需使release方法减少引用计数，又变回了一；最后，使用完这个字符串时，再用release方法减少其引用计数，这时，运行库发现其引用计数变为零了，则回收走它的内存。这是手动的方式。

这种方式自然很麻烦，所以又设计出一种叫做autorelease的机制（不是类似Java的自动垃圾回收）。在Objective-C中，设计了一个叫做NSAutoReleasePool的池，当开发者需要完成一个任务时（比如每开启一个线程，或者开始一个函数），可以手动创立一个这样的池子， 然后通过显式申明把物件扔进自动回收池中。NSAutoReleasePool内有一个数组来保存声明为autorelease的所有对象。如果一个对象声明为autorelease，则会自动加到池子里。如果完成了一个任务（结束线程了，或者退出那个函数），则开发者需对这个池子发送一个drain消息。这时，NSAutoReleasePool会对池子中所有的物件发送release消息，把它们的引用计数都减一 ——这就好比游泳池关门时通知所有客人都“滚蛋”一样。所以开发者无需显式声明release，所有的物件也会在池子清空时自动呼叫release函数，如果引用计数变成零了，系统才回收那块内存。所以这是个半自动、半手动的方式。

Objective-C的这种方式虽然比起C来进了一大步，我刚才花了几分钟就和读者讲明白了。只要遵守上面这两个简单的规则，就可以保证不犯任何错误。但这和后来的Java自动垃圾回收相比则是非常繁琐的，哪怕是再熟练的开发者，一不小心就会弄错。而且，哪怕很简单的代码，比如物件的getter/setter函数，都需要用户写上一堆的代码来管理接收来的物件的内存。

经典教材《Cocoa Programming for Mac OS X》用了整整一章节的篇幅，来讲解Objective-C中内存管理相关的内容，但初学者们看得还是一头雾水。所以，在2007年10.5发布时，Objective-C做出了有史以来最大的更新，最大的亮点是它的运行库libobjc 2.0正式支持自动垃圾回收，也就是由运行库在运行时随时侦测哪些物件需要被释放。听上去很不错，可惜使用这个技术的项目却少之又少。原因很简单，使用这个特性，会有很大的性能损失，使Objective-C的内存管理效率低得和Java一样，而且一旦有一个模块启用了这个特性，这个进程中所有的地方都要启用这个特性——因此如果你写了一个使用垃圾回收的库，那所有引用你库的程序就都得被迫使用垃圾回收。所以Apple自己也不使用这项技术，大量的第三方库也不使用它。

这个问题随Apple在移动市场的一炮走红而变得更加严峻。不过这次，Apple和与会的开发者讲，他们找到了一个解决问题的终极方法，这个方法把从世界各地专程赶来聆听圣谕的开发者惊得目瞪口呆——你不用写任何内存管理代码，也不需要使用自动垃圾回收。因为我们的编译器已经学会了上面所介绍的内存管理规则，会自动在编译程序时把这些代码插进去。

这个编译器，一直是Apple公开的秘密——LLVM。说它公开，是因为它自始至终都是一个开源项目；而秘密，则是因为它从来没公开在WWDC的Keynote演讲上亮相过 。

一直关注这系列连载的读者一定还记得，在第二篇《Linus Torvalds的短视》介绍Apple和GPL社区的不合时，提到过“自以为是但代码又写得差的开源项目，Apple事后也遇到不少，比如GCC编译器项目组。虽然大把钞票扔进去，在先期能够解决一些问题，但时间长了这群人总和Apple过不去，并以自己在开源世界的地位恫吓之，最终Apple由于受不了这些项目组的态度、协议、代码质量，觉得还不如自己造轮子来得方便。”LLVM则是Apple造的这个轮子，它的目的是完全替代掉GCC那条编译链。它的主要作者，则是现在就职于Apple的Chris Lattner。

编译器高材生Chris Lattner

2000年，本科毕业的Chris Lattner像中国多数大学生一样，按部就班地考了GRE，最终前往UIUC（伊利诺伊大学厄巴纳香槟分校），开始了艰苦读计算机硕士和博士的生涯。在这阶段，他不仅周游美国各大景点，更是努力学习科学文化知识，翻烂了“龙书”（《Compilers: Principles, Techniques, and Tools》），成了GPA牛人【注：最终学分积4.0满分】，以及不断地研究探索关于编译器的未知领域，发表了一篇又一篇的论文，是中国传统观念里的“三好学生”。他的硕士毕业论文提出了一套完整的在编译时、链接时、运行时甚至是在闲置时优化程序的编译思想，直接奠定了LLVM的基础。
LLVM在他念博士时更加成熟，使用GCC作为前端来对用户程序进行语义分析产生IF（Intermidiate Format），然后LLVM使用分析结果完成代码优化和生成。这项研究让他在2005年毕业时，成为小有名气的编译器专家，他也因此早早地被Apple相中，成为其编译器项目的骨干。

Apple相中Chris Lattner主要是看中LLVM能摆脱GCC束缚。Apple（包括中后期的NeXT） 一直使用GCC作为官方的编译器。GCC作为开源世界的编译器标准一直做得不错，但Apple对编译工具会提出更高的要求。

一方面，是Apple对Objective-C语言（甚至后来对C语言）新增很多特性，但GCC开发者并不买Apple的帐——不给实现，因此索性后来两者分成两条分支分别开发，这也造成Apple的编译器版本远落后于GCC的官方版本。另一方面，GCC的代码耦合度太高，不好独立，而且越是后期的版本，代码质量越差，但Apple想做的很多功能（比如更好的IDE支持）需要模块化的方式来调用GCC，但GCC一直不给做。甚至最近，《GCC运行环境豁免条款 （英文版）》从根本上限制了LLVM-GCC的开发。 所以，这种不和让Apple一直在寻找一个高效的、模块化的、协议更放松的开源替代品，Chris Lattner的LLVM显然是一个很棒的选择。

刚进入Apple，Chris Lattner就大展身手：首先在OpenGL小组做代码优化，把LLVM运行时的编译架在OpenGL栈上，这样OpenGL栈能够产出更高效率的图形代码。如果显卡足够高级，这些代码会直接扔入GPU执行。但对于一些不支持全部OpenGL特性的显卡（比如当时的Intel GMA卡），LLVM则能够把这些指令优化成高效的CPU指令，使程序依然能够正常运行。这个强大的OpenGL实现被用在了后来发布的Mac OS X 10.5上。同时，LLVM的链接优化被直接加入到Apple的代码链接器上，而LLVM-GCC也被同步到使用GCC4代码。

LLVM真正的发迹，则得等到Mac OS X 10.6 Snow Leopard登上舞台。可以说， Snow Leopard的新功能，完全得益于LLVM的技术。而这一个版本，也是将LLVM推向真正成熟的重大机遇。

关于Snow Leopard的三项主推技术（64位支持、OpenCL，以及Grand Central Dispatch）的细节，我们会在下一次有整整一期篇幅仔细讨论，这次只是点到为止——我们告诉读者，这些技术，不但需要语言层面的支持（比如Grand Centrual Dispatch所用到的“代码块”语法， 这被很多人看作是带lambda的C），也需要底层代码生成和优化（比如OpenCL是在运行时编译为GPU或CPU代码并发执行的）。而这些需求得以实现，归功于LLVM自身的新前端——Clang。

优异的答卷——Clang

前文提到，Apple吸收Chris Lattner的目的要比改进GCC代码优化宏大得多——GCC系统庞大而笨重，而Apple大量使用的Objective-C在GCC中优先级很低。此外GCC作为一个纯粹的编译系统，与IDE配合得很差。加之许可证方面的要求，Apple无法使用LLVM 继续改进GCC的代码质量。于是，Apple决定从零开始写 C、C++、Objective-C语言的前端 Clang，完全替代掉GCC。

正像名字所写的那样，Clang只支持C，C++和Objective-C三种C家族语言。2007年开始开发，C编译器最早完成，而由于Objective-C相对简单，只是C语言的一个简单扩展，很多情况下甚至可以等价地改写为C语言对Objective-C运行库的函数调用，因此在2009年时，已经完全可以用于生产环境。C++的支持也热火朝天地进行着。

Clang的加入代表着LLVM真正走向成熟和全能，Chris Lattner以影响他最大的“龙书”封面【注：见http://en.wikipedia.org/wiki/Dragon_Book_(computer_science)】为灵感，为项目选定了图标——一条张牙舞爪的飞龙。

Clang一个重要的特性是编译快速，占内存少，而代码质量还比GCC来得高。测试结果表明Clang编译Objective-C代码时速度为GCC的3倍【注：http://llvm.org/pubs/2007-07-25-LLVM-2.0-and-Beyond.pdf】，而语法树（AST）内存占用则为被编译源码的1.3倍，而GCC则可以轻易地可以超过10倍。Clang不但编译代码快，对于用户犯下的错误，也能够更准确地给出建议。使用过GCC的读者应该熟悉，GCC给出的错误提示基本都不是给人看的。

比如最简单的：

struct foo { int x; }
typedef int bar;

如果使用GCC编译，它将告诉你：
t.c:3: error: two or more data types in declaration specifiers

但是Clang给出的出错提示则显得人性化得多：
t.c:1:22: error: expected ‘;’ after struct

甚至，Clang可以根据语境，像拼写检查程序一样地告诉你可能的替代方案。
比如这个程序：

#include <inttypes.h>
int64 x;

GCC一样给出乱码似的出错提示：

t.c:2: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘x’

而优雅的Clang则用彩色的提示告诉你是不是拼错了，并给出可能的变量名：

t.c:2:1: error: unknown type name ‘int64′; did you mean ‘int64_t’?
int64 x;^~~~~int64_t

更多的例子可以参考http://blog.llvm.org/2010/04/amazing-feats-of-clang-error-recovery.html。 而同时又因为Clang是高度模块化的一个前端，很容易实现代码的高度重用。所以比如Xcode 4.0的集成编程环境就使用Clang的模块来实现代码的自动加亮、代码出错的提示和自动的代码补全。开发者使用Xcode 4.0以后的版本，可以极大地提高编程效率，尽可能地降低编译错误的发生率。

支持C++也是Clang的一项重要使命。C++是一门非常复杂的语言，大多编译器（如GCC、MSVC）用了十多年甚至二十多年来完善对C++的支持，但效果依然不很理想。Clang的C++支持却一直如火如荼地展开着。2010年2月4日，Clang已经成熟到能自举（即使用Clang编译Clang，到我发稿时，LLVM 3.0发布已完整支持所有ISO C++标准，以及大部分C++ 0x的新特性。

这对于一个短短几年的全新项目来说是非常不易的。得益于本身健壮的架构和Apple的大力支持，Clang越来越全能，从FreeBSD【注：http://lists.freebsd.org/pipermail/freebsd-current/2009-February/003743.html】 到Linux Kernel【注：http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-October/011711.html】， 从Boost【注：http://blog.llvm.org/2010/05/clang-builds-boost.html】 到Java虚拟机， Clang支持的项目越来越多。

Apple的Mac OS X以及iOS也成了Clang和LLVM的主要试验场——10.6时代，很多需要高效运行的程序比如OpenSSL和Hotspot就由LLVM-GCC编译来加速的。而10.6时代的Xcode 3.2诸多图形界面开发程序如Xcode、Interface Builder等，皆由Clang编译。到了Mac OS X 10.7，整个系统的的代码都由Clang或LLVM-GCC编译【注：http://llvm.org/Users.html】。

LLVM周边工具

由于受到Clang项目的威胁，GCC也不得不软下来，让自己变得稍微模块化一些，推出插件的支持，而LLVM项目则顺水推舟，索性废掉了出道时就一直作为看家本领的LLVM-GCC，改为一个GCC的插件DragonEgg。 Apple也于Xcode 4.2彻底抛弃了GCC工具链。

而Clang的一个重要衍生项目，则是静态分析工具，能够通过自动分折程序的逻辑，在编译时就找出程序可能的bug。在Mac OS X 10.6时，静态分析被集成进Xcode 3.2，帮助用户查找自己犯下的错误。其中一个功能，就是告诉用户内存管理的Bug，比如alloc了一个物件却忘记使用release回收。这已经是一项很可怕的技术，而Apple自己一定使用它来发现并改正Mac OS X整个系统各层面的问题。但许多开发者还不满足——既然你能发现我漏写了release，你为什么不能帮我自动加上呢？于是ARC被集成进Clang，发生了文章开头开发者们的惊愕——从来没有人觉得这件事是可以做成的。

除LLVM核心和Clang以外，LLVM还包括一些重要的子项目，比如一个原生支持调试多线程程序的调试器LLDB，和一个C++的标准库libstdc++，这些项目由于是从零重写的，因此要比先前的很多项目站得更高，比如先前GNU、Apache、STLport等C++标准库在设计时，C++0x标准还未公布，所以大多不支持这些新标准或者需要通过一些肮脏的改动才能支持，而libstdc++则原生支持C++0x。而且在现代架构上，这些项目能动用多核把事情处理得更好。

不单单是Apple，诸多的项目和编程语言都从LLVM里取得了关键性的技术。Haskell语言编译器GHC使用LLVM作为后端，实现了高质量的代码编译。很多动态语言实现也使用LLVM作为运行时的编译工具，较著名的有Google的Unladen Swallow【注：Python实现，后夭折】、PyPy【注：Python实现】，以及MacRuby【注：Ruby实现】。例如 MacRuby 后端改为LLVM后，速度不但有了显著的提高，更是支持Grand Central Dispatch来实现高度的并行运行。由于LLVM高度的模块化，很方便重用其中的组件来作为一个实现的重要组成部分，因此类似的项目会越来越多。

LLVM的成熟也给其他痛恨GCC的开发项目出了一口恶气。其中最重要的，恐怕是以FreeBSD为代表的BSD社区。BSD社区和Apple的联系一向很紧密，而且由于代码相似，很多Apple的技术如Grand Central Dispatch也是最早移植到FreeBSD上。BSD社区很早就在找GCC的替代品，无奈大多都很差（如Portable C Compiler产生的代码质量和gcc不能同日而语）。

一方面是因为不满意GCC的代码品质【注：BSD代码整体要比GNU的高一些，GNU代码永无休止地出现各种严重的安全问题】，更重要的是协议问题。BSD开发者有洁癖的居多，大多都不喜欢GPL代码，尤其是GPL协议第三版发布时，和FreeBSD的协议甚至是冲突的。这也正是为什么FreeBSD中包含的GNU的C++运行库还是2007年以GPLv2发布的老版本，而不是支持C++0x的但依GPLv3协议发布的新版本。 因此历时两年的开发后，2012年初发布的FreeBSD 9.0中，Clang被加入到FreeBSD的基础系统。 但这只是第一步，因为FreeBSD中依然使用GNU的C++ STL 库、C++运行库、GDB调试器、libgcc/libgcc_s编译库都是和编译相关的重要底层技术，先前全被GNU垄断，而现在LLVM子项目lldb、libstdc++、compiler-rt等项目的出现，使BSD社区有机会向GNU说“不”，因此一个把GNU组件移出FreeBSD的计划被构想出来，并完成了很大一部分。编写过《Cocoa Programming Developer’s Handbook》的著名Objective-C牛人David Chisnall也被吸收入FreeBSD开发组完成这个计划的关键部分。 预计在FreeBSD 10发布时，将不再包含GNU代码。

LLVM在短短五年内取得的快速发展充分反映了Apple对于产品技术的远见和处理争端的决心和手腕，并一跃成为最领先的开源软件技术。而Chris Lattner在2010年也赢得了他应有的荣誉——Programming Languages Software Award（程序设计语言软件奖）。

本文选自《程序员》杂志2012年01期，更多精彩内容敬请关注01期杂志

内部人士的解读：
@Andy Pan 腾讯无线国际业务产品总监, 腾讯国际业务部

我决定在国外出差的最后一晚晚点休息,在酒店静静的认真的回答这个问题。我尽量客观的负责的回答，不愤青，不炫耀，不攻击，用朴实的语言。只代表我个人的思考，不代表公司。

腾讯最出名的是PC端的即时通信(IM)，有一种普遍的认识是即时通信IM（用户关系链）是整个腾讯竞争力的基础，平台和核心。在PC互联网端的后续出现的很多产 品，特别是一些细分市场的产品（由其他公司先发），腾讯通常能够后来居上。这一点也最为人诟病。主要批评是两点：1.依赖绑定 2.扼杀新兴公司

我之前服务的公司是微软，和腾讯非常非常相似，也是构建一个巨大的平台，然后在后续的新兴领域不断超越已领先公司（从Borland,到 Wordperfect,到Netscape),被诟病的点也极其类似:1.依赖绑定 2.扼杀新兴公司

因为这些,我非常认真的思考过这个问题。我有一个想法，算不上结论，只代表我目前的考虑：有些公司，他们的产品模式决定了商业模式，尤其是平台性产品公 司，注定是先期在搭建平台的努力和投入，在后期的应用上才得到回报。在微软做DOS, Windows的时候，为了赢得一个平台的努力和所冒的风险，如果只算当时Windows本身的回报也许会是不值得的。因为平台产品市场基本是一个零和游 戏，你赌整个公司在上边，做不赢就消失。如果只算那个平台产品本身的收益，聪明生意人都不会投资的。那么冒了巨大风险而万幸成功的企业，所有的努力将会这 个平台后续应用的回报获得，因为这是之前的努力的回报的一部分，属于分期还款加利息。举一个不恰当的例子，一个从艺20年终于成功的名角儿，拍广告30分 钟挣100万。如果单从这回报看，是不公平的暴利。但是事实上，商家购买的是角儿的影响力，这影响力是之前20年不停积累的结果。也就是说这100万从他 20年前就开始挣了，这30分钟只是最后的兑现。

同样的道理，也适用于腾讯的即时通信IM。算上当时做即时通信IM，无收入，竞争对手多，创始人还在继续坚持做。这所有的投入是为了打造一个平台，而这个平台怎么挣钱当时 也不清楚。但是后来在这个平台上各项赢利的产品，其实有相当一部分是当时做即时通信IM的劳动回报，只是延期而已。

同样的模式也适用于其他平台级厂商，比如Facebook,360等等等等。

多说几句: 这样的模式就注定了有些平台级公司，随着时间的推移，会进入到各个细分领域。这个说实话，无可厚非。之所以有细分领域，是因为用户有需求，平台的用户也是 用户，作为平台加应用厂商，为平台用户提供自己在该细分领域的服务也是正常。不举IT界的例子,最早的DIET软饮料是1952年的NO-CAL,新兴公 司,只在地方销售;然后是DIET RITE,取得较大成功;引起大公司关注这个市场,1960年百事推出DIET PEPSI，DR.PEPPER在1962年推出自己的DIET饮料。1963年终于可口可乐公司进入这个市场,推出TAB,取得巨大成功,后来演变为 DIET COKE. 这是细分市场的新兴公司必然会遇到的一个挑战,更大型的公司认为这个需求成为一个大众需求就会进入这个领域,新兴公司可以选择被投资被收购从而延续自己的 价值(比如ZAPPOS被AMAZON收购,YOUTUBE被GOOGLE收购),这也是新兴公司的一个成功。当然如果这个新兴公司认为这个细分领域可以 成就一家更大规模的公司,即便大型公司进入这个领域也无法与之竞争,这就是公司领导人对产业和对自己的判断了,有成功的案例,也有失败的案例.这是领导人 的GUTS,愿赌服输. DROPBOX的创始人拒绝苹果的收购,他要为他以后的成功失败担负荣耀或责任。大公司进入细分领域也有失败的案例，微软进入消费领域很少有成功案例，腾 讯在进入电商，搜索领域后也不是所谓的“大兵所至，片甲不留”。

回到主题: 所以，对的，我相信即时通信IM平台是核心竞争力之一。

从即时通信IM出发，我觉得衍生出来的竞争力就变成了，信息双向传递而产生的独特的竞争力，这个竞争力包括：信息实时直接触达最大范围用户的能力,用户反馈回收的 能力。有了第一种能力，使得平台上的应用产品对于用户的discoverability直接增强,从而使得用户对新产品有快速的认知；有了第二种能力，使 得产品在滚动，迭代的过程中，会越来越成为一个好的产品。因此,两者配合,使得腾讯公司在用户的新需求出现后,可以迅速的跟上新产品,并且快速的使得新产 品达到相当的品质.

于是，这种公司与海量用户之间信息双向沟通的能力也是核心竞争力之一。

再往后衍生，海量用户服务能力，海量用户架构，运营能力都成为竞争优势。我就不详细说了。

最后,我想再说一下我看到的另外一个核心竞争力, 就是员工的群体性努力，群体性指的是几乎所有的员工,从CEO，总裁到基层。你可能会说，每个公司的人都会说自己员工努力啦。我要说的是，无论是微软，还 是腾讯，员工_真的_很努力，工作的负荷远远超过我工作过的其他公司，也超过我身边认识的其他公司的员工。在微软，我觉得几乎每个人都或主动或被驱动的常 年维持大负荷的工作。当时和Nokia合作项目，Nokia总部的人对我们说，印象最深的就是他们不论什么时候发电邮，我们都会马上回，似乎没有时差一 般。一次半夜一点左右，他们的一个邮件需要三个职能的同事回信写工作细节，10分钟之内，我看到我和我们几个同事的邮件全部发出来了。在腾讯，晚上门口长 长的的士趴活的队伍早就是一道风景线了，一次我带IT界另外几个著名公司的朋友在很晚的时候到腾讯，他们的反应几乎是惊呼。我几乎经常性的在晚上1点钟左 右还不停的收到同事的运营报告，数据分析。我认识的经理也差不多都是这样。这种努力为什么是一种核心竞争力呢？因为这其实反映的是一家公司管理庞大知识型 工作者群体的能力。我记得我在微软时，和一个美国的资深的开发主管聊微软的竞争力，他的回答就是，微软的竞争力在于自己管理这么大规模的一间公司，虽然不 能说管理的多好，但是至少还OK，不太会犯致命的错误，持久战中等对手犯错误。那么竞争对手你要小心，新兴公司随着业务进步，公司变大，会面临很多必然的 问题，如果人性弱点浮现（因初期成功骄傲自满，组织变大无序的政治斗争），一个错误就会被这种从上到下很努力的公司超越，变成灭顶之灾。他举了 NESCAPE的例子,一个灾难性的烂版本出来,终于被IE超过。（说到这里，我想起来乔布斯97年回归苹果，介绍微软投资时，对应台下嘘声说，你们要搞 清楚一件事情，苹果没做好，是我们自己搞砸了，不是因为别人。我有时看到业界一些公司的公关稿时，经常会想起这段话。）一家全员都非常努力的公司，犯巨大 错误的机会可能会比较少，因为如果价值观走歪，策略愚蠢，员工会考虑一个问题，我这么拼命是值得的吗？我觉得格外努力的员工群体会帮助整个公司在出现问题 的时候立即察觉，无论是从优秀员工离职率还是别的调查。

写这段文字的时候，我不停的脑子里面浮现出来我部门的几个同事深夜工作的样子。

因此，我觉得这种非常努力的员工和工作氛围，而导致的一种竞争力，也应该是核心竞争力吧。

以上就是我长期思考的一点想法。感谢知乎的周源发了问题邀请，促使我把这些想法整理出来。腾讯当然有缺点有不足，不过我还是觉得看同行的时候，见贤思齐，见不贤而自省是应有的态度吧。

@李丹华 ，腾讯产品经理，从事无线,关注电商

非内部人士的解读，代表性回答：

@张亮 ，风险投资新兵

1. 马化腾。
2. QQ 这款史无前例成功的即时通信 IM。它不仅连接了数亿中国用户，还成为了中国最主流的生活方式、娱乐手段、虚拟财产、个人成就系统。
3. 长期布局获得的交叉推广能力，说穿了，中国互联网业绝无仅有的流量能力。
4. 自 2003 年起在游戏领域积累的变现能力。中国互联网最赚钱的市场是游戏，最大的游戏公司是腾讯。
5. 2、3、4 三者相加而成的生态系统。百度有流量平台和收入平台，但缺乏用户平台。阿里系有自成一体的卖家网络、交易系统和活跃用户群，但对这体系之外的流量无控制力。
6. 极早布局于无线，且拥有产品和收入两套人马。无线领域的成就让它在移动互联网时代难以撼动。
7. 全公司长期积累的技术实力、产品能力。腾讯内部很少说某个技术是实现不了的，以至于腾讯的不少产品经理出去创业时发现有这么多以前意识不到的难搞的技术问题。产品能力不说了。
8. 心态上，没有因为公司变大而放不下身段，市值五百亿美元的腾讯较好的保持了其危机感和血性。虽然也让 360、新浪微博、迅雷、淘米、YY 夹缝中成长起来，但从未出现过微软对 Google、Google 对 Facebook 那种严重忽视。
9. 微信。个人认为，微信相当于腾讯到二次创业，至少确保了它的根基基本无人能撼动。
10. 你懂的。

@pansz ，自由软件开发者

腾讯的核心竞争力，可能是曾经的运气和机遇。

在腾讯发力 即时通信IM 的时候，MSN 还不存在，世界上唯一的流行的即时通信 IM 是 ICQ。但是腾讯跟 ICQ 的用户体验相比，强得太多太多了，以至于我这个当时的铁杆 ICQ 用户立即跳槽了。如果当年腾讯的定位不是国内而是全世界，那么恐怕 MSN 就永远没有出现的机会了。

而大家应当知道，腾讯当年发力即时通信 IM 的时候，还根本没有所谓互联网管制这回事。。。所以腾讯最初并不是靠国内的互联网壁垒而发家的。

此后的事情，只要没犯太大的错误，就没什么差错了。

当然，我个人现在其实不怎么用 QQ，那纯粹是因为这种形式的通讯对我来说没有必要而已，我自然也属于“不用腾讯”的一族。虽然我觉得腾讯的产品并非不可缺少，但是纯粹从设计的角度来讲，腾讯的产品在国内产品中设计得算是不错的。

不过为什么腾讯的抄袭行为依然受到很多诟病呢？这在知识产权不完整的国度可能是必然的，在发达国家，象腾讯这种级别的大公司如果去做别人已经有的事情，可能优先会采取收购而不是抄袭。——如果采用收购的办法，那么腾讯可能获得的骂名会少很多很多很多。

但 是腾讯偏偏采用了抄袭的办法，其原因我觉得可能是：首先在这个特定的环境，抄袭并不存在太大的法律风险，而且腾讯对自己的用户体验设计能力有足够信心，认 为自己可以设计出一款不输于对手的产品。这后面的结果就很多了，我们看到腾讯在某些产品上确实达到了打压甚至超越竞争对手的程度。但是在很多产品上，他仍 然只是一个追赶者。——究其原因，也许因为：用户体验并不是产品成败的唯一决定因素。

@陈宾文 ，程序员

1. 庞大的QQ用户群。最核心的一个。tx致广大用户一封信之后，身边的QQ好友都想删掉QQ，但是因为QQ用户群太大，大到我们的亲朋好友 都在上面，没办法还是照常用，tx几天后股价回升就是证明。有了庞大用户群（6亿多），腾讯的即时通讯（QQ，企业QQ，邮箱，浏览器，影音），网络媒体 （综合腾讯网），娱乐业务（各种游戏，QQ音乐），增值服务（各种级别的会员，QQ空间），还有电子商务（QQ网购，腾讯拍拍）哪个不是依赖于这个庞大用 户群（6亿）搭建起来的，故而腾讯很多细分市场的产品很快的能赶上甚至超越同行公司或小公司（暂且不谈抄袭），这一点可以从QQ弹窗看出（腾讯每发布新产 品都会弹窗折磨我们一下）
2. 财力宏厚，人强马壮。财大好办事（废话），吸引的牛人自然多，加上在现在“没钱没车就没老婆”的现实时代，谁不想到一个平均月薪2.7万（好像又升了）的大公司工作？首先腾讯的管理层，技术层随便一抓就是行业牛，牛人多了，各种人才都会聚集过去。
3. 用户群有了，财力有了，人才也有了，那就开始谈工作的激情、细节。作为一个程序员，我觉得腾讯用户体验很好，很注重细节。
4. 国内一些关于版权、创新的一些法律漏洞造就腾讯的抄袭无懈可击。面对腾讯的抄袭行为，尽管很多人大骂腾讯没创新，但它还是合法的，没办法！

总结性结论（@Shi.k @胡东海  ）：

• 即时通信IM积累的深厚用户基础
• 以用户为中心的价值观 ，在pony领导下，深入每个员工，在这个价值观认同下，对用户、产品的态度非常一致，员工有自豪感和认同感，工作价值感强，有工作热情 （局外人看，这条不一定对）
• 高层战略方向把握到位，公司管理不错
• 腾讯抓住了人们线上社交需求，并维系了这种社交圈，形成了强大的生态链，这很难破坏，同时也因为这让他推出附加产品时推广起来变得更加便利；

转载自：http://www.mysqlops.com/2011/11/20/tt.html

主题：http://qconhangzhou.com/ShowNews.aspx?id=7

作者：Jeff Dean, Sanjay Ghemawat

原文：http://leveldb.googlecode.com/svn/trunk/doc/impl.html

译者：phylips@bmy 2011-8-17

出处：http://duanple.blog.163.com/blog/static/7097176720112643946178/

Files

LevelDB的实现本质上类似于Bigtable中的tablet(参见Bigtable论文5.3节)。但是，与论文中的具体的文件组织方式稍有不同，解释如下：

每个数据库由一组存储在指定目录下的一个文件集合组成。有如下几种文件类型：

Log files

日志文件(*.log)存储了最近的一系列更新。每个更新操作会被追加到当前的日志文件中。当日志文件达到预定义的大小后，会被转化为一个sorted table，同时一个新的日志文件会被创建出来以接受未来的更新。

同时会在一个内存结构(memtable)中保存一份当前的日志文件的一个copy。该copy会参与到每次读操作中，这样最新的已日志化的更新就能够反映到读操作中。

Sorted tables

sorted table (*.sst) 存储了一系列根据key值排好序的记录。每条记录要么是某key值对应的value，要么是一个针对该key值的删除标记。(删除标记会被用来去掉那些老的sorted tables中已过时的value值)。

sorted tables集合是通过一系列的level来进行组织的。从日志文件生成的sorted table会被放置在一个特殊的young level(也称作level 0)内。当该level下的文件数超过一定阈值(当前是4)时，该level下的所有文件会与level 1下与之有重叠的那些文件merge到一块，从而产生一系列新的level 1下的文件(我们会为每2MB的数据创建一个level 1文件)。

在level 0下的不同文件可能包含重叠的key值。但是其他level下的文件，它们的key range都是不重叠的(是指同一个level内部的文件不会重叠，不同的level之间会存在重叠)。设现有level L(L>=1),当level L下的文件总大小超过(10^L)MB时(比如，对应level 1就是10MB，level 2就是100MB，…),level L下的一个文件就会与level L+1下的所有与它有重叠的key的文件merge成一系列level L+1下的新文件。为最小化昂贵的seek开销，这些merge操作通过批量的读写操作，逐步的将新的更新从young level迁移到最大的level下。

Manifest

MANIFEST文件列出了组成每个level的sorted tables集合，对应的key range，以及其他一些重要的元数据。只要数据库被重新打开，就会产生一个新的MANIFEST文件(文件名会嵌入一个新的数字)。MANIFEST文件会被格式化为一个log，所有导致状态改变(文件增加或删除)的变更都会追加到该log里。

Current

CURRENT 是一个包含了最新的MANIFEST文件名称的文本文件。

Info logs

一些信息会被输出到名为LOG及LOG.old的文件中。
Others

其他用于各种目的的可能会产生的文件 (LOCK, *.dbtmp).

Level 0

当日志文件超过一定大小(默认1MB)时，会进行如下操作：

l  创建一个全新的memtable结构和log文件，同时将未来的更新指向它们

l  同时在后台进行如下操作：

?  将之前的memtable的内容写入到sstable里

?  丢弃该memtable

?  删除老的log文件及memtable

?  将新的sstable添加到level 0下

Compactions

当level L的大小超过自身的限制时，我们会在一个后台线程中进行compact操作。该操作会选择来自level L的一个文件，以及那些level L+1中所有与该文件重叠的文件。需要注意的是，即使level L下的这个文件只与level L+1下的某文件的一部分有重叠，也需要读取整个level L+1下的那个文件进行compaction，之后这个旧的level L+1下的文件就会被丢弃。另外：因为level 0很特殊(文件相互之间可能是有重叠的)，因此对于从level 0到level 1的compaction需要特殊对待：当level 0的某些文件相互重叠时，它的compaction就需要选择不止一个level 0的下的文件。Compaction会merge它选定的那些文件产生一系列新的level L+1下的文件。当当前输出文件大小达到目标大小(2MB)时，我们就会产生出一个新的level L+1下的文件。另外当当前输出文件的key range已经大的与10个以上的level L+2下的文件有重叠时，我们也会立即产生出一个新文件，而不一定非要等到它达到2MB，这是为了保证后面针对level L+1的Compaction不会从level L+2下获取过多数据。

老的文件会被丢弃，新的文件会被添加到服务状态。针对特定level下的Compaction是在整个key值空间内螺旋式地进行的。详细来说，比如对于Level L，我们会记住它上次compaction的那个最后的key值，在对于Level L的下次compaction时，我们会选择排在该key之后的第一个文件开始(如果没有这样的文件，那我们就再从头开始)。

Compaction会丢弃掉被覆盖的那些value值。同时如果更高level下的文件的key range不包含当前key时，针对它的删除标记也可以被丢弃掉{!更高level下的文件实际上是一些更老的值，如果它们包含该key，那么如果我们丢弃该低level下的删除标记，会导致该删除操作的丢失}

Timing

Level 0的compaction可能会从level 0下读取最多4个1MB文件，以及最坏情况下会读取所有的level 1下的文件(10MB)，这意味着，我们可能需要读14MB，写14MB。

除了比较特殊的Level 0的compaction，其他情况下我们会选取level L下的一个2MB的文件。最坏情况下，level L+1下可能有12个文件与它重叠(10是因为level L+1比level L大10倍，另外的2是因为在level L下的文件边界通常与level L+1下的边界并不是对其的)。因此compaction会读26MB，写26MB。假设磁盘IO带宽是100MB/s，最坏情况下的compaction可能需要大概0.5秒。

如果我们对后台操作进行一些限制，比如限制在全部IO带宽的10%，那么compaction时间可能会达到5秒。如果用户在用户以10MB/s的速度写入，我们就可能会创建出大量的level 0下的文件(可能会达到50，因为compaction需要5秒，而5秒内客户端已经又写入了50MB，而每个1MB，因此是50个)。这可能会显著增加读操作的开销，因为每次读操作都需要merge更多的文件。

解决方案 1:为了减少这种问题，我们可以在level-0下的文件数很大的时候，增加log切换的阈值。缺点是，阈值越大，相对应的memtable用掉的内存也就会越多。

解决方案2: 当level 0下的文件数上升很快时，我们可以人为地降低写操作速率。

解决方案3: 尽量降低merge的开销。由于大多数的level 0下的文件的block都已经缓存在cache里了，因此我们只需要关注merge迭代过程中的O(N)的复杂度。

Number of files

为降低文件数，我们可以为更高level下的文件使用更大的文件大小，取代固定的2MB文件。当然这可能导致更多的compactions过程中的波动。另外我们也可以将文件集合划分到多个目录下。

2011-02-04，我们在ext3文件系统下做了一个关于目录下的文件数与文件打开时间的关系的实验：

Files in directory   Microseconds to open a file

1000   9

10000  10

100000 16

看起来在现代文件系统中，没有必要进行目录切分。

Recovery

读取CURRENT文件找到最新提交的MANIFEST文件名
读取该 MANIFEST文件
清空垃圾文件
我们可以打开所有的sstable，但是使用惰性加载的方式会更好些…
将日志转化为一个新的level 0下的sstable
Start directing new writes to a new log file with recovered sequence#
Garbage collection of files

DeleteObsoleteFiles()会在每次compaction结束及recovery结束后调用。它会找到数据库中所有文件的名称。删掉除当前日志文件的所有日志文件。删掉那些不属于任何level及任何活动的compaction输出的table文件。

Immutable table文件格式

文件格式如下：

===========

<beginning_of_file>

[data block 1]

[data block 2]

…

[data block N]

[meta block 1]

…

[meta block K]

[metaindex block]

[index block]

[Footer]        (fixed size; starts at file_size – sizeof(Footer))

<end_of_file>

文件包含一些内部指针。每个这样的指针被称为一个BlockHandle，包含如下信息：

offset:          varint64

size:            varint64

(1)文件内的key/value对序列有序排列，然后划分到一系列的data blocks里。这些blocks一个接一个的分布在文件的开头。每个data block会根据block_builder.cc里的代码进行格式化，然后进行可选地压缩。

(2)在数据blocks之后存储的一些meta blocks，目前支持的meta block类型会在下面进行描述。未来也可能添加更多的meta block类型。每个meta block也会根据block_builder.cc里的代码进行格式化，然后进行可选地压缩。

(3) A “metaindex” block.会为每个meta block保存一条记录，记录的key值就是meta block的名称，value值就是指向该meta block的一个BlockHandle。

(4) An “index” block.  会为每个data block保存一条记录,key值是>=对应的data block里最后那个key值，同时在后面的那个data block第一个key值之前的那个key值，value值就是指向该meta block的一个BlockHandle。

(5) 文件的最后是一个定长的footer，包含了metaindex和index这两个blocks的BlockHandle，以及一个magic number。

metaindex_handle:    char[p];    // Block handle for metaindex

index_handle:        char[q];    // Block handle for index

padding:             char[40-p-q]; // 0 bytes to make fixed length

// (40==2*BlockHandle::kMaxEncodedLength)

magic:                 fixed64;    // == 0xdb4775248b80fb57

“stats” Meta Block

——————

该meta block包含一系列统计信息。Key就是该统计单元的名称，value包含一系列统计信息如下：

data size

index size

key size (uncompressed)

value size (uncompressed)

number of entries

number of data blocks

日志文件格式

日志文件内容由一系列的32KB blocks组成。唯一的异常是文件的末尾可能只包含一个部分块。每个block由一系列记录组成：

   block := record* trailer?

{!‘*’可以看做是正则表达式里的*,代表0个或n个record。‘?’也是，代表0个或者1个trailer }

   record :=

        checksum: uint32       // crc32c of type and data[]

        length: uint16

        type: uint8            // One of FULL, FIRST, MIDDLE, LAST

        data: uint8[length]

一条记录永远都不会从block的最后6个字节开始(因为它肯定放不下，看上面的记录checksum+length+type就占了7个字节了)。在这里组成trailer的最左处那些字节，要么完全是由0字节组成要么必须被读取者跳过。

此外: 如果当前block目前只剩下7个字节，然后现在需要添加一个非0长度的记录，那么写入者需要输出一个FIRST记录(不包含任何的用户数据)来填充该block剩余的7字节的空，然后将用户数据存放到下一个block里。

未来可以添加更多的类型。某些读取者可能会直接skip掉那些它不理解的记录，其他的一些可能会报告某些数据被skip掉了。

FULL == 1

FIRST == 2

MIDDLE == 3

LAST == 4

FULL 类型的记录包含了完整的用户记录.

FIRST, MIDDLE, LAST 用于那些被分成多个片段(通常是因为block的边界导致的)的用户记录的。FIRST表明是用户记录的第一个片段，FIRST表明是用户记录的最后一个片段，MID表明用户记录的中间片段类型。

Example: consider a sequence of user records:

   A: length 1000

   B: length 97270

   C: length 8000

A会作为一个FULL类型的记录存放在第一个block里。B 会被划分成三个片段:第一个片段会填充第一个block的剩余部分, 第二个片段会填充整个的第二个block, 第二个片段会填充第三个block的前面一部分. 最后，第三个block就只剩下6个字节，会作为trailer而留空。C将会作为一个FULL类型的记录存放在第四个block里。

===================

Some benefits over the recordio format:

(1) We do not need any heuristics for resyncing - just go to next block boundary and scan.  If there is a corruption, skip to the next block.  As a side-benefit, we do not get confused when part of the contents of one log file are embedded as a record inside another log file.

(2) Splitting at approximate boundaries (e.g., for mapreduce) is simple: find the next block boundary and skip records until we hit a FULL or FIRST record.

(3) We do not need extra buffering for large records.

Some downsides compared to recordio format:

(1) No packing of tiny records.  This could be fixed by adding a new record type, so it is a shortcoming of the current implementation,not necessarily the format.

(2) No compression.  Again, this could be fixed by adding new record types.

一、影响Linux服务器性能的因素
1. 操作系统级

• CPU
• 内存
• 磁盘I/O带宽
• 网络I/O带宽

2. 程序应用级

二、系统性能评估标准
影响性能因素

其中：
%user：表示CPU处在用户模式下的时间百分比。
%sys：表示CPU处在系统模式下的时间百分比。
%iowait：表示CPU等待输入输出完成时间的百分比。
swap in：即si，表示虚拟内存的页导入，即从SWAP DISK交换到RAM
swap out：即so，表示虚拟内存的页导出，即从RAM交换到SWAP DISK。

三、系统性能分析工具

1.常用系统命令
Vmstat、sar、iostat、netstat、free、ps、top等

2.常用组合方式
• 用vmstat、sar、iostat检测是否是CPU瓶颈
• 用free、vmstat检测是否是内存瓶颈
• 用iostat检测是否是磁盘I/O瓶颈
• 用netstat检测是否是网络带宽瓶颈

四、Linux性能评估与优化

1. 系统整体性能评估（uptime命令）

[root@server ~]# uptime
16:38:00 up 118 days, 3:01, 5 users, load average: 1.22, 1.02, 0.91
这里需要注意的是：load average这个输出值，这三个值的大小一般不能大于系统CPU的个数，例如，本输出中系统有8个CPU,如果load average的三个值长期大于8时，说明CPU很繁忙，负载很高，可能会影响系统性能，但是偶尔大于8时，倒不用担心，一般不会影响系统性能。相反，如果load average的输出值小于CPU的个数，则表示CPU还有空闲的时间片，比如本例中的输出，CPU是非常空闲的。

2. CPU性能评估

（1）利用vmstat命令监控系统CPU
该命令可以显示关于系统各种资源之间相关性能的简要信息，这里我们主要用它来看CPU一个负载情况。
下面是vmstat命令在某个系统的输出结果：

[root@node1 ~]# vmstat 2 3
procs ———–memory———- —swap– —–io—- –system– —–cpu——
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 0 162240 8304 67032 0 0 13 21 1007 23 0 1 98 0 0
0 0 0 162240 8304 67032 0 0 1 0 1010 20 0 1 100 0 0
0 0 0 162240 8304 67032 0 0 1 1 1009 18 0 1 99 0 0

• Procs

r列表示运行和等待cpu时间片的进程数，这个值如果长期大于系统CPU的个数，说明CPU不足，需要增加CPU。
b列表示在等待资源的进程数，比如正在等待I/O、或者内存交换等。

• Cpu

us列显示了用户进程消耗的CPU 时间百分比。us的值比较高时，说明用户进程消耗的cpu时间多，但是如果长期大于50%，就需要考虑优化程序或算法。
sy列显示了内核进程消耗的CPU时间百分比。Sy的值较高时，说明内核消耗的CPU资源很多。
根据经验，us+sy的参考值为80%，如果us+sy大于 80%说明可能存在CPU资源不足。

（2）利用sar命令监控系统CPU

sar功能很强大，可以对系统的每个方面进行单独的统计，但是使用sar命令会增加系统开销，不过这些开销是可以评估的，对系统的统计结果不会有很大影响。
下面是sar命令对某个系统的CPU统计输出：
[root@webserver ~]# sar -u 3 5
Linux 2.6.9-42.ELsmp (webserver) 11/28/2008 _i686_ (8 CPU)
11:41:24 AM CPU %user %nice %system %iowait %steal %idle
11:41:27 AM all 0.88 0.00 0.29 0.00 0.00 98.83
11:41:30 AM all 0.13 0.00 0.17 0.21 0.00 99.50
11:41:33 AM all 0.04 0.00 0.04 0.00 0.00 99.92
11:41:36 AM all 90.08 0.00 0.13 0.16 0.00 9.63
11:41:39 AM all 0.38 0.00 0.17 0.04 0.00 99.41
Average: all 0.34 0.00 0.16 0.05 0.00 99.45

对上面每项的输出解释如下：

• %user列显示了用户进程消耗的CPU 时间百分比。
• %nice列显示了运行正常进程所消耗的CPU 时间百分比。
• %system列显示了系统进程消耗的CPU时间百分比。
• %iowait列显示了IO等待所占用的CPU时间百分比
• %steal列显示了在内存相对紧张的环境下pagein强制对不同的页面进行的steal操作 。
• %idle列显示了CPU处在空闲状态的时间百分比。

问题
1.你是否遇到过系统CPU整体利用率不高，而应用缓慢的现象？
在一个多CPU的系统中，如果程序使用了单线程，会出现这么一个现象，CPU的整体使用率不高，但是系统应用却响应缓慢，这可能是由于程序使用单线程的原因，单线程只使用一个CPU，导致这个CPU占用率为100%，无法处理其它请求，而其它的CPU却闲置，这就导致了整体CPU使用率不高，而应用缓慢现象的发生。

3. 内存性能评估
（1）利用free指令监控内存
free是监控linux内存使用状况最常用的指令，看下面的一个输出：
[root@webserver ~]# free -m
total used free shared buffers cached
Mem: 8111 7185 926 0 243 6299
-/+ buffers/cache: 643 7468
Swap: 8189 0 8189
一般有这样一个经验公式：应用程序可用内存/系统物理内存>70%时，表示系统内存资源非常充足，不影响系统性能，应用程序可用内存/系统物理内存<20%时，表示系统内存资源紧缺，需要增加系统内存，20%<应用程序可用内存/系统物理内存<70%时，表示系统内存资源基本能满足应用需求，暂时不影响系统性能。

（2）利用vmstat命令监控内存

[root@node1 ~]# vmstat 2 3
procs ———–memory———- —swap– —–io—- –system– —–cpu——
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 0 162240 8304 67032 0 0 13 21 1007 23 0 1 98 0 0
0 0 0 162240 8304 67032 0 0 1 0 1010 20 0 1 100 0 0
0 0 0 162240 8304 67032 0 0 1 1 1009 18 0 1 99 0 0

• memory

swpd列表示切换到内存交换区的内存数量（以k为单位）。如果swpd的值不为0，或者比较大，只要si、so的值长期为0，这种情况下一般不用担心，不会影响系统性能。
free列表示当前空闲的物理内存数量（以k为单位）
buff列表示buffers cache的内存数量，一般对块设备的读写才需要缓冲。
cache列表示page cached的内存数量，一般作为文件系统cached，频繁访问的文件都会被cached，如果cache值较大，说明cached的文件数较多，如果此时IO中bi比较小，说明文件系统效率比较好。

• swap

si列表示由磁盘调入内存，也就是内存进入内存交换区的数量。
so列表示由内存调入磁盘，也就是内存交换区进入内存的数量。
一般情况下，si、so的值都为0，如果si、so的值长期不为0，则表示系统内存不足。需要增加系统内存。

4.磁盘I/O性能评估
（1）磁盘存储基础

• 熟悉RAID存储方式，可以根据应用的不同，选择不同的RAID方式。
• 尽可能用内存的读写代替直接磁盘I/O，使频繁访问的文件或数据放入内存中进行操作处理，因为内存读写操作比直接磁盘读写的效率要高千倍。
• 将经常进行读写的文件与长期不变的文件独立出来，分别放置到不同的磁盘设备上。
• 对于写操作频繁的数据，可以考虑使用裸设备代替文件系统。

使用裸设备的优点有：

• 数据可以直接读写，不需要经过操作系统级的缓存，节省了内存资源，避免了内存资源争用。
• 避免了文件系统级的维护开销，比如文件系统需要维护超级块、I-node等。
• 避免了操作系统的cache预读功能，减少了I/O请求。

使用裸设备的缺点是：

• 数据管理、空间管理不灵活，需要很专业的人来操作。

（2）利用iostat评估磁盘性能
[root@webserver ~]# iostat -d 2 3
Linux 2.6.9-42.ELsmp (webserver) 12/01/2008 _i686_ (8 CPU)

Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 1.87 2.58 114.12 6479462 286537372

Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 0.00 0.00 0.00 0 0

Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 1.00 0.00 12.00 0 24
对上面每项的输出解释如下：

• Blk_read/s表示每秒读取的数据块数。
• Blk_wrtn/s表示每秒写入的数据块数。
• Blk_read表示读取的所有块数。
• Blk_wrtn表示写入的所有块数。

1. 可以通过Blk_read/s和Blk_wrtn/s的值对磁盘的读写性能有一个基本的了解，如果Blk_wrtn/s值很大，表示磁盘的写操作很频繁，可以考虑优化磁盘或者优化程序，如果Blk_read/s值很大，表示磁盘直接读取操作很多，可以将读取的数据放入内存中进行操作。
2. 对于这两个选项的值没有一个固定的大小，根据系统应用的不同，会有不同的值，但是有一个规则还是可以遵循的：长期的、超大的数据读写，肯定是不正常的，这种情况一定会影响系统性能。

（3）利用sar评估磁盘性能
通过“sar –d”组合，可以对系统的磁盘IO做一个基本的统计，请看下面的一个输出：
[root@webserver ~]# sar -d 2 3
Linux 2.6.9-42.ELsmp (webserver) 11/30/2008 _i686_ (8 CPU)

11:09:33 PM DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util
11:09:35 PM dev8-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

11:09:35 PM DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util
11:09:37 PM dev8-0 1.00 0.00 12.00 12.00 0.00 0.00 0.00 0.00

11:09:37 PM DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util
11:09:39 PM dev8-0 1.99 0.00 47.76 24.00 0.00 0.50 0.25 0.05

Average: DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util
Average: dev8-0 1.00 0.00 19.97 20.00 0.00 0.33 0.17 0.02
需要关注的几个参数含义：

• await表示平均每次设备I/O操作的等待时间（以毫秒为单位）。
• svctm表示平均每次设备I/O操作的服务时间（以毫秒为单位）。
• %util表示一秒中有百分之几的时间用于I/O操作。

对以磁盘IO性能，一般有如下评判标准：
正常情况下svctm应该是小于await值的，而svctm的大小和磁盘性能有关，CPU、内存的负荷也会对svctm值造成影响，过多的请求也会间接的导致svctm值的增加。
await值的大小一般取决与svctm的值和I/O队列长度以及I/O请求模式，如果svctm的值与await很接近，表示几乎没有I/O等待，磁盘性能很好，如果await的值远高于svctm的值，则表示I/O队列等待太长，系统上运行的应用程序将变慢，此时可以通过更换更快的硬盘来解决问题。
%util项的值也是衡量磁盘I/O的一个重要指标，如果%util接近100%，表示磁盘产生的I/O请求太多，I/O系统已经满负荷的在工作，该磁盘可能存在瓶颈。长期下去，势必影响系统的性能，可以通过优化程序或者通过更换更高、更快的磁盘来解决此问题。

5. 网络性能评估

（1）通过ping命令检测网络的连通性
（2）通过netstat –i组合检测网络接口状况
（3）通过netstat –r组合检测系统的路由表信息
（4）通过sar –n组合显示系统的网络运行状态

转载自 http://www.itlearner.com/article/4553

当一个系统越来越大之后，就需要一个架构师了。

架构师需要考虑的问题有很多，考虑的广度和深度，决定了架构师的高度，和系统架构的高度。

单单实现一个功能，实现一个系统，其实都是再简单不过的事情。很多体力活，拷贝，粘贴，输入，编译，调试，打包，部署，测试，无非就是这些。

但，维持一个大的在线的系统，更重要的不是这些，而是出各种异常情况的时候，系统的表现如何。

比如，数据库主库挂了，系统是完全不可用，还是能够优雅的降级为只读？还有一种情况比完全不可用更差，那就是：开发者也不知道会发生什么，系统的行为是未定义的，取决于机器，网络，报错的error code，运维人员昨天下班回家的顺序。。。

再比如，数据库辅库挂了，系统会自动切换辅库，甚至切回主库，还是拒绝服务？如果要实现连接池自动切换，怎么做？DNS 不是一个好的办法，但好歹“基本可用”。

类似的，memcache 挂了？redis 挂了？在大公司，做大系统，几乎每个结点都有 HA ，所以代码中做好处理就行了。万一系统中某个模块因为种种原因没有 HA，挂了以后会如何？是简单的单个模块不可用，还是会拖累到整个系统崩溃？

系统大了以后，开发团队也会膨胀，紧接着，更多的问题来了：

很多人修改代码，肯定会使用版本管理工具，svn？git？自己会用什么，想用什么并不重要，重要的是整个团队的共识。需要追踪问题，jira 还是 redmine ？文档怎么管理？需要一个 wiki 么？还是写 blog ？不管怎样，word 文档是应该被抵制的。有的团队甚至要求成员们的本机的开发环境统一，比如 eclipse 统一设置4个空格替代 tab ，比如本地的代码所在的目录。如果大家都用 windows ，也许问题会少一些，但是，如果有人用 mac，又有人用 ubuntu 甚至 FreeBSD 呢？

修改完代码是需要先测试才能上线的。同一时间多个需求并行的情况也不少见，那么就需要多个测试环境。如果系统比较单纯，这个问题也许就不那么严重。如果运气不好，一个系统由超过3个独立模块组成，有各种的队列异步处理，远程过程调用，多 IDC 部署，那就悲剧了，意味着部署一个测试环境需要一个新人付出以天计算的时间才能完成。而且，容易出错。

多个人修改一份代码，每个人都尽量只加不改，更不要说减了，到后来，代码已经完全丧失了它原本的模样，更糟糕的是，谁也不敢大刀阔斧的改，因为没有人对系统有足够清晰的，足够全局的了解。每一行代码都是一个坑，总有一天会有人掉进去的。还有，大家各自负责一块，互相之间以约定的接口进行调用，这样，很容易就会产生理解不一致，以及接口的滥用。

修改完代码，合并到 trunk 或者 master ，该上线了。如果系统只部署在小于 10 台机器上，那一般不会被认为是大的系统。如果一次上线就需要改动超过 100 台机器，单纯的上线也是一个非常大的工作量，更不要说上线完成之后的验证，可能的意外情况处理，回滚。修改了代码或者配置文件，也就意味着可能的bug风险。要不要引入 code review ？上线流程？签字审批之类的，经常会被写代码的人抵触。但是不这么做，总有一天受伤的会是自己。

大的系统，线上的“灵异”问题是一个很头疼的事情。一方面，它无法稳定重现，另一方面，数据量太大，log 不可能记的那么全，而且，系统太大，模块之间各自为政，处理过程经常串不起来，没法“重演”。机器设备一多，各种与设备相关的问题也就多了，网络波动？路由不通？ulimit ？硬盘满了？为了避免这样的问题，流程化，自动化，标准化就很有必要了。上线新代码，上线新设备，上线新资源都必须要有章可循。

为了避免某一个资源，某一个模块的故障导致整个系统的瘫痪，模块隔离，服务化就势在必行。将模块抽象成服务，资源与资源之间做到物理隔离，做好容灾和降级方案，以备不时之需。

运维，监控，就不再多说了，看起来简单，真的做起来，就一个字：难！

在公司里面做事，资源总是有限的，需求总是无穷的。如何用有限的资源，多快好省的完成紧急而又重要的任务，如何尽快搞定紧急但不重要的扑火，如何将重要但不紧急的事情按部就班的安排下去，如何拒绝又不重要又不紧急的打扰，这也是一种能力。各个相关的部门，自己有事需要他人帮忙的时候，他们总是会很忙的，他们有事需要自己帮忙的时候，他们的事情总是又紧急又重要的。一方面尽量避免公司政治，另一方面，又避不开种种麻烦的事。

一边做事，还要一边做人。内部的技术交流，培训，外部的演讲忽悠，有机会要上，没有机会创造机会也是要上的。