分类： 电脑技术

facebook的bigpipe

facebook的bigpipe是一种技术，能使一个网页的加载变得更快。
在 http://velocity.oreilly.com.cn/ppts/ChanghaoJiang.pdf 这个PPT的39-79页有详细说明。

我们知道一个HTML页面的加载时间主要分为三部分：服务端生成、网络时延、浏览器渲染。
在服务端生成数据的时候，浏览器是处于闲置状态的，反之亦然。
bigpipe的思想就是将页面分块加载，通过巧妙的JS逻辑，尽可能充分的利用服务器和浏览器的时间（见PPT43页）。
此外，为了对搜索引擎友好，也同时支持页面的single flush。

MySQL HandlerSocket Plugin

原文见：http://www.osseye.com/?p=382

说说我的理解，MySQL HandlerSocket Plugin 是一个在 Mysql internal storage engine API 基础上构建的daemon程序。

为什么Mysql internal storage engine API比MySQL直接查询要快？因为直接查询的时候，open/close表的开销占了很高的比例，且互斥竞争比较严重。
MySQL HandlerSocket Plugin绕开了MySQL的client API，对open表的session进行了reuse，并裁剪了很多功能（如SQL parsing, Making Query Plans），实现了一套接近于NoSQL的接口。

我认为大家可以尝试一下这个API，是优化数据库性能的另一条途径。

redis的一些tips

这是我计划本周五在部门内分享的内容，先贴到这里：

Redis是一款最近比较热门的Key-value数据库，它的代码量少，配置简单，与memcache同样轻量级，对于了解NoSQL是一个很好的入口，相信通过介绍之后，无论是前端和后端开发工程师，都会迅速的爱上这款软件！

    * Intro:
          o http://dreamhead.blogbus.com/logs/61443218.html
          o http://labs.alcacoop.it/doku.php?id=articles:redis_land
          o http://code.google.com/p/redis/wiki/ProtocolSpecification
          o http://code.google.com/p/redis/wiki/CommandReference

    * Features:
          o Key-value db
          o Fast: all data are loaded in memory and saved on disk
          o Supporting data types: Strings(<1Gb), Lists, Hashes, Sets, Ordered sets.
          o Interfaces: push/pop、add/remove、sort
          o Replication:
                + 一个master支持多个slave
                + Slave可以接受其他slave的连接来替代他连接master
                + 复制在master是非阻塞的，而在slave是阻塞的
                + 复制被利用来提供可扩展性，在slave端只提供查询功能及数据的冗余

    * Download:
          o http://code.google.com/p/redis/

    * Install:
          o http://blog.chinaunix.net/u3/102568/showart_2339142.html

    * Start Server: ./redis-server
    * Close Server: ./redis-cli shutdown
    * Command Line Client: ./redis-cli
    * Bindings: http://code.google.com/p/redis/#Supported_languages
    * APIs: http://code.google.com/p/redis/wiki/CommandReference
    * Best Practices:
          o Counter
          o message queue
          o user db
          o Autocomplete: http://antirez.com/post/autocomplete-with-redis.html
          o Foursquare.com

我如何进行知识管理

　　我们每天都接触到大量的信息，必须要有一个沉淀的机制使其转化为知识，否则在重新利用它们的时候，会消耗不必要的时间。下面我将自己管理知识的方法整理出来，供读者参考。

管理要做的事
　　最快捷的方式是在桌面上新建记事本；如果你需要用复杂的格式记录它们，建议用onenote；如果你的手机是IPhone、Android、Blackberry系列的，那么恭喜你，还可以使用evernote将你的文件随身携带；不要忘记，小纸条也是很灵活的方式。
管理你的文档
　　首先要保证你辛苦编写的文档不丢失，为此，我向你推荐几款工具：如果你有自己的备份空间，如FTP、共享文件夹等等，建议使用syncback，它会将你的文档目录与服务器端进行双向同步，显然也没有空间和网速的制约；你还可以用前面提到的evernote或微软的live mesh来进行同步，它们都为我们提供了若干G的共享存储空间。
　　其次要保证你的文档能被随时找到，我强烈向你推荐Google桌面搜索，它通过为你电脑上的文件编制索引，方便你对其进行查找；另外，不建议使用微软自己提供的windows search，我的Thinkpad X201笔记本，只要启动了它的索引服务，CPU温度就会从正常的45度左右，飙升到80度以上，为了节能和CPU长寿，只得卸载之，而Google桌面搜索就没这方面的问题了。
管理下载的文档
　　下载的文档特指电影、音乐等尺寸较大大的文件，如果不幸丢失，经济损失尚小，而备份它们的成本却最高。笔者目前也没有想到一劳永逸的办法，毕竟自己花钱购置硬件，总有一个寿命问题。相比较来说，买一块硬盘，加个硬盘盒，是比较经济的存储方式。
管理你的电脑
　　如果电脑某天不幸需要重装，你便需要手忙脚乱的备份一大堆存放在C盘中的数据，如果平时就将你的数据打理的井井有条，就可以避免这一麻烦。现有几个小办法向读者提供：使用驱动备份专家之类的软件将你的驱动程序备份到别处，如果先前购置的硬件中有驱动光盘，建议将整张光盘做成ISO镜像存放在硬盘上；打开“我的文档”的属性窗口，修改文档路径为C盘以外的某个目录并转移；使用类似Firefox Sync的工具同步或备份你的浏览器书签等数据。

　　相信大家也有许多自己的经验，欢迎到新浪微博(@房如华bluetent)上与我交流，谢谢。

一些关于SEO的感想

　　本周有幸用两天多的时间，与业界顶级的SEO咨询师进行了面对面的交流，收获颇丰。除掉80%不能说的内容，还是有一些common的经验能够分享给大家。这篇文章本身也顺便看看能否带来足够多的搜索引擎流量吧，呵呵。
　　1、对于百度，平级的文件形式的url要比目录形式的便于收录。
　　2、在页面里主动做相关网站的链接，并不一定是坏事。假设你的网站是A，相关网站是B，那么，用户从A链到B，比用户从搜索引擎直接点到B要好，此时搜索引擎会认为A更有价值，因为被更多的人点击了。
　　3、百度关注网站外链的数量，而Google更关注其质量。
　　4、简单来说，要先保证网站内链的良好结构，再做好外链，否则你可能会浪费很多精力。
　　5、有一些SEO公司可能在向你灌输错误的理论，因为他们需要你持续的为他们的服务付费，并产生依赖，尤其是一些让你购买他们外链的公司。

从构建一个稳定的服务说开去

　　我本科是学自动化的，所以工作六年来，一直致力于如何让一台服务器尽可能在无值守的情况下保持工作。但当前两天公司一台服务器的文件系统因硬件原因莫名其妙只读了之后，我突然打算反思自己这种追求完美的观点。
　　一个服务，放在那里，没人管他，想死是件很容易的事，而且往往都很出人意料，我来从记忆中随便抽些片段：
　　关于硬盘满：
　　某天夜里备份一个大目录，先tar后gzip，硬盘满，其上的MySQL服务无法写入，挂掉。
　　某天tmp分区满，某HTTP Server无法创建socket fd，挂掉。
　　某个脚本突然多了很多输出，向/var/mail下发了n多消息，导致var分区满，挂掉。
　　关于内存满：
　　某个不靠谱的服务需要固定占用2G内存，它为了防止内存泄漏，每天凌晨粗暴的自我重启。某天重启的时候，发现操作系统的内存忽然不够它挥霍了。
　　在apache的prefork模式下，在并发超大的时候，把系统内存吃光。
　　关于单点故障：
　　数据库通常配成一主多从，但主的服务器总有一天会出问题。
　　若干T的图片服务器，硬盘总是有寿命的，不多说了。
　　NFS有时候也会给服务添麻烦，比如某个不靠谱的程序员在NFS Server上跑统计脚本，把其它服务器都拖死。
　　LVS、L7负载均衡器、DNS Server、时间服务器、交换机、路由器、网卡、电源……冗余的代价太高了，有时候我们只能假设它们不会坏，并配上一系列聊以自慰的监控程序。
　　还有些不重要的服务器，直接放在公司，公司的机房没有UPS，也不一定有备件。如果硬件坏了，虽不影响线上服务，但恢复需要很长时间。如果它是一台开发服务器，那也足以挫伤组员的斗志，估算一下间接损失也可能上万。
　　关于不健壮的业务逻辑：
　　到memcache的连接，打开后忘记关闭，一群请求过来，memcache挂掉。
　　某个SQL语句锁住了整张表，或者创建了超大的临时表，可能几秒内就会把1000个连接占满。
　　内部的HTTP通讯没有设置合理的超时时间，导致上游压力过大时，内部因连接堆积而瘫痪。
　　异地备份程序没有确认数据已经传输完毕，就删除了本地数据。
　　其它：
　　某天你的网站突然被搜索引擎眷顾了，引发了超大流量，被IDC限速，于是你的服务器就不停的丢包，但你此时还沉浸在幸福当中，却忘了去看网络流量图。
　　你的隔壁机柜服务器中毒了，可防火墙在你们的上级节点。

　　以上情况如果平均每个月出现一次，就已经让人足够崩溃了。可是真有那么多Mr. knowall，或者先知，能提前规避这一切吗？从这里可以看出技术管理的重要性，好的团队，好的沟通机制，可以抵抗一些基本风险。说说我建议做和不建议做的：
　　建议：
　　核心的服务逻辑尽早做的足够强壮，并封装好，放到整个体系中复用、测试，不断完善并稳定下来。用你最放心的人做这件事情，不要让其他“不重要”的人去修改这个核，要把上述风险控制在你手里。
　　如果现有的架构已经老旧不堪，考虑新做一个可复用的核，然后一个服务一个服务迁移过去。
　　内部服务过于HTTP化也不好，内部的通讯是要消耗额外资源的，除非你一定要用nginx来做高可用部署。有些服务可以不Listen端口，而改为Listen socket fd。
　　有些服务，如果开源的软件已经做了很多年了，就不要自己再做一次，哪怕有创作的欲望，也要克制。把开源软件配置好，不比自己写的技术要求低。
　　不建议：
　　亡羊补牢是短视的做法，出现了问题，不要就事论事，关键还要深层次的去想，团队管理和沟通出现了什么异常，而不要划分责任或甚至逃避。我感觉，一个技术相对差的团队不太容易把一个业务搞死，但一个缺乏管理的团队一定会把一个业务搞死，而且是以最浪费资源的方式。

　　突然想到有两台服务器的服役期快三年了，得想办法赶紧把上面的重要服务挪走。梦想着把我们的系统逐渐改为一个去中心化的架构，这样服务稳定性对硬件寿命的依赖程度就低了。
　　

搞定nginx+php_fpm

　　最近几天利用春节放假的时间，搞定了nginx+php的编译与配置，将源代码和安装脚本都用一个git库维护起来，支持以下特性：

  • 在服务器的任何一个目录解压均可，一个脚本完成所有编译工作。
  • 将loadbalancer和webserver用不同的配置选项编译。
  • php的配置选项与debian发行版保持完全一致，包括suhosin patch。

　　拖了一年多才完成此事，也算是后知后觉了。计划在三月份，将我负责的所有web服务器及负载均衡器切换到这个体系下。

将outlook的联系人与手机地址簿同步

方法很简单，以Nokia第三版为例，只需要三步操作即可：
1、到这里下载GO Contact Sync，它可以将Outlook的联系人双向同步到Gmail的联系人里。
2、依照Google mobile的步骤，配置自己的Nokia第三版手机。
3、点击手机的“同步”按钮。
非常的方便，而且信息很全面，甚至Google Talk联系人的小头像都同步到手机上了，呵呵。