福林雨-博客 -- IT技术博客大学习 -- 共学习共进步！

在这篇文章中，我想强调一个陈旧的观念，但它现在更应该被关注：Unix哲学（philosophy）。我将展示这种哲学与主流数据库设计方式截然不同的原因；并探索如果现代分布式数据系统从Unix中学到了一些皮毛，那它在今天将发展成什么样子。

Google公布了它的下一代集群管理系统Omega(下载地址)的设计细节。论文中谈到Google经历的三代资源调度器的架构，分别是中央式调度器架构(类似于Hadoop JobTracker，但是支持多种类型作业调度)、双层调度器架构(类似于Apache Mesos和Hadoop YARN)和共享状态架构(就是Omega)，并分别讨论了这几个架构的优缺点。

• 转：从张绍刚vs刘俐俐谈技术面试中的非技术元素

很早之前就想总结一下技术面试中的非技术元素。最近张邵刚很火，网民愤很大，正好借个机会写点东西。本文一不讨论节目本身；二尽量不评价主持人和参赛者个体；三不上纲上线。我自己面试和被面试的经验都有限，观点难免偏颇狭隘，只希望管中窥豹，抛砖引玉。欢迎补充指正。目的面试唯一的目的是衡量求职者是否满足职位要求，尽可能全面的收集相关信息。一切无关活动都应该避免或减少。例如，评价求职者的表现应该在面试结束后综合各种信息完成，尽量不要当场透露给对方。有经验的面试官会在过程中做动态评估，灵活更换问题或方向，目的是获取更多更可靠的信息。即便如此，当面批评求职者的表现，哪怕只是面露不屑，也是非常糟糕的。求职者一般都很紧张和忐忑，面试官的任何负面评价乃至表情语气都会直接影响他们的表现，降低整个面试甚至接下来其他面试的价值。

• 乱谈技术线的成长

很多做技术的人都希望能坚持做技术，而不是转管理。但在当前国内的环境下，能提供坚持做技术的氛围的公司却寥寥无几。技术做的好一些后，除了设计技术方案并推动实现以外，不可避免的要开始带团队，开始跟项目或推项目，开始盯需求讨论，开发进度，测试，bug修复等等。最终，我们做的是 Architect + Team Leader + Project Manager 的混合体，而不是我们原来期望的 Researcher 。在这里我们不讨论如何回到 Researcher 的道路上去，只讨论如何提升自己，做一个合格的 Architect + Team Leader + Project Manager 混合体 1. 保持对技术的关注和热情不管到什么时候，在什么地方，技术是技术人的立身之本。即使这段时间里自己在忙的事情，跟技术一点关系都没有，但我们还是要时刻保持对技术的关注，广度和深度并进，在需要的时候才能给出

• 服务治理过程演进

在大规模服务化之前，应用可能只是通过RMI或Hessian等工具，简单的暴露和引用远程服务，通过配置服务的URL地址进行调用，通过F5等硬件进行负载均衡。 (1) 当服务越来越多时，服务URL配置管理变得非常困难，F5硬件负载均衡器的单点压力也越来越大。此时需要一个服务注册中心，动态的注册和发现服务，使服务的位置透明。并通过在消费方获取服务提供方地址列表，实现软负载均衡和Failover，降低对F5硬件负载均衡器的依赖，也能减少部分成本。 (2) 当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。这时，需要自动画出应用间的依赖关系图，以帮助架构师理清理关系。 (3) 接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？

• 用 redis 实现和保护 12306

网上大家都在流传如何更好的实现一个 12306 ，作为一个技术人员，碰到如此难得的机会，忍不住也想跟着忽悠一把。纯粹从技术角度出发，来设计一个架构和实现方案是非常容易的。但我相信，真实的 12306 的架构师，需要考虑的不仅仅是技术实现，还有数不清的历史包袱，现实约束，甚至人为限制。所以，这里的描述，只是技术人员关起们来，自己的 YY ，大家姑且看看就行，别太当真。 12306 当前的问题，无非是僧多粥少加定时放票引起...

• leveldb 的实现

Files LevelDB的实现本质上类似于Bigtable中的tablet(参见Bigtable论文5.3节)。但是，与论文中的具体的文件组织方式稍有不同，解释如下：每个数据库由一组存储在指定目录下的一个文件集合组成。有如下几种文件类型： Log fil...

• Linux服务器性能评估

对以磁盘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系统已经满负荷的在工作，该磁盘可能存在瓶颈。长期下去，势必影响系统的性能，可以通过优化程序或者通过更换更高、更快的磁盘来解决此问题。

• 架构师的思考

当一个系统越来越大之后，就需要一个架构师了。架构师需要考虑的问题有很多，考虑的广度和深度，决定了架构师的高度，和系统架构的高度。单单实现一个功能，实现一个系统，其实都是再简单不过的事情。很多体力活，拷贝，粘贴，输入，编译，调试，打包，部署，测试，无非就是这些。但，维持一个大的在线的系统，更重要的不是这些，而是出各种异常情况的时候，系统的表现如何。比如，数据库主库挂了，系统是完全不可用，还是能够...

• URL 设计准则

T.cn 短链项目上线，log 发现很多奇形怪状的 url ，进而引起了各种莫名其妙的 bug。为了兼容它们，本来整洁的代码被种种 work around 弄的面目全非。找到一篇 URL 设计准则，转载于此，与大家共勉。 URL 设计是 Web 设计中常被忽视的东西，事实上 URL 非常重要，这不仅是一个网页唯一的路径，还涉及到你的站点是否干净，友好。本文讲述 URL 这个司空见惯的 Web 元素中包含的大量不应为忽视的知识，准则与最佳实践。需要注...

• 本周扑火之 http client 慢连接问题

短链服务自从上线到现在，已经出了 5 回故障了：第一次，某著名的刚过百年的大学，紫荆公寓的一个哥们，写了一个诡异的抓站程序，发出来的 http 请求不合法，导致 jetty 缓冲区出错（微博上的直播）。给 Jetty 提了一个 bug，但开发人员说没法重现。我自己写的程序也没法重现当时的情形。自己写了一个 Utf8StringBuilder，覆盖了 Jetty 的版本，增加了出错重置功能，就算 fix 了。第二次，log 把磁盘写满了。运维人员的低级失误...

• 本周扑火之 redis 不给力

Social Graph 高速接口，当前我们使用 Redis 存储。但在实现的过程中，发现了诸多的问题。 48G 内存的机器上部署了 2 个 Redis 进程，一个 Redis 占用超过 21 G 内存后，在快速写入的过程中同时进行一次 bgsave ，就将机器给弄挂了（微博上的直播）。我们对 Redis 的监控远不如对 Mysql 之类的完善，以至于 Redis 机器假死，居然没有触发任何的报警。在经过几天的 debug 后，终于找到了问题所在，复杂的上线流程：源码 svn 合 tru...

• 关于 Jetty Continuation

领导说，我们不能绑定在某个产品，某个框架，某个技术实现上。所以当我们希望使用 jetty 的 continuation 技术的时候，我们必须对它进行一个包装，以保证将来如果需要，我们可以用其它的技术或框架进行替换。

• 几种常见的基于Lucene的开源搜索解决方案对比

几种常见的基于Lucene的开源搜索解决方案对比

• 【转】基于lucene实现自己的推荐引擎

采用基于数据挖掘的算法来实现推荐引擎是各大电子商务网站、SNS社区最为常用的方法，推荐引擎常用Content-Based 推荐算法及协同过滤算法（Item-Based 、User-based）。但从实际应用来看，对于大部分中小型企业来说，要在电子商务系统完整采用以上算法还有很大的难度。

• 挑战邮箱搜索（续一）

首先是排序的问题。Lucene 默认的排序考虑了很多因素，套用到邮箱搜索的结果里，很多时候反而显得结果很混乱，不同文件夹，不同时间，不同主题，不同发件人的邮件混在一起，更严重的是，已读邮件和未读邮件混在一起了：已读和未读邮件的 css 样式是不一样的，混在一起的结果就是，界面看起来非常混乱。

• 挑战邮箱搜索

邮箱搜索与其它的搜索引擎最大的区别莫过于每个用户只能搜索自己的邮件内容。搜索引擎一般都是开放性的搜索，每个用户都有权访问所有的索引项目，每次搜索请求都会在所有的索引项目中进行匹配。而邮箱搜索是私密搜索，每个用户只能访问索引中很小的一部分数据，相应的，也就可以将每个用户的索引单独存放，以加快建索引和搜索的速度。

• 学习：一个并发的Cache

学习：一个并发的Cache

• 转：NoSQL生态系统

空前的数据量正在驱动商业寻找传统关系型数据库的替代方案,它已经为我们服务30多年了(今年5月份ACM刚刚给关系型数据庆祝40岁生日).总体来讲,这些替代方案就是目前知名的“NoSQL数据库.”关系型数据库的基本问题是无法处理许多现代的工作负载.有三个具体的问题领域:向外扩展(Scale out)类似于Digg(3TB的绿色徽章数据)或Facebook(50T 的收件箱搜索数据)或Ebay(总共2PB的数据)的数据集,单机性能限制以及僵化的概要设计.

• 音乐搜索的极致

12530 PC客户端咪咕 (页面最下方有一个很不显眼的下载链接) 搜索原本计划是今天上线内测，20号正是随资源库后台一起上线，其实昨晚就已经替换掉了正式服务器上原来的接口。正因为昨晚悄无声息的上线，原本已经下班走到家门口的我们，又被电话叫回公司，来解决一个刚刚发现的bug。音乐搜索，第一期还没有特别做歌词的搜索，只对歌手名，歌曲名，专辑名做优化，加上数据量本身就很小（一共才不到100万首歌），只好在查询上做文章...