今天一天跟房子干上了。 http://www.soufun.com/house/zt/201102/312kft.html这个是当初是报名的网址。

地址，当初这上面可是写好有午餐和礼品，可一天下来什么都没有，还好之前出门的时候带了点吃的，不然今天可是饿着肚子了。搜房网你去死吧。整的什么团阿，看来开发商给你的钱是少了，不然你怎么会这样抠门呢。还是你自己都私吞了。本来我参加这种活动就是奔着这些小礼品去的，就跟上次去参加MSN车友会一样，吃吃饭，开开卡丁车，中中奖。而这次搜房网看房团居然什么都没有，要啥都没有我参加看房团干嘛？ 给你做活广告？ 你们也就这点小心思。北苑又不是不认识，也不是太远。祝愿你们股票早日跌到1美元以下直接退市。 早上参加了搜房网北一路线的看房团，主要是北苑那边3个楼盘。第一个什么天润福熙大道只有TMD尾房，在北苑这种地方还建高端住宅，旁边一排高压线，真正有钱人会买房住在高压线旁边？ 不知道是不是开发商拿地价格太高。宣传单上写着2W6一平，怎么到你们嘴里就是3W1一平了呢。后面的世华泊郡价格也一般，2W5单价，就开2栋楼，看来大的开发商都喜欢搞饥饿销售。周边环境实在是太差了。而最后一个筑花年连价格和开盘时间都没定呢，样板间也没有。户型就一种，看来开发商都把买房的当傻子来看了。大家都在观望着。我同样也观望着。 今天路上还碰到好多摆摊的中介，号称请听政策分析。看来中介们好想找人聊聊天啊。 后来又坐地铁是拿退房的钱去了，汗，手续都走完了还要经过20个工作日才能打到卡里，这些开发商都真够黑的。看到财务那边一堆退房的单子。接着去看了红木林。红木林户型倒是挺多，但是同样也是没有样板间，不过好户型我看下来就一种。要到5月份才有样板间，所以还是到时候再说吧。今天就先排个VIP号。之前还让这边的亲戚关注下说开盘了告诉我一声，结果也没有通知，还好问了下销售。 从现在来看也就远洋一方从户型和位置上还不错，只是价格稍贵，我看上的那个户型均价22000呢。比其它的户型都贵，要是再打个8折啥的就好了。那边都快靠近通州了，也就值这个价格吧。当然当初2W5均价买的那些人闹事算不算是开发商的策略呢？ 现在谁不知道一方降价打折呢。 而且这当中发现好多违规的东西，住建委不是要客户首付款在房屋封顶前都存在住建委专用账户上，可看了半天好像就远洋一方是这样干的，而其它楼盘都是存到开发商自己的账户。这不是很明显的违规吗，可销售说了这个都是很正常的。看来大多开发商都是缺钱的。同志们再摒摒吧，等开发商更缺钱的时候房价才会腰斩呢。

昨天说了nginx的几个问题，

由于我现在支持的主要是通用CDN，也就是小图片和CSS以及JS这些东西，并没有做大文件的cache。而问了我们视频部门他们也根本不用nginx作为cache使用，所以有些问题还是没考虑周到。 一个问题是之前发现的，在做tmpfs的时候，当你设置的cache大小为tmpfs的90%的时候，一旦要缓存的内容大于这个90%的时候，nginx会自己崩溃掉。这个我明天做个测试再重现一下，现在有点忘记原因了，好像是tmpfs会占用到实际的磁盘才导致的。 另外一个其实是upstream的问题，这个是一个新浪的老兄提的，基本现在是无解。问题是：比如平均一个文件10M，你在磁盘上存3000个文件，然后模拟多个客户端去访问，因为shm一开始是空的，所以都会去后端拽文件，我们放慢这个拽的过程，比如说网络不好吧 呵呵，那么第一个请求发现不在lookup失败，就会去upstream取数据，边取边向downsteam发，并且存在一个临时文件中，这时第二个请求来了也请求这个文件，因为第一个请求没有处理完，所以第二个请求找不到目标文件只好继续去后端拽，又生成临时文件，并发量大的时候，一个大文件会对应N多的临时文件，最终这些文件rename到一个目标文件，大大浪费了磁盘IO。这个rename是内核做的，nginx调完之后就返回了。这种问题往往会导致内部网络流量非常大，而实际却没有根本没有大。 当有多个连接来获取同一个文件的时候，squid中却没有跟nginx cache一样的问题。我们看看squid是怎么解决的吧。我们在squid有这样一个参数collapsed_forwarding on（http://wiki.squid-cache.org/Features/CollapsedForwarding），一旦设置了参数了，当发现有连接请求同一个文件的时候，squid会合并多个连接，但是它会以最慢速的那个连接去取，然后同步地传送给客户端。这样就不会重复请求后端了。但是squid也有问题，因为首先它是同步的。当用户请求的是动态的内容的话会导致客户端错误。而且当一个用户连接速度很快，一个用户连接速度很慢，那就会以最慢的速度进行获取和传输。所以在squid3.0以后取消了这个参数。 这个问题的解决办法暂时看起来只能在nginx cache前充一下热点的大文件。还好一般内网都是千兆连接，这个速度往往大于用户的连接速度。只有当文件特别大，并且热点文件特别多的情况下才会发生。而且nginx这种处理方式也有一定的好处。 nginx upstream流程我们可以参考http://bollaxu.javaeye.com/blog/900424和http://bollaxu.javaeye.com/blog/900357这2篇文章。基本是由于nginx upstream为了防止锁所以进程间是不共享的。

在我这边现实环境中主要是有三个问题。 第一个问题是当cache过期的时候，nginx会把cache状态设置为updating，但是这个updating却没有设置一个超时，所以导致的情况当一个cache过期的时候好多nginx会连接到源站取数据，而如果源站并发量有限的话，会导致源站突发负载过高，而这个时候导致nginx一直处于updating过程中，如果导致源站挂掉的话，那完蛋了。当然我们也可以设置proxy_cache_use_stale updating;但是这样会导致cache的内容不准确。

解决的方法有2种，一个是我们现在更改nginx源码，使之可以updating设置有超时时间，这样不会导致长时间连接源站造成拥塞。另外一种就是nginx cache分层，分为父节点和子节点，只有父节点才会去源站更新，子节点只从父节点上更新。 第二个问题是upstream中server的状态，我们知道upstream中可以设置proxy_next_upstream当一个服务器挂掉后自动转到其它的服务器上，但是这里有个问题就是让用户访问的时候proxy会每次都会先访问下这个坏的服务器，连接不通了再转到其它服务器上，这每次都要测试会浪费大量的时间。我们需要得到的是proxy会独立一个线程去检查后端服务器，一旦发现后端服务器挂掉的话，那直接从upstream中剔除掉这个服务器就可。而等检测后端服务器又存活了再加进来。 这个现在有ngx_http_healthcheck_module这个第三方模块。具体可以参考http://wiki.nginx.org/HttpHealthcheckModule 第三个问题是nginx proxy连接nginx cache的时候居然使用的是http1.0的，而不是http1.1，就没法使用keepalive连接后端，导致我们小文件的cache服务器连接数过高，而没法进行复用链接。 这个暂时还没有解决，不过看到http://wiki.nginx.org/HttpUpstreamKeepaliveModule这个第三方模块，但是实际还没有测试过，没法做什么结论。 其实大家可以完全查看http://wiki.nginx.org/3rdPartyModules 来看看是否针对自己的应用，有些还是我们国人自己开发的，但是针对第三方模块还是要谨慎使用，上面的healthcheck模块还是经过我们自己的开发重新修改后并进行压力测试后再上线的。开源就是这点好啊。看来我要得学习学习C语言编程来，以后自己也改改增加增加功能啥的。

Mysql读写分离

首先我们必须知道为什么要分离。这个一般是由于以下原因导致的。

1. 性能，单台数据库实在是撑不住了
2. HA，防止单台数据库挂掉造成应用不可用
3. 扩展，由于业务新增了新的需求

以上几种是我们常见的要进行分离的原因。其中做多的可能是第一和第二种。这个主要还是涉及到钱和服务器的数量上。一般业务都会在前端部署更多的服务器，而在最后端的数据库服务器往往比较少。但是对于好多web2.0 UGC这样的业务的网站还是有必要重视后端的速度和稳定性。   分离的多种方案

1. query proxy，这个一般是由单独的服务器来进行的，由它负责这个sql语句路由到哪个服务器上。这种proxy的话最好还是要建立HA方式，不然这个proxy就是一个单点故障。这个在之前人人的系统中就是如此，虽然只是负责发起查询的时候建立真实mysql服务器和应用服务器连接，但是还是比较危险的。
2. Load balance, 后面一堆服务器，通过轮寻的方式来访问mysql服务器。这个很多时候是通过内部DNS来实现。

  分离的多个原则

小时候就一个圆脑袋 干嘛你要看着我呀？ 我也喜欢长啸几声 我们长大了哦 我们就爱趴着 我也来点朦胧的 有时候我也思考东西 也有惆怅的时候 这么多愁善感当然是女孩拉，但是我不喜欢这个造型 有时候我也来点摇滚的风格 我就是不喜欢穿衣服，那就意味着我要出门了 ###########################################

  Best regards Timo Seven

翻译自2010年oreilly mysql user conference中《InnoDB Plugin: Performance Features and Benchmarks》一文 原作者：Jimmy Yang John Russell Calvin Sun InnoDB1.1的新特性

1. 多个buffer pool实例
2. 提升恢复性能
3. 扩展的InnoDB更改buffering
4. 支持Linux原生的AIO（异步IO）
5. 多个回滚段
6. 分拆flush list互斥
7. 改进purge调度
8. 改进log_sys互斥
9. 性能schema支持

多个buffer pool实例

buffer pool互斥是为了保护很多在buffer pool中的数据结构： LRU， Flush List, Free List, Page Hash Table
buffer pool互斥是一个热门互斥（可能不是最热门的）。
在sysbench测试中，它能达到大约700k/s，花费大概50%的时间。
InnoDB性能schema同样可以证明：

它的解决方法如下：
拆分一个buffer pool成为多个buffer pool实例。这种拆分的结果可以避免所有查询执行代码占用一个以上的buffer pool互斥，只有少数的查询代码会同时占用多个互斥。在16核的服务器上sysbench的读写测试可以提升10%，当然它也会提升只读的性能，在32核的CPU上提升的幅度更大。

使用 innodb_buffer_pool_instances=N，下面是测试结果

跟你在一起也很长时间了。现在怎么觉得我们两的共同语言越来越少了，你喜欢的我就勉强跟着喜欢，而我喜欢的你却骂我脑子有毛病。 是阿，我是认识一个脑子有毛病的人，可惜她已经死了，跟电视里那个人一样的毛病–脑瘤。 我知道你的工作压力比我高许多，可也不能因为这样而生闷气啊，这样不光对自己身体不好，对于家人也不好。你以前不是什么事情都喜欢说出来啊，可为什么现在不说了，只是从表情上看出来不大高兴。我知道你的意思是想让我们大家猜哄着你，可你也是大人了啊，可不能跟小孩子一样。我希望的是以后有什么事情可以直接说出来，虽然我看过心理学，但还是不怎么懂你啊。看来我得理论和实践共同成长，也许能做到以后你一个小动作就能知道你想啥了，不过那样会不会觉得我恐怖了呢？ 另外一个是穿衣和化妆。我是不反对你在这上面花时间的，我觉得这样挺好，但是你的衣服大多看着不好，感觉太随便了那种。我想对于你工作来说真不适合这样穿。应该更正式一点，你买的休闲西服上的也都不穿，要说配裤子，那我们就买去啊。女孩子还是少穿牛仔裤这样的较好，得淑女点。化妆倒还好啦，本来淡淡的妆就好了，最好是不用化就好，毕竟化妆品都是化学成分，对于皮肤总不会好到哪里去的。看看那些明星不化妆的那个脸，我相信这些都是化妆品给弄的。毁的越多就越化，越化越毁，越毁越化。 好了，虽然这样，我觉得我们家宝宝还是不错的。可能由于单位同事的关系，你对生活的物质需求越来越高，你从小就是吃你爸做的饭长大的，怎么现在就吃不习惯了呢，我都吃的挺习惯的。看来人跟人的差距还是大的。对于我来说外在的物质需求真的很简单，很无所谓。关键是有书看，有事情可做，有梦想，这就心里不再空虚了。我希望每天都能昨天一样，可以安静的写文档看会书，但是这样就让你觉得我不理你了。所以还是做早起的鸟吧，这些事情留在早上来做，请允许我通过1周的时间来调整吧。那样晚上就可以配着你，而且也不耽误学习，但是我现在怕起的太早会打搅到你。 关于兴趣吧，我觉得吹口琴挺好，虽然不会，但是我知道你其实会的，音乐对于开拓自己很有好处的，真羡慕小田子会那种高级乐器。我要会就好了。还有昨天说的折纸啥的，你太小看这些小玩意，这个我还真准备当作爱好来培养，智能电子那个东西要买很多外部设备，而折纸真是材料太简单了。小玩意玩出大花样，不是之前跟你说过之前有个老太太只会剪纸，结果美国人把她当文物一样移民到美国去了。生活中很多事情我们看着简单，但是其实还有很多深入挖掘的东西。你不懂计算机，但是你知道这个内部是多么的复杂，做一个像《愤怒的小鸟》这样的游戏需要多少人写多少代码吗？ 这些都是你不可想象的。 好了，先就说这么多吧！

MySQL服务器的linux性能优化和扩展技巧

作者：Yoshinori Matsunbu

作者现在是DeNA公司的数据库和基础设施架构师。
之前在SUN公司工作。
他也是HandlerSocket的作者。
这个是MySQL的NoSQL插件。

本文是根据他的PPT整理而成的，如有不正确敬请指教。

本文有可以直接点击下载：linux性能优化技巧

本文主要的内容有如下：

对于常看PDF文档的人来说，批注是非常有用的功能。

而对于我这样经常看英文文档的，有时候旁边加个翻译什么也是常有的事情。最近发现xournal是个不错的pdf批注的工具。可以用很多工具进行批注。默认保存的格式是xoj。但是一旦我们批注完成想进行发布和保存的时候可以导出为pdf格式。 在ubuntu直接sudo apt-get install xournal 安装就可以了。 也可以上项目首页：http://xournal.sourceforge.net/ 帮助文档在：http://xournal.sourceforge.net/manual.html

sohu系统工程师的面试题还是比较内容全面的。下面就是我之前进的时候的一些笔试题目，之后还有好多面试的，是一轮又一轮阿。应该说这些都是比较基础的题目，而不会考你一些源码啊，这其中还有一些开放的题目。比如15和16题基本可以根据自己的想法来写。

1. GPLV2协议的主要内涵是什么？
2. UNIX,Linux,BSD,Solaris,System V之间的关系是？
3. Linux开机引导的步骤
4. inode和VFS的涵义？  文件权限 4755的涵义？
5. 64位和32位的主要差异。
6. Linux内存管理的工作模式。
7. DNS反向解析的工作过程。
8. traceroute的工作原理。
9. TCP3次握手过程。
10. TCP滑动窗口原理。
11. time_wait, fin_wait2的涵义。
12. http1.1中keepalive1.1的涵义。
13. apache的apxs和dso的关系。
14. SQUID的cache置换基本工作原理。
15. 大型web提供性能的方式。
16. SCSI标准为什么被sas取代。
17. RAID0，1，5，0+1涵义。